and the problem is that if you apply for a job in this area you have to know them all +10 years experience with all the frameworks and backend stuff, sql, docker
More money. More power. Greed. Don't ever underestimate human greed. It doesn't matter what people have or where they are, they will always want more. We only have what we have now because of a few very peculiar people like Richard Stallman, but now it's just a bunch of normies in control.
I'm guessing immortality I'm not joking. We may be the generation that has the right escape velocity to escape death. Vladimir putin mentioned it in his recent china summit
I think it's an unintended effect of Europe regulations. Google saw Apple exploring what's the bare minimum to comply with EU regulations regarding openness. And Google is setting their bar there.
Because Apple didn't want to open their ecosystem, they invested a bunch of money (and time) into "exploring what's the bare minimum required to comply with EU regulations". Now Google is locking their ecosystem down the same way because they know they are legally allowed to do so.
This is why it's an "unintended side effect" of EU regulations, as the regulations prompted Apple to find out how much user hostile behaviour they can get away with.
It's not sudden, and it's about control. You probably don't remember a time when you could switch/remove batteries from your phone. All manufacturers removed this ability.
That was one very good reason for me to choose a FairPhone. (Almost?) everything is user replaceable. It has been in my pocket for a could of years and I have not needed to replace anything yet. But I do like having the option.
Samsungs Galaxy S21 is also really simple to fix stuff. The back is made of relatively flexible plastic connected via glue, which you can easily get under by blowing into the charging/speaker port. Once your inside its all just a lot of screws.
Had to reattach the battery ribbon cable after my phone fell one too many times (I could have also just fixed it by pressing on the back in the right place, but I only really figured that out after I disassembled the phone).
I have a Volla Phone running Ubuntu Touch. In order to insert my SIM and SD cards I had to take off the back cover (which is intended and I just had to pull on a small gap in a corner of the device) which also made it very obvious that it's easy to take out the battery should I have the need to swap it out.
It's actually not happening all of a sudden. The dam-breaking moment is more that Samsung, the number #1 Android vendor, decided to stop supporting it.
The vendors stop maintaining bootloader-unlocking methods because the cost/benefit profile to develop/maintain/support that feature and its consequences is simply not sufficient, all while several of the biggest customers explicitly require unlock to NOT be supported.
Supporting this is not just about the unlock itself, it's about allowing this unlock (required as some carriers explicitly forbid this, so a unlock needs to be requested), then performing the procedure (using a shared secret between the device and the vendor) and then the OS continuing to boot in this untrusted state with all components gracefully handling this broken trust-chain.
The commercial incentive for this feature isn't there for a device-vendor, it actually never was. It was built, defended and fought for by passionate people (mostly within the R&D) of those companies. Companies which managed to implement it early (in times of higher product margins) were able to keep it longer, others simply couldn't get the budget to implement bootloader-unlock in the first place. Today, devices are shipped with commitments of several years of upgrades, without the vendor actually knowing yet how the OS-upgrade in 2 years will look like. Keeping his custom security-implementation is a risk-factor here
The 3rd party OS developer community was always small, and became even smaller in the past years. The footprint of alternative OS users was shrinking since Cyanogen (the leading "universal kernel" developers for Android and predecessor of LineageOS) dissolved (or tried to become a for-profit).
However, the events around Cyanogen were more of a public symptom, The main driver for people to stop using 3rd party OS's was:
1.) The increasing fragmentation of devices in the market: When the community started, the majority of the market was Samsung, Motorola, LG, Sony. Samsung was leading, but each of them had quite healthy parts of the Android market, competing with each other in an "almost-stalemate" situation. Today Samsung is leading with a huge margin, all others are basically fighting for scraps. So naturally, most of them try to go for the lowest common denominator and find a distribution channel.
2.) Android itself became more competitive: At the height of the OS community, people switched to alternative OS's to get a newer OS, new customization options and convenience features. Today, vanilla Android checks most of the convenience options already, sufficiently that most people don't want to bother researching alternative options, maintaining them, etc.
Devices of major vendors are receiving upgrades for several years (back then it was ONE major-OS Upgrade, a YEAR after Google's release, if at all)
3.) Device-integrity became more important: At the height of the OS-community, there was no Device Integrity check by Google to give a flag on whether the device can be trusted or not, so all apps kept working (with minor exception of some streaming services restricting their service/resolution, as the DRM keystore became unavailable on unlock). Today, most banking and entertainment apps rely on those Google integrity checks to decide whether they should even start. This introduced another reason for users to consider their actual need for an alternative OS.
--
How to change that: If it's not possible to create a commercial incentive for the vendors, a regulatory incentive could be an option.
It's crazy to think how much computing power is just added to a drawer or landfill every day, just because there is no reason for the vendor to allow you to repurpose it.
I think this could be a path, to legally require device-vendors to provide a common SW-layer with respective documentation to utilize features of underlying hardware (optional without the shipped OS on top, disconnecting the device from the shipped ecosystem).
This would prevent e-waste and put this old hardware to better use. A community OS could then be built on top of this common SW-layer and be maintained for a wider range of devices.
I would e.g. LOVE a "Browser on everything" OS which just provides a Browser OS for outdated hardware, but the only way this could work on scale would be if the device-vendor would be mandated to provide and document the lower layer...
Someone would have to make the economic case for such a regulation as well, i.e. demonstrate the benefit for society if that is in place. The chances for this are razor-thin, especially in today's public/political climate.
Yeah well, not in the way it progressed after the carriers started to take control over it (I was actively involved in a Firefox device-project back then).
What I sketched out here with a "Browser on everything" OS would be a concept for a aftermarket OS, where the device-vendor is not required to have his OS support the unlocked HW (because he can't be forced to do that), but he will have to provide components and documentation up to a certain layer to make use of the hardware. This could then be the layer for a generic "Browser on everything" OS to work on.
Very much thanks for this text. This makes much sense.
I don't think regulation would help ... only ppl who show their raised middle finger to this vendors.
I mean this scenario is the scenario ppl thought of when TPM came up ... a fcking closed up device and you are in the hands of the vendors.
People showing their middle finger won't be enough, because the vendors are torn between two groups of interests here:
1. Building a HW/SW product which works within controlled boundaries to provide warranty, support, repairs, future maintenance, Google-compliance, regulatory compliance,...
2. A subset of Customers wanting the HW to be separable from the SW, for product to be open in a way that they can use it differently than intended (potentially creating "Group#3", a HW/SW product with a different SW).
To create a product for Group#2, alot of the aspects of Group#1 still apply, but in a more-complicated, more-expensive manner. If there is a viable business-case for Group#2, it will be a separate more-expensive product with lower volume.
But in reality, the only way a vendor could meaningfully resolve the needs of Group#2 is if ALL his devices support this feature (including customers who don't want a unlockable "open" device now), allowing everyone to become member of Group#2 without having to buy a new separate product.
For this, the economic incentive doesn't exist.
Explicit example: The Fairphone is a great device, but it will never sell more volume than a Samsung Flagship, because it's a device satisfying the conscious needs of a niche of customers, without the chance of reaching comparable volume to compete in all other areas.
That's why the only chance I see is to create a regulatory incentive by making the requirements of Group#2 a part of Group#1, to have the "unconscious needs" of the majority also satisfied.
Because only THEN the mainstream-customer can be converted to *users* of this potential "Group#3" product, and market-forces have a chance to flow freely again, if you see what I mean...
The government is also keen to have these devices controlled more tightly. Now with the help of the big companies so much data is on the device and in the cloud about you that policy enforcement, tax evasion or anything else that the people in the government deemed crucial for them is much more easily done.
Check how China controls the Uyghurs phones and will they be happy to have "unlocked bootloaders".
It's not profitable for the companies to lose total control of "your" device you "bough", nor for software developers who sell you the software to have "ReVanced" versions of their apps. Just a small minority of people who understand what is freedom and ownership are aware of the dangers of this.
Basically, not enough people care to have this as a priority and make it an election issue. And sadly we're walking into more and more control, ads, and enshitification. :(
> The government is also keen to have these devices controlled more tightly.
Not to oppose what you wrote, but let me try to give you a different view on the same picture to support a different conclusion:
In the eye of most governments these devices play such a minor role that they practically don't even exist.
What governments see is messaging services, finance services, digital marketplaces, and so on. It was and is their job to do that. They used to regulate telecom providers, financial institutions, marketplaces in the past, and they are now catching up realizing that the carrier is no longer the messaging provider, banks are not in control of all finance flows, marketplaces exist beyond the classical physical markets, etc.
If you look at detailed regulation and laws, Governments still have little interest in the explicit devices, they still look at those new variants of classical services and try to adapt to them.
But what the PROVIDERS of those services do, is creating pressure on the devices to help them reach lowest-effort compliance for their SERVICE-requirements (--> "let's make the end-user device bulletproof trusted, so we can offload our responsibilities to his device").
This is in most cases why the devices evolve the way they do. Because they are a merge of product and services (often from the same vendor), and the product is evolving to satisfy the needs for those services.
That's why fighting for "ownership of your device" is mostly futile, because the assumed opponent in this fight doesn't even feel addressed.
You need to bring the fight to their topics, to the topics relevant for governments:
On how a citizen ID should be verified, how financial services should be realized, how a competitive market should be ensured also on digital markets, etc.
Less conspiratorial answer (better late than never):
Google services, integrity hardening:
From outside it might be difficult to understand the distinction, but Google is acting here as the owner and maintainer of a services ecosystem, which is the entire Google service-package provided to end-users. For them, Android is provided as a foundation for that package, and they increasingly experience difficulty to contain issues within that ecosystem and prevent them from spreading (piracy, malware, hacking,...).
The logical way out for them to contain those issues is to ensure that members of this ecosystem (=Devices with Google Services, Developers) are vetted more strongly.
Now Android has a history to be an open ecosystem, which allowed it to grow to the size it has now. But similar to the bootloader-unlock situation of device-vendors, the economic incentive of an "open ecosystem" keeps shrinking in comparison to the risks and issues it's causing Google in governing their services-ecosystem.
They obviously decided now that the price they have to pay for that "open ecosystem" (less control over the services ecosystem) is not justified anymore.
Now they have little room to move. In order to preserve that "open ecosystem", they would have to provide the user an option to disable Google Services entirely. But Google services are such a integral part of the OS-experience already that it which would turn the device almost into a completely separate product, different from the product the vendor initially built and the consumer initially purchased.
--
I don't expect this to be properly resolved for the sake of "pleasing the community". Products and Services are already so tightly combined in the Smartphone-space that it's hard for most to even understand what it is the user actually purchased when he bought the device.
Now Google the service provider starts to change the users' device in order to maintain his services, and there is no up-to-date definition to what degree they are actually allowed to do this.
How to change that: The underlying customer-protection framework is missing. A solution would be a general legally binding definition of what functions a customer owns if (and when) a device is stripped of any services on top.
If my car loses functions once it loses connection to the manufacturer, this bare set should be communicated as the purchased value ("in exchange for your money"), separately from any on-top ("in exchange for your data") business-model.
In theory this could create competition on the actual purchased value again, instead of continuing to offload the value from the device to some service provided by the vendor/service-provider...
But that's such a complex topic, the implications should be studied much deeper. Also, I don't expect political bodies to fully understand it for years to come, leave alone create a proper case to get the required voting and decision...
> Google is acting here as the owner and maintainer of a services ecosystem...
> they increasingly experience difficulty to contain issues within that ecosystem and prevent them from spreading (piracy, malware, hacking,...)
I wonder if the smartphone app industry is big enough now that allowing just two corporates to govern them is no longer fair or democratic.
It has outgrown the "ecosystem" word a long time ago. It's a genuine industry now.
Apps are such a fundamental part of most people's lives now (whether they like it or not), and these two companies have a disproportionate amount of power over an entire industry.
This is more or less the journey the EU has started with the Digital Markets Act, but in a very agnostic way.
They identified that, among others, Apple and Google are operating a "Digital Market" of significant size within their ecosystem, where they invite others to participate and compete, and it's the role of a government to ensure fair conditions in the markets of its economy so forces can flow freely.
The way they defined that is very smart. They don't define what an "app" is or an ecosystem, they identify in a objective way that their operations constitute a market, and that they have to comply to certain rules in order to ensure fair competition.
I just hope that they can see this through and have those Digital Markets established as proper "markets" in the same sense as physical markets are, before some political "wind of change" is dissolving everything again.
Apple is very much counting on such a wind of change, by actively rallying its users against the EU...
I live a pretty frugal life, and reached the FI part of FIRE in my early 30s as an averagely compensated software engineer.
I am very skeptical anytime something is 'free'. I specifically avoid using a free service when the company profits from my use of the service. These arrangements usually start mutually beneficial, and almost always become user hostile.
Why pay for something when you can get it for free? Because the exchange of money for service sets clear boundaries and expectations.
I never use color names (except if I quick want to set a color in CSS for testing purposes) so I wonder who is using color names and why?
Does all this has any real world implications?
I used to use them in both X11 and CSS way back in the day. They were really common in X11, because a lot of users were on pseudocolor displays and it made sense to reuse colors as much as possible.
If you used uncommon colors in your program on - for example - a Sparcstation 20, the palette would shift every time you moved the mouse in or out of your window. It's difficult to describe to someone that's never seen it, but it's unpleasant. No one mourns the death of pseudocolor.
Pseudocolor was a different thing. The palette wasn't fixed. The adapter could display any color in a 24-bit color space, but only 256 colors at once. So if you had one program that used one palette and another program that used a different palette on the screen at the same time, whichever program wasn't active would have its colors scrambled.
On the CSS side, I sometimes use named colors as an anchor point. Like when writing a dark mode and thinking "that text might look good in yellowish" I set "amber", and the result was good enough to keep it. Other times it makes for a good challenge, limit your design options to only named colors to not get lost in the color wheel.
As a casual user and coder, I use them, because I don't know what #FF00FF or #00FFFF look like, but I do recognize magenta or cyan instantly. Though, support for hexcodes has become better in editors, so it's now a mixed experience.
As touched on in the article, the beauty of colour names would be that they’re celebrated for the machine.
#124356 might look different on one monitor or workstation compared to another.
Having colour names which are calibrated for the device makes a lot of sense. Assuming those colour names are actually calibrated, which as the article also mentions, so often wasn’t the case.
As an aside, this is a big problem in DTP where your display should match the page. However you obviously wouldn’t use colour names in that specific industry because you’re dealing with a vastly greater range of colours and shades.
In the case of CSS specifically, that’s right. But the practice of assigning names to colour values predate CSS by quite some time. And the reasons for doing so are what I’ve described.
Nitpick: you absolutely would use colour names in that industry - it's just that the colour names would be more along the lines of "Pantone 137C" than "Yellow".
In desktop publishing or other graphic arts where you are sending your files to pre-press for physical printing you would use CMYK or Pantone (for spot colours) + paper grade.
Those can be useful, but not really against LLM content. Though neither do I think an LLM-based filter could actually reliably detect LLM-based content.
reply