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: 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.