Personally? I'd say that this is totally unreasonable.
Pre-restricting the use cases of the device that YOU bought and have the ownership of is absolutely not OK.
There are a multitude other trivial ways this could be accomplished, but they chose the "lets squeeze the market" and "fuck the modders" option.
The company is a part of the society, and has the responsibility of providing support for their devices. Society provides the customers and money, and the company has the obligation of providing support.
They could just burn the serial to the silicon and when someone needs support, they need to provide the serial and they cross-reference the data tied to the serial number.
Too much ram? "Yeah, sorry, we can't guarantee the operation of your device. Here's a 5% off coupon for our store to get one with our genuine hardware"
Judging by how many people in this thread seem eager to reinvent the hellhole presented in that episode, it's good enough to recommend as required watching.
There's the program called Starshield, that's part of the miltech side of the program. One of the military uses is using the starlink constellation signals as a passive SAR for the whole planet with millimeter scale accuracy.
I don't have the answers, but I'm speculating that it has developed first from being a skeuomorphic text representation depicting a modem/ethernet port, but then just being re-used outside the original and slowly evolving to what it is currently.
Probably not, as modems connected to Macs via a round serial port identified by a phone icon and Ethernet ports were originally AAUI (D-shaped transciever port similar to AUI but with a smaller connector) or, on some of the old NuBus cards, 10BASE2 (coaxial).
I suspect it's just a stylized double-ended arrow representing bidirectional data transfer, created because Apple (or whoever) needed a localization-agnostic way to represent "Ethernet" on hardware.
This is a tricky field, the problem is not actually the non-determinism of the processing algorithms, but implicit ordering of the data.[1] The implicit ordering of the data is a footgun that -- as seen in the paper -- has already claimed victims.
Using algorithms that don't need to upkeep the ordinality requirement in every operation will definitely move the library to a better direction and make future data modeling better and more explicit.
[1] Aha, now I see why language models use this so frequently and why it might be overrepresented in the data. This is a perfect way to move the blame from the person you're responding to, if they're mistaken. They probably have a super, super overtuned "politeness" gym using sentiment analysis that tries to reword answers to not blame the misunderstandings of the person. Then this blame shifting unfortunately gets re-used as this super, super common phrase.
By "implicit ordering", do you mean "implicitly assumed that the data is ordered a certain way"? Since if that assumption of data being sorted a certain way is broken on some systems and not others, the result might be both non-deterministic (which could be a bug if the result is not allowed to be non-deterministic, but may or may not be a bug regarding the algorithm's assumptions) as well as a bug if the algorithm's assumptions requires it to be sorted a certain way.
> Using algorithms that don't need to upkeep the ordinality requirement in every operation will definitely move the library to a better direction and make future data modeling better and more explicit.
How would the library "make future data modeling ... more explicit" if this is a change to a default, which is implicit?
> How would the library "make future data modeling ... more explicit" if this is a change to a default, which is implicit?
It would become more explicit because where the order matters, you will now see a `maintain_order=True` where previously, you couldn't say whether it actually needed the fixed order or not.
Yeah, by implicit ordering, I mean an underspecified pipeline which has an undeclared dependency on some of the inputs being sorted. Unfortunately this is why the code in the cited paper worked on some systems and not others as the os.listdir() call didn't guarantee sorted results and thus the assumed invariants were broken.
Requiring code to be explicit about its invariants by default is just plain good design and makes things more robust. And when being more exact about invariants, you can reap the algorithmic benefits.
NIH barely applies here at all. If we take into account the constraints they were under and the absolute state of desktop Linux when Android started, it makes total sense.
Starting a lot of the components as greenfield projects will fortunately help a ton with shedding years and years of legacy cludge, hacks and desktop first design. Without mentioning the colossal amount of friction they would've faced if they tried to upstream any of the code they would've produced by the end. "We don't care about that issue. Closing."
Because of the above, they still would've needed to have their own fork regardless and still would've eventually diverged further and further -- so why bother? With a greenfield project, you can just optimize to your specific constraints. If the maintenance becomes too burdensome, just pick up the best of your design and reimplement them onto the non-greenfield project, everyone wins :D
Yeah, it technically was there, but it had proprietary components and Nokia had a baggage of softbware project management being super inefficient because of their earlier roots of how they developed software in their past. Not that I have personal experience of it, but a colleague of mine had first hand experience of it.
Nokia had a "means to an end" type of perspective to software, it was all made to be basically disposable and they didn't have great "steward of the platform" type of effort.
Also, if we take a gander at the timelines, unfortunately QT and Maemo were happening in parallel, and of course Maemo was based on GTK. (But QT was still a Nokia proprietary tech back then.) Right hand not knowing what the left hand was doing etc.
Not that any of this means anything, just felt that this was all relevant.
And in spite of Nokia being fundamentally in the dark, not really helping: it was a wildly successful scene. People were rabidly excited and doing incredible things with their devices, in cross-modal between phone/laptop/desktop ways. The core of technology had great interoperation points.
It's weird because my whole point is that the freedesktop mentality means no one company ever is that important to the device. And your point is that Nokia was terrible at Maemo. Yes but? Yes but: it didn't really matter. The ecosystem was incredible, intense, vibrant. If you leave the door open, people will do amazing things with your platform. And even if the company burns the platform, burns the ships, a lot of people will still probably spent a decade being vociferously dedicated to the platform.
https://maemo-freak.com/community/
You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state.
Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"
Without knowing it, you're thinking at neither high nor low level. You've accepted at face value claims made by RISC-V architects about how to design an ISA for low level embedded controllers, but they weren't actual experts in that field. Instead, they were largely academics.
When you read their stuff, they're constantly overestimating the value of ultra-minimalist CPU designs in the modern context. In fact, they often show little understanding of the real impact of ISA design decisions on implementation complexity, so some of their decisions don't even make sense as minimalist decisions.
To expand on the low value of minimalism: even in trailing edge process nodes, if you're designing something on the scale of a simple single-issue in-order 32-bit RISC core targeting no particular frequency, gates are essentially free. The RISC-V guys are badly out of touch. If minimum gate count mattered as much as they think it does, there would still be a thriving market for 8-bit microcontrollers. Instead, they're steadily losing market share to 32-bitters, even in applications where an 8-bit µC would be more than enough. It's not the 1980s, you don't have to struggle to fit a featureful 32-bit core into a single die anymore, but they're hellbent on relitigating that era's debates.
If the spec was only arguing that avoiding flags allowed for simpler implementation of minimal in-order pipelines... I might actually agree with it.
But the argument in the spec explicitly uses the "added complexity to out-of-order microarchitectures" as a part of the justification for not having conditional move (and flags). It's the most commonly parroted part of the argument (see above) and the part of the argument I'm responding to.
I actually agree with much of the spec's argument. The cost of not having flags is pretty low, the MIPS approach does work pretty well, and it does simply things.
I'm just not sure it was the right trade off, and I strongly disagree with its attempt to use OoO cores as part of the justification.
Skitter creek bath salts... Or SCBS
Guess there'll be a talk called Secure Computing BullShit in the next Blackhat conf! I'll be eagerly waiting for it! :)
I'm probably an outlier, but as someone working a non-physical job, I have been talking about how I personally would still keep working and doing jobs even if all of my basic needs are met.
I do work purely because of idealistic reasons. I'm not actually owed anything, I'm working because of us, humanity.
Yeah, people are going to slack, and that's just life. It's just statistics, optimize society to such a configuration that people acts have a place and get the support they need. Most of the "slackers" who represent the people just living on the UBI type system you described, probably don't do it as a direct choice. Most likely they feel like they can't contribute to society, but that's something that's solvable. It's a matter of education and culture.
About your quote:
"have nothing to lose and decide to attack the source of their misery. Bread and circuses will only distract so much."
There's a theory directly relating to this that I have about the modern golden age of punk and rock in the nordics.
When people had all of their basic needs met, they finally had the time to take a breath, take a look inwards and face their own inner demons. I suggest that this was one of the big things that created the conditions which made the nordics the rock/punk powerhouse that they were.
Of course, the good times also had their downsides, lots of complacency in politics and not feeling the need to fight for better, because things were already better than they've ever been!
There are a multitude other trivial ways this could be accomplished, but they chose the "lets squeeze the market" and "fuck the modders" option.
The company is a part of the society, and has the responsibility of providing support for their devices. Society provides the customers and money, and the company has the obligation of providing support.
They could just burn the serial to the silicon and when someone needs support, they need to provide the serial and they cross-reference the data tied to the serial number. Too much ram? "Yeah, sorry, we can't guarantee the operation of your device. Here's a 5% off coupon for our store to get one with our genuine hardware"
THIS WAS SUCH AN EASY MARKETING WIN :(
reply