Excellent news. This is something far more open source projects should do. All this fragmentation is good for nothing, it is far better to have one really good piece of software than 20 half baked ones all doing roughly 80% of the whole.
Except it wasn't 20. I was 2. One for free and one for the enterprise.
I totally agree with you, but that's a different statement than the one in the comment I originally replied to.
Rick Moen wrote a good essay titled "Fear of Forking"
http://linuxmafia.com/faq/Licensing_and_Law/forking.html
It's a defense of forking, but it contains a few capsule histories of important forks of the past (from the perspective of when it was written) which are interesting.
When I first started using GNU/Linux in 1999 (Red Hat 6), I found it confusing to understand what all the fuss was about with libc/glibc and egcs/gcc. I think the differences had been resolved by that stage but all the related documentation referred to the split which made learning this strange new system very confusing (at the time, I knew what a compiler did but I didn’t know about anything about architectures other than x86 and I didn’t know why a C library was so important).
Rick includes a reference to the Emacs split of the early 90s. Jamie Zawinski’s reflection on this fork is quite interesting: https://anonym.to/?https://www.jwz.org/doc/lemacs.html (using the anoymiser as Jamie doesn't seem to like news.ycombinator.com as a referer).
Amazon [2] has some micro travel routers only - so what are good options under 100$?
[1] https://openwrt.org/toh/views/toh_available_864?dataflt%5BDe...
I have to disagree on this one. Multiple diverging projects create _Stability_, whereas a single project creates _fragility_. One bad step on the only project, and it will be all who suffer
I thought it was about scratching your own itch? "I want to be a maintainer" kinda sounds like an itch.
The relationship between FreeNAS and TrueNAS is more like the difference between Fedora and RHEL. Both sponsored by the same company, but the later is the more mature, “enterprise” version.
So instead of having FreeNAS and TrueNAS we’re going to have “TrueNAS Core” and “TrueNAS Enterprise”.
It’s honestly not that big of a shift from a practical perspective.
That sounds more like RHEL vs CentOS, really. ...which is fitting, since those two have also been slowly coming closer and closer to each other.
You'll see how stable is diversity.
Then package for windows xp. It probably works on windows vista, 7, 8 and 10.
Now I do see a lot of value in diversity. Resiliance, ethics, competition, collaboration...
Stability isn't one.
Also, you shouldn't be writing your own packaging scripts: leave those to distribution packagers. There are thousands of people who work on packaging these things, and the user of the distribution is much safer if they don't touch software distributed by random people.
This stuff is completely stable, just don't break the assumptions of the system without knowing what you're doing.
And for static linking: That is kind of happening with those modern snap and flatpack and whatever systems for handling applications, but it's bad for security. I want to update my system zlib in case there is an issue instead if depending on all applications consuming compressed unteusted streams updating their package in time. And I certainly don't want each little tool bundling their own Qt.
Or provide an app image and ignore most integration.
This is my point exactly: to get stability, you remove diversity.
Static linking, one packaging system, and you don't have to care about how diverse the universe it.
But it also means you don't benefit from what make those differences add: security updates, dependancy graph, automation, signing, jails, user documentation and training, os integration, native window theming, etc.
This shouldn't need to be done? The distribution's packagers handle most of this. Except for Nix, maybe? I hear they have a particularly fucked up ecosystem for packaging.
The chances your project matches the criterias to be included into any distrib repo are very low, and it's a lot of work and problems by itself.
They are not app stores you pay to get into. The gate keepers have a very strict opinion on what to let in and how. And it's all done manually, and fedora policy is not debian's is not gentoo's.
Plus, statically linked projects are almost never accepted. Back to square one.
Besides, what if it's not free software ?
And often fuck it up and introduce bugs or even vulnerabilities, intentionally ignore the developer, or simply fail to update packages in a reasonable time frame.
Relying on free labor to package software for you is a terrible terrible idea that helps keep Linux Desktop a shitshow.
I'm glad there is a layer there that will patch and configure to better integrate into the system and in some (very rare) cases remove user hostile "functionality".
This was a bug introduced in packaging. See https://lwn.net/Articles/281436/ for more details.
It is sandboxed, so your use case must be compatible.
It uses apparmor, what if the system uses SEL ?
It's sandboxed in a certain way, your app must support it.
It's very recent, only the latest distribs have a snapd release that works well.
It's slower to execute.
Snapd assumes systemd.
But wait, did you say snapd ? I though you said flatpack. Or appimages.
Anyway, despite all that, it is easier to write a snapd instead of a deb+rpm+whatever. I actually like this project a lot.
And again it proves my point: to get stability, we use snapd, a tool to compensate for diversity.
Anti-fragility is a lot more complicated then just having a lot of implementations.
The moving away from CVS and SVN to much more easily distributed revision controls is one of the best things that ever happened to large open source projects.
The reason for this is that when its very easy to loose contributors and users to forks then it enforces a lot of project management discipline on the part of the project leadership. Before when you held all the keys to the castle and it was difficult to move away it was very tempting for people to use their position to impose "political" restraints on other people.
And vastly reduced hosting costs thanks to things like github, gitlab, spread of cloud providers and so on and so forth makes it now cheaper then ever before.
And these things makes it easier to 'unfork' as well.
In this way we have the odd result of easy forking has a way of making it so that forking isn't necessary.
And when there is a major dispute in a particular community then cheap and easy forking (and recombining) means that people can actually have competing governance models and see which approach is actually better. Rather then just fighting until everybody gets burned out and abandons the project.
Lede vs Openwrt is a good example of this.
Libre Office vs Open Office.
Gnome vs Unity.
These things exist more due to competing governance models then anything else.
So this can be summarized as saying "improvements in anti-fragility in modern large open source projects is more due to the fluidity in which projects can be managed, forked, and recombined rather then just the number of implementations users and contributors can choose from"
:-)