Regarding Unix philosophy, not so. I always encourage Pat to do what he needs to do to compete. He has to maintain a full KDE desktop or be stuck with Xfce and the classic window managers. He has to maintain everything that goes with modern hot-pluggable gadgets. At work, I need Samba and BIND, maybe ntpd, and hope to have a recent set of GNU development tools; everything else is optional. IMO, these daemons will be among the last to force Linux users to use systemd. Additionally, while the kernel developers still cater to the embedded systems crowd, I should be able to keep any related underpinnings out of the kernel. If Pat has to migrate to systemd due to lack of options, I'll respect his viewpoint. I'll still have options for a while, though.

I don't think it's that simple.

Debian can make it optional, in theory. As systemd continues to grow outside of init it will become harder to avoid, unless people continue to shim around it - hardly a good solution.

Linux's diverse nature has made standardisation very seductive for everyone (logind is attractive, as are the GNU ersatz components that systemd is replacing), but this doesn't mean it is the best way. It's just one way. It's also particularly bad news for portability which has been hugely positive for open source over the years.

There is also the important issue of Lennart not really caring about bugs (there's loads of examples of him being dismissive on Bugzilla); for example NFS mounts using established methods (fstab) is inconsistent and systemd's service dependency resolution misbehaves in some not uncommon scenarios.

I trust Slackware to do the right thing, and for the record I've been using systemd on some Arch and Gentoo boxes for a couple of years. I like the principle of it, just not the steamroller adoption method. I am also greatly concerned portability will suffer on the large projects. We've seen this already with GNOME. In the future it may be very difficult to run Wayland and perhaps things like KDE, although the latter has made some reassuring noises.

Remember, what is good for Redhat is not necessarily good for everyone.

5 members found this post helpful.

Because it's the most active forum in here and in the end it's all just Linux.

7 members found this post helpful.

At first, I am not playing for any team, I am making a solo play here. My opinion is entirely mine and you are of course free to think of it what you want.

Regarding my change from being a systemd opponent to becoming a systemd proponent, it is quite simple: as I stated on forums.debian.net already I was not opposed to the ideas of systemd, but did not trust the developers regarding their behavior to deliver a stable system running at the very core of my systems. Funnily, it was my move to Gentoo that enabled to do a deeper evaluation of systemd on the systems I use every day while still having OpenRC as backup and for comparison. I came to the conclusion that for me systemd is the better option, I find it easier to use and even though I use Gentoo's development branch I never got hit by a bug in systemd.

I personally don't think that a change in my opinion based on my experience with and evaluation of systemd is a bad thing. In fact, I even recommend to anyone interested in this topic to do an extensive test drive of systemd with an open mind (read: don't rate it bad just because it works different than sysvinit).

3 members found this post helpful.

The part of the UNIX philosphy mostly cited when it comes to systemd is that software should do only one thing and do it well. I can't comment on the "do it well" part, since I yet have to give them a testrun, but I can comment on the "do one thing" part: both mentioned filesystems do not do only one thing. ZFS, for example, implements not only the filesystem parts, but also functionality for RAID, volume management and snapshots/backups (in one big binary).
Far from adhering to the UNIX philosophy, but nonetheless nobody complains that, but often times it is even endorsed by the same people calling projects other projects "unUNIXy" or "suffering from feature creep".

2 members found this post helpful.

Someone was looking for old isos, so I dug out Red Hat 5.1 (Hurricane) May 1998. README:
Heh.
Same as it ever was. Yet Slackware still exists. Hmm. Here's a screenshot of their installer (before burn-all-gifs!) with humor. Slint hint, haha.

Attached Thumbnails

 

2 members found this post helpful.

I agree that UNIX philosophy works best as a set of design and engineering principles that have been well tested over the years. Not everything is going to adhere perfectly, but it's a set of very sound aims.

systemd's coupling is rigid. More so than anything in Linux's history. The fact you can't take it out without some difficulty should be worrisome, and it is that which is causing the shaky nerves around some parts of the community.

6 members found this post helpful.

You've made your point once already and you've made it twice now.
That's not inviting, not constructive and quite enough.

ZFS is a rather poor and backwards comparison to use against the UNIX Philosophy.

ZFS was originally designed to be a volume and file system management system that encompassed all it's intended functions. Sun Microsystems designed it to be just that for their Solaris and OpenSolaris Operating systems. There was no mission creep or feature creep as you claim. The only "creep" that's been done has been the reintroduction of functionality on the various system ports and slight handling improvements geared towards different types of storage media like SSD drives and network storage.

If anything ZFS completely adhered to the UNIX Philosophy, or something similar, from Day 1, so unless you wish to say adding Solid State Drive support was philosophy breaking, then honestly, you're dead wrong.

If that's the case then let's compare ARM versus X86 support by software on all accounts int he same light. It's a poor comparison at best to say "adding support of hardware type" is the same as "importing completely reciprocal features XYZ to software project B that does the same as software D, H, and K".

Of course it is.

My point was that Archlinux has jumped through most of the systemd's quirks by now.

So systemd is simply better integrated and documented than it will be on early/potentially upcoming Slackware-based releases.

Yes it did many years ago as a matter of fact.

What would be bad about that? Why must an OS have a "full-featured" DE with a host of features activated by point-and-click? If not having Gnome does not make Slackware unappealing or "uncompetitive"*, why should not having KDE do so?

* Other than the very few distributions owned by companies, when did competition enter the equation? I did not realise Patrick was competing with anyone.

Just so that I get it: You claim that after the filesystem and volume management parts where implemented the development of ZFS basically froze and no new features besides SSD support where added? You also claim that the principle of "do one thing and do it well" does not apply to ZFS because it was designed from the beginning to do more than one thing?

If so, where is the difference to systemd?

ZFS is a volume and system file manager only. It does what exactly it's supposed to do and always has.

systemd was an init system starting out that branched out to include a login manager, cgroups manager, file system check utility, cron daemon manager, system log manager, etc.

I'd say that's very far outside the bounds of what ZFS did. I don't think you need to say more on where you stand with systemd Tobi, it's clearly obvious you keep trying to defend it at any cost using low-brow tactics and improper comparisons without any merit of foundation.

If that's the case we should consider scrutinizing ALSA for including it's own audio mixer dmix when we have other standalone mixers like JACK, ESounD, PulseAudio, aRTs, etc. and even forcing out OSS.

1 members found this post helpful.

Happy Halloween ;-}
https://lkml.org/lkml/2014/10/29/854

I assume that's for linux 3.19 (meaning we'll soon find out how the D-Bus part turns out).