Alsamixer was written only for the ALSA subsystem, not the BSD audio stack or OSSv4. That's a very shallow comparison if not completely pointless comparison Tobi.

KDE, GNOME, Xfce, etc. number of WMs do not make a GNU/Linux system. They are add-ons that aren't even required. Packages like grep, kmod, bash, glibc, make a GNU/Linux system though in actuality GNU is not entirely required as UNG/Linux aims to accomplish. GCC, binutils, make, etc. actually build the system but don't make it GNU/Linux. As far as editors, editors are actually optional. You have tee, sed, and cat to read and rewrite files or add in information from the terminal shell. Does KDE make a FreeBSD system? Does nano make OpenIndiana? No it doesn't. Bad comparison again Tobi.

So it's up from 3.3.8 to 3.4 as far as the kernel goes, oh so I was right then. Thanks for confirming that Tobi.

The problem is systemd shouldn't have to completely consolidate more and more. Existing tools have worked completely fine for years. Just because systemd is consolidated doesn't make it better. Larger projects have been known to have more problems than smaller modular projects. Again, go read the book The Cathedral and The Bazaar if you haven't. By fair comparison systemd is becoming what Xorg used to be. A cathedralistic monolithic project with tons of problems. Xorg today is verily much a dinosaur with problems out the wazoo. It became modular and moved to the bazaar model to try and address ongoing issues that are eventually going to be resolved through possibly the Wayland project. That remains to be seen though.

Even if a line of the journal is corrupted, that still makes the log less than useful, especially if the line corrupted was a critical readout. If the corruption is more widespread the log is even more useless, if not useless to an extent.

The kernel and system output stderr and stdout as plaintext anyway to either the terminal or a file, so why do we need to convert plaintext to binary to read it all as 1s and 0s? That's just adding a needless step to the process of making a clear and concise log file.

As far as anything using D-Bus outside of systemd, that's the choice of that developer to use the messagebus for that project. It may be a required dependency, but even then xfce-power-management is NOT a required part of the internal GNU/Linux system. It's part of a UI that's entirely optional, and therefore D-Bus is still optional.

You claim you debunk my arguments Tobi, but as I've clearly done, I've countered your arguments not just with facts, but common knowledge as well as good common sense as well.

The arguments still for systemd usage and adoption are weak at best, and only show that the project is not better or worse than the existing toolkits used to create a GNU/Linux based operating system.

1 members found this post helpful.

I disagree here. If a project is set up to specifically use kernel features that other kernels don't have then you can't blame the developers for not being compatible with kernels that lack those features.
The implications are only frightening to you if nobody is doing anything about it. The advantage of having all those blocks in one tree is that the development is more coordinated and the software relationships are better tested. So one possible way to start a competitor would be to go ahead and try to get the many "stand-alone building block" developers to cooperate better, maybe with an inter-project mailing list to address problems that occur between the projects. Additionally start a project that allows a distro developer to just set some switches to get a working Linux OS, like systemd does. A few of those exist, but they lack the inter-project communication, they are usually just Makefiles on steroids. This would help to make the life easier for distro developers which will in turn decrease the temptation to switch to systemd.
There are many things one can do to make systemd less attractive or other projects more attractive. Setting up a boycott website or arguing on forums are not one of them.

Lemmings. One jumps, they all jump.

systemd was written only for the Linux kernel using its advanced features, not for the BSD kernels lacking those features. The comparison is not shallow at all.
ANd again I disagree, it seems to me that you missed my point. You claim that systemd is not needed at all with its function of integrating the building blocks of an OS in one tree, because all those building blocks also exist as stand-alone versions. If you follow that through you also have to say that, for example, XFCE is worthless with its function of integrating the software needed for a DE, because all that integrated stuff also exists as a stand-alone version. To go even further, editors like nano are worthless because they integrate all the text editing features that are available stand-alone (like you said, cat, sed, awk, ...) in one program.
Again, not a bad comparison.
You are welcome. It is a known fact that certain versions of systemd will need a certain minimum kernel version. I fail to see where the problem is. If you don't want to upgrade your kernel for whatever reason, why do you have to upgrade your systemd to the latest version?
So it is OK for KDE, GNOME, XFCE, the kernel, ..., but not for systemd? Is that what you are saying?
How and why would the same scenario be better with plain text logs?
I am not quite sure if you are kidding here or if this really should be an argument.
A logfile is clear and concise by the way it is formatted and which content it has, not by the way it is stored on a medium. You may be shocked by the fact that the file system driver may do some weird stuff before storing the "plain text" and even the hardware, especially if you use a SSD with Sandforce style controller or a hardware RAID, will not store your plain text log in an easily human readable way.
As far as systemd using DBUS, that's the choice of the developers to use the messagebus for their project. It may be a required dependency, but even then systemd is NOT a required part of the internal GNU/Linux system. It is an init systems and software tree that is entirely optional (remember your own words that anything systemd does can be done with other projects also), and therefore DBUS is still optional.
Complaining about the dependencies of a project is completely useless, either you deal with it, fork it and remove/replace the dependency or use something different.
No, you haven't. You still come up again and again with the same "arguments" that were debunked time over time (some of them even in this very thread, like the "for systemd you need to adapt a large number of packages" claim) and explained to you many times (like the "everything runs in PID1" claim, also debunked in this very thread by a simple combination of ps and grep).
I still fail to see if you do this deliberately to make your point, or if there are other reasons, but nonetheless this seems to be your modus operandi.
That is what you think. Somehow most of the people doing the actual work of developing distros came to a different conclusion. The question is: Whom should I believe, people that develop distributions on large scales or people that repeat debunked myths on a forum.

And you can think what you think as well, but you really should take the time to actually learn what makes a real GNU/Linux system. You need to learn what is required and what is optional Tobi because all you've shown is clearly you don't know.

If and when you actually learn what makes a real GNU/Linux system, and then you'll have a respectful argument other than forwardly biased pro-systemd rhetoric.

Is Gentoo any less a distribution than Fedora? Gentoo doesn't include a desktop. All it supplies are build scripts. Is LFS any less a distribution? It's only a book to hand build a minimal working distrubution and doesn't really include a lot especially the Classic book and a few expansion books. Are any of these less a distribution of GNU/Linux that they can't produce or reproduce a working system with the traditional tools? Apparently, in the eyes of people like yourself Tobi, and the pro-systemd crowd, we've all gotten it wrong. Apparently, according to your words by what you feel defines a set of building blocks for GNU/Linux POSIX got it wrong, LSB got it wrong, every released UNIX got it wrong, BSD has always been wrong, and every fully working distribution that has been released since MMC Interm Linux first rolled out and paved the way forward have all been wrong.

If systemd is right, then ironically maybe Microsoft is right and Apple is right also, because apparently two companies and systems that thumbed their nose at sensibility and modularity should be the model of the future of not just GNU/Linux, but all UNIX and UNIX-like solutions out there. Solid thinking if you ask me. Apparently all this time we haven't even been using working systems, every distribution is broken, and when we've wasted enough time creating another cathedralistic monolithic operating system we'll finally have a real, true Linux system. Bloody brilliant!

Harrrrummmmmph ... come on girls, play nice, put those claws away and don't get personal.

That, or I'll call it quits and close the thread till tempers cool down.

So tell one of the lemmings to hold out its arms and block the others so that they turn back.

Poettering would chastise that lemming for propagating FUD. The rest of the lemmings would ignore the smart lemming and continue over the cliff.

1 members found this post helpful.

I'm only stating facts Tinkster, not recycled rhetoric.

If only we had more than one smart Lemming...

I was surprised when Debian jumped. I thought, with it being a "conservative" distro, they would resist such radical changes to Linux. They would have added more clout, more big guns, to the opposition.

Because the developers of Red Hat got a 1 billion dollar donation from IBM and money talks. KISS
Red Hat developers are the ones that made systemd

Instead, they abandoned the Debian policy of only adding well-tested software to the system and adopted a buggy systemd while it is still in development. Interesting, isn't it? I did not bother trying to solve the conundrum. I just said good-bye.

I pretty much know what a GNU/Linux system is, I have gone through LFS and have built several single purpose distros for work. Now tell me again, where is the GNU/Linux standard written down (and don't come with LSB, nobody is using that) and where does it say that a GNU/Linux system is not allowed to be build by building blocks from one source tree instead of stand-alone projects?

Wait, what? You were the one bringing "facts" to the discussion that were not only long debunked, but I know for sure that you have been educated about those misconceptions. Now I am the one that is somehow biased? Wow, just wow.

I tell you what, when you want to have a technical discussion about systemd maybe you should actually look at it. How much time have you spent analyzing the project, its goals, how it works, how many time have you spent actually using it to get hands-on knowledge? And now compare that time to the time you spent reading FUD sites like boycottsystemd.org.

Thinking about that, in the future I will answer to your systemd posts only to correct factual wrong information. Seeing how you argue here this will keep me busy enough.

Written down standards are there to bring uniformity like LSB, POSIX, and such, and they have worked very well throughout the years to accomplish a job that GNU/Linux has had a rough time getting clear since it was decided that GNU/Linux could not become a certified UNIX project.

So are you saying then that LSB and POSIX both are completely irrelevant and the software and statutes they've established are worthless now just because Poettering says so? The LSB isn't ironclad, and never has been, but it's been a viable diagram to establishing a flexible ground and base unit the same as POSIX has been. Maybe by that effort we should abandon the FHS as well since it isn't always exactly followed to the T. GNU/Linux even tries to follow the Single UNIX Specification as best it can.

These standards have been in place with some flexibility for the longest times. So why such a rush to kick them to the curb?

And as for boycottsystemd.org, if you've read through the material, everything they've cited with resources is all based in factual evidence Tobi. There's even a response given by US government researchers as well regarding it. Yes there is some poking and sabre rattling done by the author, but the author's view points are clear that systemd is anti-standard and the author feels that he can make up the rules as he goes along. Because the only supposed "facts" about systemd come from only it's author, they are hardly facts at all then. So in essence... there are absolutely zero facts about systemd from non-biased sources if any exist.

It is what it is Tobi, nothing more and nothing less, ever.

And don't say I haven't tried using it. You don't even know half the work I do regarding my own systemd system I use for testing and such, so please don't make invalid assumptions on something you have no information on, nor ever will until given to you. I have at least five different systems of which three are LFS based I use with sysvinit, systemd, and Runit equally with Slackware and a FreeBSD system as well. Armin K's work at LFS has been very exemplary to get systemd into a stand-alone viable book. I don't have to like it, but I use it for research purposes to see what I can learn and use for my own purposes.

I was just reading about this on linux com. http://archive09.linux.com/articles/57213 <--here.

Its a brief explanation of why Ubuntu (and Mint) started using Upstart but includes a comparison of initV, systemD and Upstart. More helpfully it provides a general reason for the unhappiness with the sysV init that stimulated the invention of systemD. So it gives some helpful background information about what is being discussed.

3 members found this post helpful.