Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.
Once clang builds the kernel it will most likely also build systemd:-)
1. Many people do not like gnome; plus, how do you prove "soon any other desktop environment" is going to jump through the hoops thrown by systemd developers?
KWin (the KDE window manager) will depend on logind at the very least for wayland. ConsoleKit is dead, so anything currently using that will need to look for an replacement soon. That includes basically every DE out there.
Some might come up with a different solution, some may function without logind, some will just require logind like gnome does now. Let's wait and see how that will work out.
2. Not all people, who happen to like some of systemd's features, need to agree with everything provided with systemd. Systemd-style process supervision -- okay perhaps; logind/journald/networkd -- why the hell?
You are aware that logind, journald and networkd are all stand-alone daemons that just happen to integrate well with systemd-PID1 and that live in the same source code repository? You do not want them? Just disable them.
Journald is a bit of an exception here: It basically provides the logging infrastructure for the other parts of the project. So all you can do there is to have it forward the logs to syslog.
3. Removal of journald removes some nic(h?)e features, but also brings about merits, for example reduction of log corruption, which might happen to be one reason people fond of some systemd features feel unsatisfied with systemd. Yes, you have counterarguments, but I have as well; you'd better get a degree in hypnosis before assuming all people will agree with you. And btw, systemd developers seem to like saying something like "don't like it? then make your own", which does not seem suitable now;)
I entirely fail to see why binary logs are such a big argument, considering that syslog is fully supported. Push your stuff there, RHEL7 apparently even does that by default. You still get more information into your logs that way than you used to. So you win, independent of whether you use journalctl or cat on the files syslog creates to read them.
4. OpenBSD develops system-bsd to mimic systemd interface because of increased hooking of FOSS into systemd (and not necessarily because systemd is good;). BTW, why do FreeBSD's choice need to be exclusive? Does porting launchd affects the plausiblity of contributing to uselessd? Yes, manpower maybe, and it seems really nice of you to care about FreeBSD's human resources instead of themselves;D
No, but then FreeBSD is of course free to have several init systems if they care. Traditionally they do seem to prefer a more consistent user-space developed by one team.
5. So now it's about the portability vs. exclusive feature issue? I'm not sure, either, but maybe in a different sense 8)
I do not get what you are going at with this point.
6. So glibc is also the dominant libc on routers and a lot of other "niche" platforms?
Yeap, it is getting more and more common, even on embedded hardware. There is so much software out there that is basically untested on anything but glibc that it makes sense to use that libc if you do not write everything in-house.
7. Again, please earn your degree in hypnosis before you use "we" instead of "I", really ^_^
I used "we" exactly once and I am pretty sure there will be very few people indeed that defend the crontab syntax.
I wonder if you realize that your post boils down to a longer version of this:
for all features X removed from Systemd, to achieve X in a replacement init, you must add Systemd back again.
In other words, it appears that you've been so indoctrinated by Systemd that you can't even conceive that there are structural alternatives possible for each feature X.
Well there are, unlimited numbers of them.:P
I am in no way talking about features of any replacement init. I am talking about interfaces other applications are depending on.
This may be udev, or the hostname/data/time configuration or logind or whatever else. Fact is that gnome is depending on some of these interfaces. KDE announced that they will do the same -- at the very least for wayland. I doubt that the other DEs will be far behind, especially now that ubuntu wants to move to systemd, too. These interfaces are apparently not all bad, so developers want to use them.
So if you want to run any of these applications, then you need to provide these interfaces in one way or another. This can be by either using systemd, or systemd-shim or systembsd or whatever implementation. There are quite a few to choose from at this point:-) For a new project to remove all that code and claim it is not needed is naive at best.
The features provided by the init system itself or how those are implemented is irrelevant to my point.
So this does *not* ship the things that are needed to run Gnome
I think that's a feature
It is a feature to some, a misfeature for others. It definitely does not make this uselessd a viable alternative to systemd for mainstream distros.
especially since much of the journald code still needs to stick around:
Well that right there shows that systemD is not modular and flexible
Not at all. It is just sound development: Come up with a interface you use in your code for the functionality you are using from others. That way you can have different implementations. In this case: Push logs to/dev/null, use journald or push it to syslog. Actually it is exactly what makes this flexible and modular.
First it implements the PID1 part of systemd, cutting out things like hostname, date and time management and logind. So this does *not* ship the things that are needed to run Gnome (or soon any other desktop environment). So you need systemd anyway... or a systemd shim or systembsd or whatever to provide the functionality that is missing.
It removes journald... and with it really nice features like systemctl status whatever showing the last bit of output from that unit. That is a huge step back, especially since much of the journald code still needs to stick around: It is the "internal" logging interface used in systemd. It just feeds it on to syslog now instead of writing it to disk, something you could do with one line of configuration.
Removal of udev? You need that functionality, so again you will need to install "real" systemd or some other piece of code replacing that. Again you could just reconfigure the "real" systemd to use any alternative implementation in place of its own.
Then it advertises that it is portable. The developer apparently spend time to make this run on FreeBSD, which is nice, but has anybody in that came ever asked for that? AFAIK they are working on something like Apples launchd. Any other of the BSDs that want systemd? Not that I am aware of.
Then it is portable to other compilers but gcc. Systemd uses gcc extensions that make for more robust code (e.g. destructors for variables). Ripping that out will just lead to more bugs, especially in the error-paths. Not sure that is worth the trouble.
Finally it is portable to other libcs. That is actually somewhat nice... even though glibc is the dominant libc implementation on linux systems (that are not android:-).
Then it removes some really convenient functionality like the timer units. Do we really want to go back to the cryptic crontab syntax? If the job there is somewhat complex it will most likely start a systemd unit anyway (for the security features, resource management, the way better logging or just the better job control). PID1-systemd needs to know the time anyway, and it needs to start jobs, so why not have it start jobs based on the current time? That is definitely less code -- and probably better tested, too -- than running an extra daemon for that rather trivial job.
It also removes the support for the security frameworks... "to stick to a more clearly defined purpose, one that is agnostic of such elements". Wow, that is just plain stupid. If you want to use these frameworks, then you want to have them in use *everywhere*. That is the whole purpose of those frameworks.
I cant be completely sure here, but there is a funny pattern I have noticed over the years that may explain your experience. Over and over again, I hear about problems that require these over-engineered solutions from people running over-engineered distros that I just cannot reproduce using my (cleaner) system. So I suspect somewhere in your excessively complex system you have managed to break apache in a way that I cannot reproduce using a simpler system.
Considering that reparenting processes that double fork is tried and true unix philosophy: It would be somewhat surprising to see apachectl properly clean up after itself in your so called cleaner system. Maybe you just fail to properly recreate the problems in your trimmed down universe?
And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.
None of the init systems currently in use is conceptually very complex. In the end sysv init is actually one of the more complex ones. The others are of course different, but I would not actually call them conceptually more complex.
In fact setting up a service and then starting it is significantly simpler with systemd (and upstart and openrc) than it is with sysv init. Give it a try before complaining about it.
Why would I care? I dont use that system and am not affected by their bugs.
Hmmm... why would you? Maybe because these are fundamental issues with how sysv init works?
I think you've lost sight of the purpose of an OS and the purpose of logs. An OS is not running for the sake of running an OS, and logs are not persistent structured application data, but ad-hoc information about the behaviour of the system for human consumption.
I am not talking about structured application data, I am talking about facts that go with the actual log message like the timestamp, the PID that the message originated from, the capabilities the process has that originated the message, the full filename of the process running, which cgroup the message originated from, which boot id this message belongs to (really nice if you want to see one boot/run/shutdown cycle only), that kind of data.
Having that information in the journal is really nice. Not having to parse it out of some textfile where some application put it in a more or less randomly selected format is even nicer. Correlating data from different log files written by different applications is a huge pain that is completely gone with journald.
They need to be filtered, sliced, and flattened as needed *post-facto* to be of any use. Given that you don't even know what I want to log, from where, how is that going to be normalised in a centralized journal? Will it let me query by anything more than straight filter on app or PID etc - like I can already do?
Yeap, it does. It makes full use of all the extra data it adds to the log entries and thus allows for way more reliable and powerful filtering, slicing and dicing:-)
I'll tell you when: when GNOME developpers took the path of making it all but impossible to have GNOME properly working with other init systems. And that's just the "I've had enough" point in time, not the one and only example.
So the GNOME project making a technical decision that makes their live easier is forcing something down your throat. You are being a bit egocentric, aren't you?
Some decision taken over the past years in various linux distributions have been taken not out of technical merit or discussion, but out of personal interests, or for political reasons. Sometimes it comes discreetly through some clever marketing that everyone swallows and when you notice it, it's already too late (systemd), sometimes through hostile takeovers (yes, Debian, I'm looking at you *cough* libav *cough*) where there is nothing you can do as a user because a few guys in power decide what is good for you.
Do you have prove for any of those claims? Where are the army of developers that do something about the decisions and flock to projects that are not falling for the propaganda? Or are you the only one that understands what is being played here?
Linux used to be about choice, but the list of these non-technically-based decisions that reduce our options is getting longer and longer recently.
This statement does not become true by repeating it.
FLOSS always had a strong "who does the work is right" approach. What the users say has always been secondary.
Whatever will happen, don't tell me that the many voices around objecting to systemd have been listened to or their objections to core-design problems addressed.
There are loud voices speaking out against systemd. Do not mistake that for many voices. In Debian the systemd oponents failed to find five people required to call for a vote to overturn the decision made by the technical committee! And that after all the fuss taht was raised during the discussion process.
systemd may very well be the best init software ever written, but then there is the manner. The way it's currently spreading its arms out of its role as an init system in a non UNIX way for political reasons, acting like a kernel above the kernel, is what most people are complaining about.
Why bother to write something that is as good as what was there before? Systemd tries to do more than init ever did, right. But much of that actually makes sense if you take the time to read up and think about it.
Just read this whole thread, yes there are trolls, but there are sensible people making reasonnable arguments. And what is the answer they're given: "you're holding it wrong".
I have seen very few reasonable argument levered against systemd in this thread. But then what can you expect from a thread that has an april fools joke listed as a fact?
I mostly see misinformed or uninformed posts. What can you tell people that form a strong opinion on something without bothering to learn about it first? "You're holding it wrong" is actually a rather polite way to put it IMHO:-)
No it one of systemd's goals to manage a system reliably.
Processes that double fork end up with the init process as its parent in the process tree: That is unix-philosophy at work and apache is not to blame here.
That makes it really hard to manage things like apache without additional concepts like cgroups. Those are actually not complex nor do they require lots of code to be implemented, but they need to be managed in a central place to be useful. So systemd does that right in the init process so that you get maximum benefit from the concept.
Most packages do not depend on systemd being PID1, they depend on other things that found a home in the systemd repository. One big thing is of course udev for things that are close to the hardware. The other big thing is user session management. Basically systemd can replace all the custom start-up-the-desktop-environment code that all the desktops implement to make sure all their services get started and keep running. Then there is logind which manages who is logged in where and who has access to which keyboard/graphics card/mouse/etc. That is pretty essential for any modern desktop environment, too.
Note that all these interesting things are interfaces that can be implemented for other init systems as well. Unfortunately nobody stepped forward to do so yet. The implementations found in systemd are tied to systemd being PID1 (more or less badly), since they e.g. use the systemd interfaces to manipulate cgroups.
So you want to have a tiny init process that spawns a bigger init process that does all the actual work? If the "big init" fails, then your system is hosed. If your "small init" fails, then the system is also hosed. Your proposal gets more code into the critical path, not less.
But then your problem is that other projects start to depend on systemd. What exactly are you objecting to here? That Systemd finally solves real world problems that developers face when implementing their software? Or that developers go ahead and fix the issues that they were unable to fix before? In the end you claim we should keep bugs open because some people on the internet are feeling uneasy.
Yes, there are bugs in systemd, just like there are bugs in sysv init -- even after decades of use. Yes, there will be some exploit sooner or later targetting systemd, just like there will be some for every other piece of software. But that should not stop people from improving the status quo.
Lennert and some other guys wrote a bit of code and went out to talk about it. They got feedback, and improved their code based on that feedback. At some point more people started to care about the code and so they contribute. Much later some other people sit down together and agree that this piece of software addresses problems they have, so they depend on that software -- either as something providing a service to their own software or as a basis for their distribution. At which point in the story does somebody grab you and forces a USB stick down your throat?
"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
That kill apache, not the crap it started and that forked itself away.
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.
That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your first sysv-init based Linux ever either;-)
I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.
"a more secure system by being able to isolate daemons from one another and the rest of the system."
A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.
At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?
With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.
A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.
"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"
You REALLY seem confused now. You have the players backwards.
the journal instead of a set of randomly formatted text-dumps all over/var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.
You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache
Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
a more secure system by being able to isolate daemons from one another and the rest of the system.
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.
Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.
Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.
The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.
If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.
You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.
That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.
If you think sysv init is not broken, then you must not have been using unix systems in earnest.
It is only simple till you want to have a reliable boot without races... BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?
You are aware that udev is part of that tree you are proposing to delete? With eSATA harddrives coming and going, projectors that get attached at random times, all kinds of gadgets with USB connectors? No thanks, I want something that I do not need to change a the boot script and then reboot when I plug in a mouse.
Let me keep systemd and go straight for a beer instead of bombing my system back into the 60s.
That way I can also update all the software I care about (much of it already depends on systemd or will do so soon), I get * the journal instead of a set of randomly formatted text-dumps all over/var/log, * a convenient way to kill apache with all the crap that it started, * a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there. * a more secure system by being able to isolate daemons from one another and the rest of the system. * a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
I do not see what you are going at: UTF-8, UTF-16 and UTF-32 are all different encodings of the same unicode characters. All of them can hold all defined unicode characters. I fail to see how Latin1 comes into the discussion... that is a subset of unicode that is available (just as all other unicode characters) in all unicode encodings. For a programmer it makes very little difference API-wise whether a string uses UTF-8, UTF-16 and UTF-32 internally.
UTF-16 does use a more RAM to hold a ASCII string than does UTF-8 (in fact twice as much). OTOH it uses less space than UTF-8 for most non-ASCII languages. So what is better depends mostly on which nationality you code for.
That is non-sense. Trolltech was very much not Nokia!
And even if: Both Trolltech and Nokia are no longer in the game. Nokia sold the Qt trademark (along with most of the Qt devs) to Digia about two years ago. Qt was long gone when Microsoft bought Nokia.
I am still pretty sure Digia will not come after you to shake you down for all your profits. Digia is a small company (compared to Nokia at least). Heck, Digia does not even own patents AFAICT.
First I am almost 100% sure that there will be some idiots employed by Intel somewhere. Every big company has some of those around. So "works for company X or Y" is not a qualification in my book.
Second Dirk is making it very clear that he is speaking as a private person about a hobbyist project of his, not as an employee of some company. So there is no reason to bring the company into the discussion. People will misread the headline to mean that this is something that Intel is doing. Just check this thread: One misguided individual is asking: "How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing?".a couple of comments down. It is not Intel speaking, it is not even "their developers". It is just one single guy speaking about something that is not related in any way to what Intel does. These misunderstandings were needlessly created by the headline.
Seriously: This is slashdot. How many people here on slashdot bother reading more than the headline?:-)
You are aware that you this is a project founded by Linus himself and that Dirk is involved with open source development since 1988, often working at the kernel and other core infrastructure you are likely to use if you run Linux?
I somehow doubt that these two are not aware of how open source works. I am further convinced that they are bright enough to figure things out on their own by reading the code and/or using the internet.
Sorry, but that is non-sense. C++ support has always been and will always be a focus of Qt development.
During Nokia times the QWidgets were considered to be "done" in the sense that there were no new exciting features expected to happen. But then widgets are pretty well used for years, pretty complete (all the standard stuff is there and you will need to write the rest anyway) and the APIs were hammered down ages ago. Bugs were going to be fixed as they are reported, so the code was and is fully supported. I think you are referring to this... it was awfully badly communicated back then and did raise quite a ruckus.
That was the state when Nokia was still at the helm: Digia is putting way more resources into "classic desktop parts" than Nokia did and with that widgets do see more love again.
How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason?
Canonical did not ditch gnome3: They used all the bits and pieces and just replaced desktop itself. Unity was written in GTK, just like gnome, so there was no productivity win there. And the problem was IIRC more that way the switch was communicated (or better: not communicated) than the switch itself.
Are you now going to flame Intel because their developers are saying the same thing?
It is Dirk speaking here, not Intel. He makes that very clear during his presentation. Dirk just happens to work for Intel -- which somehow makes this newsworthy. This is definitely not Intel that made the announcement to not like GTK anymore.
Slashdot Mirror
If that interface isn't easily replaceable, you have a problem.
Why should it be replaceable? It is internal. You are fine as long as you can attach everything you need as some kind of backend to that interface.
Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.
Once clang builds the kernel it will most likely also build systemd:-)
Oh, come on... *ALL* init systems do IPC. That might just be a simple pipe somewhere, but that is still IPC. How do you think telinit works?
1. Many people do not like gnome; plus, how do you prove "soon any other desktop environment" is going to jump through the hoops thrown by systemd developers?
KWin (the KDE window manager) will depend on logind at the very least for wayland. ConsoleKit is dead, so anything currently using that will need to look for an replacement soon. That includes basically every DE out there.
Some might come up with a different solution, some may function without logind, some will just require logind like gnome does now. Let's wait and see how that will work out.
2. Not all people, who happen to like some of systemd's features, need to agree with everything provided with systemd. Systemd-style process supervision -- okay perhaps; logind/journald/networkd -- why the hell?
You are aware that logind, journald and networkd are all stand-alone daemons that just happen to integrate well with systemd-PID1 and that live in the same source code repository? You do not want them? Just disable them.
Journald is a bit of an exception here: It basically provides the logging infrastructure for the other parts of the project. So all you can do there is to have it forward the logs to syslog.
3. Removal of journald removes some nic(h?)e features, but also brings about merits, for example reduction of log corruption, which might happen to be one reason people fond of some systemd features feel unsatisfied with systemd. Yes, you have counterarguments, but I have as well; you'd better get a degree in hypnosis before assuming all people will agree with you. And btw, systemd developers seem to like saying something like "don't like it? then make your own", which does not seem suitable now ;)
I entirely fail to see why binary logs are such a big argument, considering that syslog is fully supported. Push your stuff there, RHEL7 apparently even does that by default. You still get more information into your logs that way than you used to. So you win, independent of whether you use journalctl or cat on the files syslog creates to read them.
4. OpenBSD develops system-bsd to mimic systemd interface because of increased hooking of FOSS into systemd (and not necessarily because systemd is good ;). BTW, why do FreeBSD's choice need to be exclusive? Does porting launchd affects the plausiblity of contributing to uselessd? Yes, manpower maybe, and it seems really nice of you to care about FreeBSD's human resources instead of themselves ;D
No, but then FreeBSD is of course free to have several init systems if they care. Traditionally they do seem to prefer a more consistent user-space developed by one team.
5. So now it's about the portability vs. exclusive feature issue? I'm not sure, either, but maybe in a different sense 8)
I do not get what you are going at with this point.
6. So glibc is also the dominant libc on routers and a lot of other "niche" platforms?
Yeap, it is getting more and more common, even on embedded hardware. There is so much software out there that is basically untested on anything but glibc that it makes sense to use that libc if you do not write everything in-house.
7. Again, please earn your degree in hypnosis before you use "we" instead of "I", really ^_^
I used "we" exactly once and I am pretty sure there will be very few people indeed that defend the crontab syntax.
I wonder if you realize that your post boils down to a longer version of this:
In other words, it appears that you've been so indoctrinated by Systemd that you can't even conceive that there are structural alternatives possible for each feature X.
Well there are, unlimited numbers of them. :P
I am in no way talking about features of any replacement init. I am talking about interfaces other applications are depending on.
This may be udev, or the hostname/data/time configuration or logind or whatever else. Fact is that gnome is depending on some of these interfaces. KDE announced that they will do the same -- at the very least for wayland. I doubt that the other DEs will be far behind, especially now that ubuntu wants to move to systemd, too. These interfaces are apparently not all bad, so developers want to use them.
So if you want to run any of these applications, then you need to provide these interfaces in one way or another. This can be by either using systemd, or systemd-shim or systembsd or whatever implementation. There are quite a few to choose from at this point:-) For a new project to remove all that code and claim it is not needed is naive at best.
The features provided by the init system itself or how those are implemented is irrelevant to my point.
So this does *not* ship the things that are needed to run Gnome
I think that's a feature
It is a feature to some, a misfeature for others. It definitely does not make this uselessd a viable alternative to systemd for mainstream distros.
especially since much of the journald code still needs to stick around:
Well that right there shows that systemD is not modular and flexible
Not at all. It is just sound development: Come up with a interface you use in your code for the functionality you are using from others. That way you can have different implementations. In this case: Push logs to /dev/null, use journald or push it to syslog. Actually it is exactly what makes this flexible and modular.
This project is indeed useless:-)
First it implements the PID1 part of systemd, cutting out things like hostname, date and time management and logind. So this does *not* ship the things that are needed to run Gnome (or soon any other desktop environment). So you need systemd anyway... or a systemd shim or systembsd or whatever to provide the functionality that is missing.
It removes journald... and with it really nice features like systemctl status whatever showing the last bit of output from that unit. That is a huge step back, especially since much of the journald code still needs to stick around: It is the "internal" logging interface used in systemd. It just feeds it on to syslog now instead of writing it to disk, something you could do with one line of configuration.
Removal of udev? You need that functionality, so again you will need to install "real" systemd or some other piece of code replacing that. Again you could just reconfigure the "real" systemd to use any alternative implementation in place of its own.
Then it advertises that it is portable. The developer apparently spend time to make this run on FreeBSD, which is nice, but has anybody in that came ever asked for that? AFAIK they are working on something like Apples launchd. Any other of the BSDs that want systemd? Not that I am aware of.
Then it is portable to other compilers but gcc. Systemd uses gcc extensions that make for more robust code (e.g. destructors for variables). Ripping that out will just lead to more bugs, especially in the error-paths. Not sure that is worth the trouble.
Finally it is portable to other libcs. That is actually somewhat nice... even though glibc is the dominant libc implementation on linux systems (that are not android:-).
Then it removes some really convenient functionality like the timer units. Do we really want to go back to the cryptic crontab syntax? If the job there is somewhat complex it will most likely start a systemd unit anyway (for the security features, resource management, the way better logging or just the better job control). PID1-systemd needs to know the time anyway, and it needs to start jobs, so why not have it start jobs based on the current time? That is definitely less code -- and probably better tested, too -- than running an extra daemon for that rather trivial job.
It also removes the support for the security frameworks... "to stick to a more clearly defined purpose, one that is agnostic of such elements". Wow, that is just plain stupid. If you want to use these frameworks, then you want to have them in use *everywhere*. That is the whole purpose of those frameworks.
I cant be completely sure here, but there is a funny pattern I have noticed over the years that may explain your experience. Over and over again, I hear about problems that require these over-engineered solutions from people running over-engineered distros that I just cannot reproduce using my (cleaner) system. So I suspect somewhere in your excessively complex system you have managed to break apache in a way that I cannot reproduce using a simpler system.
Considering that reparenting processes that double fork is tried and true unix philosophy: It would be somewhat surprising to see apachectl properly clean up after itself in your so called cleaner system. Maybe you just fail to properly recreate the problems in your trimmed down universe?
And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.
None of the init systems currently in use is conceptually very complex. In the end sysv init is actually one of the more complex ones. The others are of course different, but I would not actually call them conceptually more complex.
In fact setting up a service and then starting it is significantly simpler with systemd (and upstart and openrc) than it is with sysv init. Give it a try before complaining about it.
Why would I care? I dont use that system and am not affected by their bugs.
Hmmm... why would you? Maybe because these are fundamental issues with how sysv init works?
I think you've lost sight of the purpose of an OS and the purpose of logs. An OS is not running for the sake of running an OS, and logs are not persistent structured application data, but ad-hoc information about the behaviour of the system for human consumption.
I am not talking about structured application data, I am talking about facts that go with the actual log message like the timestamp, the PID that the message originated from, the capabilities the process has that originated the message, the full filename of the process running, which cgroup the message originated from, which boot id this message belongs to (really nice if you want to see one boot/run/shutdown cycle only), that kind of data.
Having that information in the journal is really nice. Not having to parse it out of some textfile where some application put it in a more or less randomly selected format is even nicer. Correlating data from different log files written by different applications is a huge pain that is completely gone with journald.
They need to be filtered, sliced, and flattened as needed *post-facto* to be of any use. Given that you don't even know what I want to log, from where, how is that going to be normalised in a centralized journal? Will it let me query by anything more than straight filter on app or PID etc - like I can already do?
Yeap, it does. It makes full use of all the extra data it adds to the log entries and thus allows for way more reliable and powerful filtering, slicing and dicing:-)
I'll tell you when: when GNOME developpers took the path of making it all but impossible to have GNOME properly working with other init systems. And that's just the "I've had enough" point in time, not the one and only example.
So the GNOME project making a technical decision that makes their live easier is forcing something down your throat. You are being a bit egocentric, aren't you?
Some decision taken over the past years in various linux distributions have been taken not out of technical merit or discussion, but out of personal interests, or for political reasons. Sometimes it comes discreetly through some clever marketing that everyone swallows and when you notice it, it's already too late (systemd), sometimes through hostile takeovers (yes, Debian, I'm looking at you *cough* libav *cough*) where there is nothing you can do as a user because a few guys in power decide what is good for you.
Do you have prove for any of those claims? Where are the army of developers that do something about the decisions and flock to projects that are not falling for the propaganda? Or are you the only one that understands what is being played here?
Linux used to be about choice, but the list of these non-technically-based decisions that reduce our options is getting longer and longer recently.
This statement does not become true by repeating it.
FLOSS always had a strong "who does the work is right" approach. What the users say has always been secondary.
Whatever will happen, don't tell me that the many voices around objecting to systemd have been listened to or their objections to core-design problems addressed.
There are loud voices speaking out against systemd. Do not mistake that for many voices. In Debian the systemd oponents failed to find five people required to call for a vote to overturn the decision made by the technical committee! And that after all the fuss taht was raised during the discussion process.
systemd may very well be the best init software ever written, but then there is the manner. The way it's currently spreading its arms out of its role as an init system in a non UNIX way for political reasons, acting like a kernel above the kernel, is what most people are complaining about.
Why bother to write something that is as good as what was there before? Systemd tries to do more than init ever did, right. But much of that actually makes sense if you take the time to read up and think about it.
Just read this whole thread, yes there are trolls, but there are sensible people making reasonnable arguments. And what is the answer they're given: "you're holding it wrong".
I have seen very few reasonable argument levered against systemd in this thread. But then what can you expect from a thread that has an april fools joke listed as a fact?
I mostly see misinformed or uninformed posts. What can you tell people that form a strong opinion on something without bothering to learn about it first? "You're holding it wrong" is actually a rather polite way to put it IMHO:-)
There are several. https://tim.siosm.fr/blog/2014... is the first one that come up googling for the headline of the ewontfix article.
No it one of systemd's goals to manage a system reliably.
Processes that double fork end up with the init process as its parent in the process tree: That is unix-philosophy at work and apache is not to blame here.
That makes it really hard to manage things like apache without additional concepts like cgroups. Those are actually not complex nor do they require lots of code to be implemented, but they need to be managed in a central place to be useful. So systemd does that right in the init process so that you get maximum benefit from the concept.
Most packages do not depend on systemd being PID1, they depend on other things that found a home in the systemd repository. One big thing is of course udev for things that are close to the hardware. The other big thing is user session management. Basically systemd can replace all the custom start-up-the-desktop-environment code that all the desktops implement to make sure all their services get started and keep running. Then there is logind which manages who is logged in where and who has access to which keyboard/graphics card/mouse/etc. That is pretty essential for any modern desktop environment, too.
Note that all these interesting things are interfaces that can be implemented for other init systems as well. Unfortunately nobody stepped forward to do so yet. The implementations found in systemd are tied to systemd being PID1 (more or less badly), since they e.g. use the systemd interfaces to manipulate cgroups.
So you want to have a tiny init process that spawns a bigger init process that does all the actual work? If the "big init" fails, then your system is hosed. If your "small init" fails, then the system is also hosed. Your proposal gets more code into the critical path, not less.
But then your problem is that other projects start to depend on systemd. What exactly are you objecting to here? That Systemd finally solves real world problems that developers face when implementing their software? Or that developers go ahead and fix the issues that they were unable to fix before? In the end you claim we should keep bugs open because some people on the internet are feeling uneasy.
Yes, there are bugs in systemd, just like there are bugs in sysv init -- even after decades of use. Yes, there will be some exploit sooner or later targetting systemd, just like there will be some for every other piece of software. But that should not stop people from improving the status quo.
Lennert and some other guys wrote a bit of code and went out to talk about it. They got feedback, and improved their code based on that feedback. At some point more people started to care about the code and so they contribute. Much later some other people sit down together and agree that this piece of software addresses problems they have, so they depend on that software -- either as something providing a service to their own software or as a basis for their distribution. At which point in the story does somebody grab you and forces a USB stick down your throat?
"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
That kill apache, not the crap it started and that forked itself away.
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.
That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your first sysv-init based Linux ever either;-)
I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.
"a more secure system by being able to isolate daemons from one another and the rest of the system."
A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.
At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?
With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.
A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.
"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"
You REALLY seem confused now. You have the players backwards.
Read a couple of man-pages and see for yourself.
the journal instead of a set of randomly formatted text-dumps all over /var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.
You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache
Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
a more secure system by being able to isolate daemons from one another and the rest of the system.
So, its a startup daemon AND a kernel, huh?
Check out http://www.freedesktop.org/sof... , especially all the options starting with "Private" there.
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.
Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.
Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.
The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.
If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.
You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.
That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.
Read the code, it is actually pretty ok.
No, but it can start a service for you that can.
If you think sysv init is not broken, then you must not have been using unix systems in earnest.
It is only simple till you want to have a reliable boot without races... BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?
You are aware that udev is part of that tree you are proposing to delete? With eSATA harddrives coming and going, projectors that get attached at random times, all kinds of gadgets with USB connectors? No thanks, I want something that I do not need to change a the boot script and then reboot when I plug in a mouse.
Let me keep systemd and go straight for a beer instead of bombing my system back into the 60s.
That way I can also update all the software I care about (much of it already depends on systemd or will do so soon), I get /var/log,
* the journal instead of a set of randomly formatted text-dumps all over
* a convenient way to kill apache with all the crap that it started,
* a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
* a more secure system by being able to isolate daemons from one another and the rest of the system.
* a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Sheesh:-)
I do not see what you are going at: UTF-8, UTF-16 and UTF-32 are all different encodings of the same unicode characters. All of them can hold all defined unicode characters. I fail to see how Latin1 comes into the discussion... that is a subset of unicode that is available (just as all other unicode characters) in all unicode encodings. For a programmer it makes very little difference API-wise whether a string uses UTF-8, UTF-16 and UTF-32 internally.
UTF-16 does use a more RAM to hold a ASCII string than does UTF-8 (in fact twice as much). OTOH it uses less space than UTF-8 for most non-ASCII languages. So what is better depends mostly on which nationality you code for.
That is non-sense. Trolltech was very much not Nokia!
And even if: Both Trolltech and Nokia are no longer in the game. Nokia sold the Qt trademark (along with most of the Qt devs) to Digia about two years ago. Qt was long gone when Microsoft bought Nokia.
I am still pretty sure Digia will not come after you to shake you down for all your profits. Digia is a small company (compared to Nokia at least). Heck, Digia does not even own patents AFAICT.
First I am almost 100% sure that there will be some idiots employed by Intel somewhere. Every big company has some of those around. So "works for company X or Y" is not a qualification in my book.
Second Dirk is making it very clear that he is speaking as a private person about a hobbyist project of his, not as an employee of some company. So there is no reason to bring the company into the discussion. People will misread the headline to mean that this is something that Intel is doing. Just check this thread: One misguided individual is asking: "How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing?".a couple of comments down. It is not Intel speaking, it is not even "their developers". It is just one single guy speaking about something that is not related in any way to what Intel does. These misunderstandings were needlessly created by the headline.
Seriously: This is slashdot. How many people here on slashdot bother reading more than the headline? :-)
You are aware that you this is a project founded by Linus himself and that Dirk is involved with open source development since 1988, often working at the kernel and other core infrastructure you are likely to use if you run Linux?
I somehow doubt that these two are not aware of how open source works. I am further convinced that they are bright enough to figure things out on their own by reading the code and/or using the internet.
Sorry, but that is non-sense. C++ support has always been and will always be a focus of Qt development.
During Nokia times the QWidgets were considered to be "done" in the sense that there were no new exciting features expected to happen. But then widgets are pretty well used for years, pretty complete (all the standard stuff is there and you will need to write the rest anyway) and the APIs were hammered down ages ago. Bugs were going to be fixed as they are reported, so the code was and is fully supported. I think you are referring to this... it was awfully badly communicated back then and did raise quite a ruckus.
That was the state when Nokia was still at the helm: Digia is putting way more resources into "classic desktop parts" than Nokia did and with that widgets do see more love again.
How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason?
Canonical did not ditch gnome3: They used all the bits and pieces and just replaced desktop itself. Unity was written in GTK, just like gnome, so there was no productivity win there. And the problem was IIRC more that way the switch was communicated (or better: not communicated) than the switch itself.
Are you now going to flame Intel because their developers are saying the same thing?
It is Dirk speaking here, not Intel. He makes that very clear during his presentation. Dirk just happens to work for Intel -- which somehow makes this newsworthy. This is definitely not Intel that made the announcement to not like GTK anymore.