Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Torvalds: No Opinion On Systemd
Soulskill posted 13 hours ago | from the linus-not-swearing-at-people dept.
Open Source 303
An anonymous reader writes:Linux creator Linus Torvalds is well-known for his strong opinions on many technical things. But when it comes to systemd, the init system that has caused a fair degree of angst in the Linux world, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," Torvalds says. "I don't personally mind systemd, and in fact my main desktop and laptop both run it." Torvalds added, "I think many of the 'original ideals' of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality."
Although reportedly neutral, actions speak louder than words. As the grandpappy of Linux and a prominent public figure in the Linux world, Mr. Torvalds admitted use of systemd is as good as an endorsement. Within the next 3 years systemd will likely spread to all major active distributions like a virus. I usually walk the line when it comes to conspiracy theories but something's fishy when Linus Torvalds has no strong opinion. My spidey sense is tingling...
800mhz, 512mb ram, dCore-jessie (Tiny Core with Debian Jessie packages) with BusyBox and Fluxbox.
Most don't have computer access, reuse or pay forward an old computer.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan
So what's wrong with systemd, really? (5, Insightful)
Endymion (12816) | yesterday | (#47926785)
(paraphrasing a previous post of mine, becuase more people should see this)
It breaks existing promises, and makes few new promises in return.
There has been a lot of talk about the various technical problems with systemd and its developers inexperience-betraying design decisions. As bad as those are, they miss the larger point. There has also been a lot of very important talk about philosophy of design ("the unix way") that again shows how little experience the developers have and their disregard for the work people have already done and will have to do to fix the systemd mess.
These topics are valid, but miss the larger problem that systemd represents and the threat it is to Free Software in the Linux ecosystem.
## The problem with systemd's design: embrace and extend [wikipedia.org] ##
As an excuse for all the vertical integration Poettering's cabal have been busy aglutenating into what they still sometimes claim is "justs an init system" has been the laughable claim that systemd is in any way "modular". They claim that "modular" is a *compile time* feature, or some property related to the fact that they build several ELF binaries. This is not modular, because it does not represent some form of stable, well-defined API.
What is an API (Application Programming Interface)? It's not a technical feature. It is not documentation that describes how to use some set of features. It is not a calling convention. So what is it?
An API is a PROMISE .
It is a social feature, not a technical one.
The functions and documentation are just a particular implementation of that promise. The key attribute that makes an API an API is that it is a promise by the developer: "If you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, I promise this set of functions will be stable and reliable".
Binding previously-separate features into one project is bad design, by itself, the problem with systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs (and breaking existing promises that developers relied on). His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable" (despite being good enough for RHEL), specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.
A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.
The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.
If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.
## systemd threatens the GPL ##
It goes without saying that many people would like to distribute various GPL licenced software and not be bound by the terms it requires. The fact that some of these same people use the courts to threaten people who do the same to their software is noted, but off topic for now. The problem is the linking clauses in the GPL. Link the wrong way with GPL software, and the so-called "viral" nature kicks in.
Systemd (via kdbus) are an end-run around this. By calling function calls "IPC", you don't have to link to the GPL licenced code. A lot of players are willing to take the loss in performance for the benefit of distributing GPL software "unmodified".
You may have noticed the "systemd way" (and to some extend, the "gnome way") has been to ONLY provide access across dbus (soon, kdbus) instead of providing a local library .so and .h you can use directly. When the "local" forms even exist, they are often poorly documented and usually unstable. You may have also noticed that for "compatability" (by fiat), the "not-systemd" replacements tend to talk over dbus, as that is the mandated "correct" interface.
Embracing and extending linux with systemd is only a tool. The goal here is a new form of "tivoization" - to let proprietary business use GPL code while never opening up their part.
Is this really what you want to support by using systemd?
//now that you know this, guess what the point of systemd's control of cgroups is really about
//hint: think proprietary/GPL isolation
Free Software Matters
Ash init durbatulûk, ash init gimbatul,
Ash init thrakatulûk agh burzum-ishi krimpatul.
My oldest used PC: 1999 imac 333Mhz 256MB PPC abandoned by Debian
The trouble with opinions is - such is the persuasiveness of the appeal to authority - that if Linux Torwalds were to endorse or not systemd, then a lot of other people who don't make a habit of thinking for themselves would probably do the same.
Over the last few months I've been reading forum posts about systemd but haven't so far formed my own opinion since I still don't know enough about it; however, I'm beginning to feel a little uneasy about its becoming - from jessie onwards - the default dependency-based system and service manager in substitution of sysvinit. I have yet to look at the whole systemd controversy and its implications for both servers and desktop systems but I remember having misgivings about the advent of Gnome3 and pulseaudio in wheezy when I was using squeeze with with Gnome 2, Compiz and OSS4. But the mate desktop has been included in jessie and so has oss4, so there continues to be choice but I see that sysvinit is currently available in testing only as a transitional package.
kedaha wrote:...I have yet to look at the whole systemd controversy and its implications for both servers and desktop systems but I remember having misgivings about the advent of Gnome3 and pulseaudio in wheezy when I was using squeeze with with Gnome 2, Compiz and OSS4. But the mate desktop has been included in jessie and so has oss4, so there continues to be choice but I see that sysvinit is currently available in testing only as a transitional package....
You can clearly see the big picture and appreciate the architectural issues and can make your own mind up. I personally oscillate between 'its just a new generation carrying the torch and doing things their own way' and 'this is a mudball of mutual dependencies that is going to shadow new developments for decades'.
At the end of the day, a kid with no money can still cadge a hand-me-down laptop and download ubuntustudio and start creating his/her own stuff, then push it out to YouTube/flickr/soundcloud/freesound and make a name. And - if Joey Hess gets his way and we keep xfce4 as the default desktop in Jessie - a small community in Brazil can download a Debian live iso using a mesh network, use dd to create a score of bootable USBs and use them effectively on P3/coppermine class hardware.
But also a large (but not huge) multinational can still play switcheroo with the systemd API spec and cause headaches for upstream, and possibly try an end run round the GPL.
Slackware will only stay Systemd-less for so long as it is convenient. They will eventually switch if maintaining other INIT systems becomes too difficult. The BSDs (from what I have studied so far) seem to be the ~only~ camp that seems to be solidly against Systemd. Go figure - Systemd was not intended for them. Yet. It will happen though eventually. Sure, there are other Distro's out there who seem to want to keep the torch burning for other INIT systems, but how long will they last given all the majors are gleefully hopping on the bandwagon? Upstream projects that matter seem to mostly all be ambivalent to Systemd.
Look. It really does not matter what torch one carries philosophically or politically when it comes to FOSS and Linux. One has to ask the questions though. What drove you to FOSS and Linux in the first place? Are you still in the same camp now? What real threat does Systemd bring to our beloved Debian?..
Forget the spin, hype, conspiracy theories, trolling, etc.. Seriously. Is Systemd going to kill Debian as we know and love her? Is it going to destroy the Social Contract and guidelines? Does it fly in the face of Ian's original concept? Do we still have freedom and choice within Debian that we should have after Jessie?
mardybear wrote:...something's fishy when Linus Torvalds has no strong opinion.
Yeah, "no opinion" from the only guy I can think of offhand who is more vocal about his opinions than I am is at best a deep anomaly, at worst profoundly troubling.
(Ok, ok, slightly more vocal.)
oswaldkelso wrote:Thanks I found this comment the most interesting...
An API is a PROMISE .
Wow, that commenter looks to have actually read Winograd & Flores. Awesome to see.
keithpeter wrote:...'this is a mudball of mutual dependencies that is going to shadow new developments for decades'.
This. Motives are deniable/debatable, but this is an unquestionable fact. (Just sayin')
