2,329 karma · joined October 27, 2014
There’s enough profit to make the payback period for a decent battery quite short.
CRTs needed to be refreshed to keep the phosphors glowing. But all screens are now digital: why is there a refresh rate at all?
Can’t we memory-map the actual hardware bits behind each pixel and just draw directly (using PCIe or whatever)?
Let's say they did. Would you be saying "So what?" then too?
It hasn't happened yet. Is there something you perceive as especially problematic now, as opposed to the last 30 years?
To create something like the GNU project, or OpenBSD, or Linux, takes serious levels of commitment. You really have to believe in it, and to a degree, you have to _will_ it into being. Along the way, you need to explain why your crazy idea is worth all the sacrifice, discourage those who would distract your team members, maintain your own and the team's focus through years of not actually having the thing you want in any useful form, etc, etc. You have to be an unreasonable person to take it on, and then continue it.
There are people who become "fans". They can be even more zealous than the project leader(s). Maintaining direction (aka control) of a horde of over-zealous fans takes aptitude and patience. It's easy, I think, for projects to devolve into vitriol, and denigration of those who think differently, even if it starts out from a good place.
All group endeavors are ultimately political. A group endeavor with a multi-year payoff period and no tangible rewards? It's bound to be very political.
That said, we all enjoy the fruits of their labors ...
I think Perl5 was originally planned to be replaced by Perl6. Then Perl6 took much longer than anyone expected, and kinda ended up in a different place. Perl5 was re-anointed as the once-and-future Perl, and what had been Perl6 became Raku.
If I remember correctly, somewhere in the middle of all that there was talk of running Python (and other languages) on the new Perl6 VM.
Similar motivations: the developers had some legacy decisions that were unfixable without breakage. But they were sick of it, and decided to just go for it.
Most end users didn’t care about those issues. The few that did were happy to pay the cost of switching. Everyone else clung to Python2 for years because migrating was high cost and low value.
It took about 15 years to complete the migration for most, and there are a small number of users who will never make it over.
Perl5 to Perl6 is another useful historical example.
FOSS development is managed by the developers, and so, compared to a commercial software project, the implementation issues get more weight. This sort of thing is very likely to happen again and again.
OTOH, eg. (not an advertisement, just the first search result) masto.host offers managed Mastodon hosting for $6/month, which is on par with eg. Fastmail or Proton's base non-free plan.
If you're using someone else's email domain (like, eg. gmail.com), you cannot migrate to another provider. If you use your own domain, you can change who is hosting it.
Like email, there are plenty of Mastodon hosting companies. You can use your own domain, and migrate between them at will. If you use eg. mastodon.social, you can even migrate in most circumstances (but not if the instance vanishes).
Using someone else’s instance is just outsourcing your decisions.
Other people might be ok with or even enthusiastic about that, but that shouldn’t be your problem.
When you’re broke and hungry, those differences become immaterial compared to the protein-bar/no-protein-bar tradeoff.
Some humans will very likely survive. Millions, possibly hundreds of millions, will die.
Life as it has been known for hundreds of years will change dramatically.
An unwillingness or inability to conceive of this possible future as anything more than “it’ll be colder, but fine” would make it vastly worse for many people.
Yes, there is a cost to changing software. But it’s not unique to an Open Source migration.
Once that’s in place, the process for populating that repository can easily adopt locally modified versions of upstream software: defaults changed, bugs removed, features added, etc.
No one in a big business/government blinks at changing group policies for internal deployment. Changing the code is really very little different once the ability to do so is internalized.
Pre-coffee, apparently.