SoylentNews is people
SoylentNews
After announcing his company was abandoning Unity for GNOME, Shuttleworth posted a thank-you note to the Unity community Friday on Google Plus, but added on Saturday:
"I used to think that it was a privilege to serve people who also loved the idea of service, but now I think many members of the free software community are just deeply anti-social types who love to hate on whatever is mainstream. When Windows was mainstream they hated on it. Rationally, Windows does many things well and deserves respect for those. And when Canonical went mainstream, it became the focus of irrational hatred too. The very same muppets would write about how terrible it was that IOS/Android had no competition and then how terrible it was that Canonical was investing in (free software!) compositing and convergence. Fuck that shit."
"The whole Mir hate-fest boggled my mind - it's free software that does something invisible really well. It became a political topic as irrational as climate change or gun control, where being on one side or the other was a sign of tribal allegiance. We have a problem in the community when people choose to hate free software instead of loving that someone cares enough to take their life's work and make it freely available."
Shuttleworth says that "I came to be disgusted with the hate" on Canonical's display server Mir, saying it "changed my opinion of the free software community."
Full story here.
(Score: 3, Insightful) by Grishnakh on Tuesday April 11 2017, @03:31AM (7 children)
Should all FOSS projects be equal, though some more equal than others?
Unfortunately, yes. What would you think if some small group decided to fork the Linux kernel, and make a different kernel that wasn't fully compatible, and then demanded that everyone write their software to work on that kernel too? And look at all the hoopla over systemd adoption (and at least there, most software isn't affected by the init system, only other low-level system services). There's a reason there's been a lot of pushes to try to standardize certain elements of the Linux/FOSS software stack, such as with LSB: fragmentation causes more problems than it solves. We should have learned this lesson long ago: the whole reason UNIX died is because of fragmentation. Windows came along offering a single, standard platform for high-end software vendors, and they all ended up abandoning UNIX because they could write one version for Win32 and be done, instead of having to write 5-10 different versions for UNIXes.
Should everyone just settle for whoever has the first-mover advantage in low-level software, regardless of the relative merits of each solution?
Remember too that Wayland wasn't the invention of some small group of outsiders: it was the product of the de facto group of FOSS display stack experts, the people who were already giving us X and the many important extensions to it which were badly needed for desktop Linux to work. Sorry if that sounds like an appeal to authority, but that team had already proven its worth and importance to the community with their X.org work, so it's perfectly reasonable that a small team from a single company acting against this standardization effort, in an apparent display of NIH, were shunned.
(Score: 5, Informative) by MadTinfoilHatter on Tuesday April 11 2017, @06:07AM (4 children)
at least there, most software isn't affected by the init system
Don't worry. The systemd devs are working hard on fixing that. [debian.org]
(Score: 5, Informative) by rleigh on Tuesday April 11 2017, @08:33AM (3 children)
That's a shame to see. But, there are two separate issues in that bug:
1) A gratuitous dependency of procps on libsystemd
2) The requirement to mount a separate /usr (if any) in the initramfs
The first is the real problem, dragging in unnecessary library dependencies in a minimalistic core tool. Extended functionality should likely be in a separate tool, or dynamically loaded from a module.
The latter was done ages ago (by me) when I was maintaining sysvinit, and is independent of any init system in use. There are numerous long-standing issues with mounting /usr part way through the init sequence, and this resolves all of them. It was done so that it would continue to work properly for all users, irrespective of their init system, with the exception of users *not* using an initramfs who were mounting a separate /usr. This subset of the userbase is vanishingly small. You can continue to boot without an initramfs if /usr is on /. And you can continue to use a separate /usr so long as you use an initramfs. It's the combination of the two that's not supported (separate /usr and no initramfs). I did a lot of work to make this minimally disruptive--you can even mount separate / and /usr from NFS in the initramfs. Even a separate encrypted /etc.
(Score: 2, Interesting) by Anonymous Coward on Tuesday April 11 2017, @04:37PM (2 children)
Back when I maintained procps, it only depended on libc. It didn't even trust libc very much. It was prepared for some kinds of kernel bug that could hang it, producing output until hitting the kernel problem. When I was asked to support SELinux, I insisted on doing so without the external library.
I gave up maintaining it. Sorry. I got a full-time job and had 10 kids. I also couldn't really deal with Red Hat hacking in incompatible changes, such as stealing command option letters that were reserved for other things. One can't say "no" to a distribution that is able to patch your code with piles of shit.
Now you know another way that free software projects die.
-- Albert Cahalan
(Score: 1) by DBeemer on Friday April 14 2017, @09:18AM
So you had 2 kids?
(Score: 2) by rleigh on Friday April 14 2017, @06:52PM
I'm in the same situation with some of my own software, and it was one of the reasons I ended up dropping sysvinit maintenance in Debian, and quitting the project entirely (RSI was the primary reason). As a lone volunteer, there's little a single person can do when faced with the juggernaut of paid commercial developers ramming their changes in. Times have changed a lot since free software development in the '90s. I don't like where things have ended up going.
Right now, I'm in the same situation as the tmux developers. My stuff won't work on a "modern" Linux system properly because it falls foul of the systemd session management and mount namespaces. But I don't really want to hack in special support logic and dependencies upon junk like libsystemd. Not just because it compromises the portability and maintainability, but also because I object to the necessity of "fixing" perfectly working code just because a bunch of people decided to break decades old systems programming contracts. I don't think breaking POSIX is at all acceptable, and I've moved more and more to FreeBSD as a result. If I had the same cavalier attitude to basic systems compatibility in my day job, I'd be fired for reckless incompetence, yet RedHat permit this as the foundation of their flagship enterprise product.
(Score: 3, Informative) by VLM on Tuesday April 11 2017, @01:45PM (1 child)
the whole reason UNIX died is because of fragmentation
That sounds very retcon-ish having lived thru that era the problem was tying hardware to software (before windows all OS came from your hardware mfgr just like OSX today) and both upfront cost and support costs were milked until people hated the OS provider. Also no security patches.
Back in the days before package managers and GNU autoconf and all that, it still wasn't all that much work to compile C from one machine on another. There was a lot of stupid address width assumptions in the old days. Also floating point was weird.
(Score: 0) by Anonymous Coward on Wednesday April 12 2017, @01:25AM
Agreed. Commercial Unix died because it was FAR more expensive (SW & RISC workstation HW were tied together) than Windows and PCs, and PCs running the new Windows NT were becoming more capable. That's it.
In the heyday of commercial Unix, software vendors happily developed their star product for only one or two Unix variants. This was back when only Unix HW & SW were up to the task.