Don't panic and keep forking Debian
lists.dyne.org
lists.dyne.org
As it stands, after nearly three years using ubuntu desktop, I came to the conclusion that a windows license is very cheap by comparison. The amount of time and effort I spent wasted on package incompatibilities, instabilities, and debugging strange hardware/driver related issues isn't worth it. I keep linux in a VM where it's very easy and cheap to backup and rollback without affecting my data or ability to work. I really gave it a good try, and I liked a lot of things about the freedom to configure things like I want, without metro crapware infesting the place, but the downsides were just too much for me.
Again I wonder how things could have been if everyone was pulling as a coherent team instead of in different directions.
You basically can't use Linux without at some time going to the cmd line to fix some dam configuration or driver problem.
Chromebook and hybrid tablets are slowly eating into the "laptop" market. Many people will never buy a laptop because their tablet or phone does what they need. I know a lot of people who go weeks between opening their computer, but live on their phone and tablet. Desktop and laptop will be a thing people use at work for a long while, and it'll probably still be ruled by Windows. Creatives and developers will have beefy computers, and they'll probably still be running Windows and Mac OS X predominantly (though I use Fedora, and have never really worked on anything other than a Linux system). For now. I can't predict what will happen on that front, but phones and tablets are encroaching on so many fronts I never would have predicted (I just bought my first tablet last week, and thought they were ridiculous for years even after they'd started taking off).
Tablets and chromebooks have already been around for several years. Why do I still use a desktop for work? Why don't I just ssh everywhere from my eyepad?
Because they suck at making me productive.
Desktops and actual laptops are not going anywhere, because they run fully featured OSs that people can contribute to, not some nasty walled garden of corporate shrink-wrapped ToS turds and ignored pull requests (if you're so lucky to even come within barfing distance of a FOSS component on lobotomy-hardware).
Look, IBM started predicting the death of the desktop, what, 20 years ago? 30? It's not going to happen. Then laptops came around. They're gonna kill the desktop! O noes! Not gonna happen. Ultrabooks are gonna kill laptops! Yeah, maybe.. Depends on how much they wind up resembling good laptops.
Starts to sound pretty familiar after a while.
Please re-read my comment; I've already conceded the workplace will remain a desktop/laptop domain for some time, and that I can't predict when that will change, and for the reasons I mentioned. And, as I said, I don't know how the workplace will play out on the desktop and laptop. I bet it will gradually show declining power for Microsoft and increasing market for Apple and various Linux variants (for different reasons).
So, I don't disagree with you. Desktops and laptops will stick around for a long time in some segments, including the workplace. I don't know how long that will last, possibly decades more. But, it doesn't matter; the desktop/laptop is already less important than the phone/table...and Linux won that market. It effectively won "Desktop 2.0".
Why are they on Stack Exchange? If they are installing a Linux distro on a Windows computer, then of course you will have an unpleasant experience. If you want to use Ubuntu the right way without having to butt heads with anything, you buy a system from zareason / thinkpenguin / system76.
You can / will run into the same "searching the Internet" for problems installing Windows on your custom built gaming rig. Driver bugs, config issues, etc. Except for those you will end up digging through yahoo answers or windows help with even more misinformation and bloat.
In the end fundamentally it is not a problem with the Linux desktop. You can use a terminal on Windows as well, but you don't expect to because you bought a Windows computer and expect it to work. The same expectation should be had of prebuilt Ubuntu systems, and I think nowadays it lives up to expectation in my experience.
(unless, of course, I'm missing something)
...I'm running Ubuntu on an ASUS laptop that cost under $400, which worked almost seamlessly, and I installed Mint on my ma's laptop that cost under $400. (That incurred finding a new video driver to avoid running everything in 800x600)
I would love to have a Linux-out-of-the-box experience, but the price has to make sense.
That is not good UX for the average joe, or anyone you are just introducing to Linux. It is a UX fail and ruins impressions when people try to install Linux on arbitrary hardware and have a bad time of it. Yes, if you are a veteran and know what you are doing you can do better than the vendors, but to recommend anything else to a Linux newbie without absolute confidence in comprehensive hardware support is just ruining their first impression.
Given that it's Google, that's hardly a compelling argument. They could've made Windows NT dominant if they'd so desired.
Linux doesn't describe one OS, rather a class of OSes. Like Cancer isn't a disease but a class of disesases, or functional programming isn't one language but a class of them.
Google is dominant because they dominiated. MS didn't dominate, google does, and it's not like both companies couldn't compete in a money fight. And this comes back to Windows NT not being dominant despite MS's wishes.
And, when Google started down the Android path, they weren't the Google we know today. It was not a foregone conclusion, and had they chosen a tech which they couldn't control completely, I can't imagine how it could have worked out the way it has. Microsoft couldn't make Windows dominate on the phone/tablet, despite devoting plenty of resources to the task, I'm sure Google couldn't have (given that anybody that buys from Microsoft plays to Microsoft's tune or they don't play at all).
"Make it on the desktop" always meant "the consumer desktop". There is no consumer desktop in the future. The consumer desktop is a tablet or a phone or a TV device or all three. I don't understand it, I don't necessarily like it (I like desktops with big monitors, big hard drives, big mouse and keyboard, and a nice chair to sit in), but it's the way things are. Computing isn't something consumers do sitting at a desk any more. So, Linux won what is currently the way consumers use computers. And, that's hella fascinating, and hella cool.
This is a huge factor for its success, considering all previous efforts of coordinating distros (e.g. LSB) pretty much failed.
My GF, who is not very computer savvy, has been using Mint for years at home and at work. Unfortunately, there were no command line configurations needed even once to set it up. What a disappointment. Ah well, I personally use Slackware so I'll get my jollies there I suppose....
Granted, I did have to go by GF's work at one point and install a printer but you know what? I've spent a lot less time there than I used to as her Windows systems (she and an assistant now both use Mint) regularly got virus or gunked up and slowed to a crawl...
Linux on the desktop has actually been much easier and reduced my honeydo workload considerably. Fact.
That aside, I have to scratch my head and wonder about people who claim to have so many of these types of problems. Tech people too. People who should be eager to embrace and learn powerful command line invocations and the control this learning brings....
Since then, my experience with Linux' driver support has been very smooth, as well, any a lot smoother than stuff I've seen on Windows. Getting a printer to work on Windows is incredibly convoluted compared to CUPS.
Most people I know who use Windows at home either call "that guy" they know who knows his way around a computer, or they just reinstall their system (which is not such a bad idea, really, just very inconvenient).
For me, though, Ubuntu's user interface is just so much more convenient for programming and the other things I do that I manage with debugging the occasional failure to boot, install etc., but that's because I have unusual priorities and good google-fu.
Honestly,I really really dislike Apple...esp the fanboy culture, mythology of Steve Jobs (and the culture which means everyone in Starbucks knows him and not Norman Borlaug), the weird shops, the overpriced products and ripoff margins, lack of choice and individually vs Android...for years I've been known as the guy who slags off Apple etc etc
BUUUUUTTTTTT - and this might be relevant to Windows survivability in the future.
Having spent nearly a week humming and thinking, comparing every type of new business laptop (powerful, reliable etc) at any price to run as my next Windows machine, I can't really find any...Thinkpad has seemed to have gone to pieces, DELL I have only ever had bad experiences with, ASUS/ACER meh etc...
I quite literally am close to swallowing my pride (awaits incoming from friends who I slagged off over the years) and buying a MacBook and putting Windows on it.
Maybe it's just me, but as Windows (except for the Win 8 bloaty crap) software has gotten better, the hardware at the moment seems to be getting worse.
Except when it does. I have a friend who got a virus that deleted the Windows bootloader / ntldr from C:, but hes not as technically literate and lives two states away.
Nothing can fix it. He does not have the technical wherewithal to remove the drive and recover files, there is no way to rewrite those specific files without reformatting the disk, and if the Windows install CD does not fix it (and it did not) you have no resources to try to resolve it.
With Linux, he would have had a live USB on hand, and if it failed to boot he could have reinstalled over his root partition and have all his personal files preserved while effectively resetting the environment.
There is no way he would have been able to boot to the Windows recovery CD command prompt and run anything. Also, I'm pretty sure the boot repair on the disk runs bootmgr repair options during its "please wait were doing stuff and not telling you what is going on" phase.
Windows is a different story altogether. Not primarily because of some technical inferiority, but because people run all kinds of not-even-broken things with admin privs just because they got it in a box.
Just last week someone pushed a mobile broadband stick in their Windows box. It purred and whirred for a while, and hasn't booted since. I've seen similar things before.
(OT: I'd be grateful if anyone had any helpers on how to remove things selectively from the Windows boot process. There is a safe mode boot, which also hangs. Can I step through it, like on DOS? Can restore the boot related registry settings to an older version? Google doesn't help me at all here, and it seems like it should be a pretty common problem.)
I agree that Windows has gotten a lot better over the years, but if you have enough machines in one place, you see some pretty strange things happening, like MS Office breaking for no apparent reason, or an update to Office 2013 breaking Autodesk Inventor, forcing me to reinstall Inventor, thereby breaking Outlook, forcing me to reinstall Office (afterwards, both Outlook and Inventor continued to work - I have no idea why).
The chance for an individual user to experience such problems is fairly low, but as an admin / help desk monkey (we have no dedicated help desk, so I am the one users call for help) I get to see all those problems.
Let me repeat, Windows has improved a lot over the years, and I honestly do not know what it would be like to manage ~100 Debian or CentOS clients. I am not saying Linux deployed on such a scale on such a variety of machines would run without problems.
But you do run into those situations where you have to invoke some arcane command or edit the registry on Windows, too. And at least in my experience, if that happens on Linux, at least you can look at the man page for the command or the config file.
To a point it could be beneficial, but then we would hit the same wall we're coming to here. Over all, you do not need a large group of developers to work on a project. You just need people who have a specific knowledge in order to add features and fix bugs.
Too many people trying to all work on the same thing can lead to too many ideas on how to proceed ahead.
Another idea is having a form of management to help guide people towards more system complementary projects, rather than recreating the wheel.
Doesn't this assume that this cost for commercial OSes is zero? In my experience, that hasn't been the case (as an OSX user, haven't used Windows for software development in a long time).
Also, as an ISV or IHV, if your app or device fails to work with Windows, it's a DEFCON-1 emergency. If it fails to work with one of 5,000 random obscure Linux distros, well, they'll get back to you on that, someday, maybe. It's simply economics in action.
Note that neither of these are issues in the tablet or phone markets, which is why people citing those markets to defend Linux on the desktop are all wet. (They're in good company, of course -- lots of people in the Windows world have failed to understand why those markets are different, including the developer of Windows itself.)
As an open source fan but also someone who has been burned by the hidden costs of implementing it in certain emerging market regions (extensive training, time, lack of people to fix it when it goes wrong, incompatibilities etc etc vs Windows environment with a wider base of support and usage), I would find this very interesting.
I think things often look different in London or SF but the idea of "free software" in poorer parts of the world is often a false one.
FWIW OpenBSD, which I had installed on another partition, ran flawlessly with the exception of suspend/resume. This was a couple of years ago, I think there have been improvements since then.
Just as an example, at our company, we run a Windows Server 2008 R2 Terminal server, with Outlook 2003 installed for email. A while ago we decided to replace the aging Internet Explorer 8 installed on that machine (shudder) with IE11 (still shudder - but it's company policy), and if people are going to use IE, I thought at least they should use a reasonably current one.
Turns out, that Outlook uses IE for rendering HTML emails, and that Outlook 2003 using IE 9 or newer for that purpose results in HTML mails being truncated randomly. Since some of our users run Outlook almost exclusively in their RDP-sessions instead of their local desktops, this was a rather big deal for us, and it took me a while to figure this problem out.
And keep in mind, this problem was caused by the interaction of two problems written by Microsoft itself. Imagine the non-deterministic fun you can run into with applications by a dozen or more software vendors, running across several versions of Windows, 32 and 64 bit.
(Yes, I kind of needed to vent. Sorry.)
Now that Office 2003's support has ended, I don't think Mirosoft will do anything about the problem for newer versions of IE.
(If I could, I would also upgrade Outlook on that terminal server, but that is another story altogether.)
> Again I wonder how things could have been if everyone was pulling as a coherent team instead of in different directions.
If everyone keeps pulling in the same direction you might end up in a dead end. With a plurality of approaches natural selection comes into effect.
Anyway, how do you propose to force volunteers to do your bidding when they have different ideas? Sometimes ideas are mutually exclusive.
Seems like Linux has been competing just fine, but I take it you mean "a desktop linux that appeals to windows/osx users by being similar to them so the learning curve is small".
That seems to more be about a lack of effort and manpower, not because people are pulling in different directions but more that the people who would actually build that stuff don't want it enough to dedicate their free time to building it. That and designers don't seem to be nearly as interested in contributing to FOSS as do programmers.
Because non-technical/non-contributing users are nothing but a drain to FOSS projects. A success is having a large number of contributors, all cooperating to solve a shared problem so they can all spend more time on something else, with some of them dedicating themselves to the problem because it's interesting and helps their friends.
No one is doing it at the scale necessary for the same reason Apple isn't spending all it's money developing products for people who couldn't possibly pay for them. They aren't stupid.
except that the size of the userbase drives companies to port their products to the platform.
How convincing is this though?
"I would like you to volunteer to work on this project that you don't want and wouldn't use (and therefore probably won't do a great job with). You will be inundated with support requests from unskilled users. I would like you to do this because if a lot of people do it, it might convince a unspecified number of companies to port their software to linux at some unspecified time in the future. That's only if you are completely successful building this for and marketing this to people who you don't understand or care about. You will have no help from designers or user interface people because they don't give a shit about you or this. Design and user experience will be the most important parts of this, technical quality will not influence success because the users don't care about that. You will get no social capital from this because the users don't give a shit about what you do.
Do this instead of one of the huge number of really interesting projects building things you would love to have that are on your plate right now, the ones where your peers will recognize, appreciate, understand and value your hard work."
I'm sorry, but that's absolute baloney in the context of the parent post. By and large neither Windows or OSX users need to deal with low level OS stuff, whereas Linux users frequently do. These sorts of issues affect long time users and new users. From what I've seen, Linux users tend to either go straight to a mainstream distro, or distro hop for a while, get bored or frustrated with dealing with unnecessary complications, and end up on a mainstream distro as a result. At first you take pride in learning more, but after a while you just want something that works and gets out of your way. Describing user wants as drains on FOSS means that you're ignoring the issues that are drains for everyone.
In my experience they aren't even problems for beginner computer users or people who don't need to unlearn Windows/Mac-isms post Ubuntu and modern hardware detection.
edit: I should add, I'm not saying a project solving these problems wouldn't be popular among users or generally great for Gnu/Linux as a whole, I'm explaining why it's not popular among potential developers. And when you aren't working in a market capitalism framework a large number of potential non-contributing users isn't enough to get things done.
Isn't that what Zorin is / is meant to be?
I view the diversity and freedom in Foss projects as a feature, not a bug.
First off, assuming you got a group of people together who agree that they should all pull in the same direction, who gets to decide which direction that is? Why that person, and not this person? Secondly, speaking for myself only, being told to work on projects I'm not interested in will produce sub par work and will drain my motivation to both work with that team and the project itself.
Everyone has a different idea on what it would take to get to the Year Of The Linux Desktop, call me when you reach consensus on what exactly the requirements for that project are. Not to be cynical but reaching consensus seems like the biggest blocker, the fact that there are people pulling in multiple directions I think is a symptom of this problem.
The downside is it fragments the finite development efforts of the contributors to the point where it becomes difficult to compete with the wider marketplace.
I guess the problem is nobody really set out to build a Windows alternative at the beginning. As such they got what they set out to build, a powerful set of tools for building "things". It was never a coherent set of tools design toward making a comfortable user experience (grab a compiler from here, a windowing system from somewhere else, mash it all together).
Some distributions (I guess notability Ubuntu, and projects like KDE) have tried to polish what's available into something that's a good user facing experience. With varying success. Most of the issues here likely stem from a legacy of tools which were not designed to build a consumer facing system, and a lack of resources (and desire) to build a platform for the average consumer.
Others, have rewritten the userland (Android) and produced competitive consumer facing products.
Others, have continued to build what (I'd guess largely the developers) want, either to service their personal of commercial interests, things like Debian/RedHat.
So different distributions have targeted different users groups. I no more want to user an Android desktop than a Windows one. But I can see how Android could be far more competitive against Windows. The question is who wants to invest the resources in building that?
They also made important changes regarding security that at least made it more difficult to exploit bugs in more recent versions of Windows.
And, having personally almost no experience with Vista, the changes they made to the GUI between XP and Windows 7 are, IMHO, rather nice in terms of actual usability.
Also, Vista development got stalled big time when Microsoft first pulled out a substantial part of the Longhorn team to work on XP Service Pack 2, and then decided to re-base Longhorn from XP to Windows Server 2003 (R2?).
The net result was, of course, still a system that took much longer than planned and ended up being a huge disappointment to pretty much everybody, even by Microsoft's standards.
But if you consider Vista a "public beta" of Windows 7 and compare XP to Windows 7 side by side, I think - as far as Windows systems go - Windows 7 was actually a big improvement. (Not only on its predecessors, but also on its successors, as they saying goes.)
SCNR.
In the name of tradition, you want a name which is an acronym that says "is not that other thing" or something like that and is perhaps infinitely recursive.
How about WildOS?
"WildOS is like Debian, omitting systemd"
Definitely not DildOS though. :)
Debrogas:
"Debian rid of gnome and systemd"
Rejected bloopers, from my personal cutting room floor:
BSDOS:
"Because systemd, of course, sucks"
"What-I-need Debian: out with systemd"
However, in the end, I think a really good name for this fork would be:
Defiant!
"What are you running on that server?"
"Defiant six dot three!"
"What? Debian?"
"No, Defiant! D-E-F-I-A-N-T, spelled like the word defiant."
I love this one. It captures defiance (getting upset and making a fork), sounds indistinguishable from Debian when uttered by a drunk hacker through a G.711 ULAW speech codec, and has an unusual pronunciation so we can endlessly correct people who just say "de-FIE-unt", who instantly identify themselves as not-in-the-know outsiders. Remember all the fun with Lie-nucks versus Lee-nucks versus Li-nucks.
Lastly:
Deviant
On the other hand, perhaps this will provide a more useful outlet for the set of people who keep claiming they'd use a fork if available, so that they can actually go use one and stop griping on Debian mailing lists.
Nope, sorry, couldn't keep a straight face while saying that.
1. Ensure that there will be a systemd-free variant of debian even beyond jessie.
2. Provide a tangible metric of the interest in such a variant.
3. Provide a platform on which alternatives to systemd can be developed and promoted. After all, systemd it must be said, addresses some legitimate concerns, largely concerned with service tracking and a generally far more dynamic computing environment. The recent Future of FreeBSD presentation by Jordan Hubbard is actually one of the more eloquent arguments in this light (noting that FreeBSD is both Not Linux and Doesn't Have Systemd).
The primary argument against forking is that it divides efforts. My counterargument is that forking makes the existing divide between views on a given approach tangible and explicitly visible. Free Software, particularly under the GNU GPL or equivalent copyleft, also explicitly preserves the right to merge projects which have forked, as has in fact been the case in several notable instances -- GCC/EGCS, the long-running TK
For a specific study of the topic, see "A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes" by Gregorio Robles and Jesuus M. Gonzalez-Barahona
http://flosshub.org/sites/flosshub.org/files/paper_0.pdf
It cites: GCC/EGCS, xpdf/poppler, GNU Emac/Xemacs, the numerous OpenOffice forks, X.org/XFree, NetBSD/OpenBSD, Wireshark/Ethereal, Gerequi/Amarok, MySQL/Miriadb. In total the paper explores some 220 forks, analyzing them by software area (e.g., networking, web apps, development, etc.), year of initiation, and reason. "Technical" accounts for the most at 27%, "differences among technical team" is sixth at 7.3%.
Resolution of forks is of particular interest:
Successful branching: 43.6%
Discontinuation of original: 29.8%
Discontinuation of fork: 13.8%
Discontinuation of both original and fork: 8.7%
Re-merging of fork: 3.2%
Other: 0.9%
As a critic of systemd and proponent of the concepts of Free Software, including the Freedom to Fork, I'm in support of this and similar efforts.
If the fork gave people the choice between "Debian with systemd" and "Debian without systemd", and if that was all there was to it, that would be really sweet. But given the circumstances of the fork, it is not exactly clear how the two distros would coordinate their development, possibly resulting in eventual divergence.
Also, if the project catches on, this might lead to a kind of brain drain on Debian, replacing one - up until now - great distribution with two less impressive ones. (This is of course a worst-case scenario. There might be, three years from now, a lot of sharing of code and people between the two distros. I sure hope so.)
It is surely a very interesting development, but it remains to be seen whether this is good or bad news or even news at all.
1. Why is systemd considered "un-unix"?
2. Why is sysv considered to "follow unix"?
3. Can you provide or point to some explanations on the ideologies that motivate the difference of opinions regarding sysv/systemd?
4. Really, can someone provide some context and history for all this?
Which, I guess, is why the BSDs feel a lot less pressure to replace their init/rc system than Linux distros.
1. It is attempting to unify a bunch of previously disconnected functionality into a single program. Typically unix is composed of small single-purpose utilities that perform a single function, rather than a giant monolithic blob of code (with obvious exceptions, like emacs).
2. Partially because it has been around for so long and has so much history, and partially because it follows a unix tradition of using plain text configuration and shell scripting to solve problems.
3. The systemd folks believe that sysv init isn't capable of doing things that are important to modern systems (ex. dependencies between services, reacting to devices coming and going, intelligent daemon management, etc), and that doing those things correctly requires that an init system be 'more' than people previously thought it needed to be. They are also very....confident in their ideas, and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code.
People opposed to systemd believe that it is too complex for such a critical piece of system functionality. They also resent the fact that systemd seems to require tight coupling to the rest of the system, and that it is aggressively pushing into so many linux systems. Many of them also probably have a long history with sysv init, and are comfortable with the way that it works. (Some portion also probably recall pulseaudio, which had similar grand visions, was similarly aggressively pushed into use before it was fully baked).
4. I think 1-3 probably cover most of this.
And in the process makes old mistakes.
http://seclists.org/oss-sec/2014/q4/592
What is the saying again? Those that don't learn from history is doomed to repeat it?
He still trots that disaster out as proof of his fitness to lead, so it's hard for me to trust that systemd is both well-designed and likely to not be abandoned by him for his next shiny pursuit of Windows. The involvement of other devs helps, but not enough to convince me systemd is worth getting near. Two years of audio fail made a good object lesson for me about Lenart's professionalism and dedication.
One of the best books on the Unix philosophy is "The Art of Unix Programming", which is available for free. (I recommend getting a hard copy and reading the whole thing.)
http://www.catb.org/esr/writings/taoup/html/
Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the philosophy.
Here's one part of the argument: systemd breaks the Unix design style because it's monolithic: http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
But then systemd developers claim it's not monolithic because it's actually composed of multiple processes. They say there is a misconception that all code is contained in PID 1. There are many executables and many processes, so they would say systemd is modular.
But the problem is that all the binaries are released together, without well-defined interfaces. Moreover they are also tightly coupled to kernel features.
If you have 2 binaries A and B, but the interfaces between them is not documented or stable, then it's not really modular, because you can't write your own B' to work with A or A' to work with B.
The recent thread here about dbus is a good example. Traditional Unix is simple text protocols. dbus is this weird text/binary RPC-ish mix which is not documented.
There are lots of other issues with systemd and the Unix philosophy, but that should give you a flavor.
That aside, poking around I found this: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... which looks like reasonably well-defined interfaces?
Also not really seeing the problem with a binary protocol, works fine for tcp/ip.
If you have ONLY used Unices, then I could understand why the philosophy is invisible.
If, like me, you had used Windows exclusively for a decade, and then Unix for a decade, then the Unix philosophy would knock you up side the head. The systems could not be more different. (Despite the fact that they run mostly the same applications. http://www.joelonsoftware.com/articles/Biculturalism.html is the review that got me to read it).
There is no such promise about the interfaces between said sub-daemons and systemd-init.
So are Xorg and Apache HTTPD, which break module ABI with every release. Postfix and qmail are also monolithic (according to your reasoning), with a modular implementation of multiple processes but no stable interface between them. If you replace of the postfix processes with one of the qmail processes you won't get a working MTA.
Not to mention the Linux, FreeBSD, Solaris etc. kernels themselves.
Why is it then that we see this argument only used against systemd, when your average Linux distro install is primarily composed of software systems that you would consider to be monolithic?
> Moreover they are also tightly coupled to kernel features.
sysvinit is also tied to kernel features: it won't work without Linux procfs.
> dbus is this weird text/binary RPC-ish mix which is not documented.
No idea where you got that idea, is this D-Bus protocol documentation is a figment of my imagination?
> Why is it then that we see this argument only used against systemd
WIth systemd we see the changes against Unix design, whereas your other examples already exist.
Here's a nice quote right from the doc you linked: The D-Bus protocol is frozen (only compatible extensions are allowed) as of November 8, 2006. However, this specification could still use a fair bit of work to make interoperable reimplementation possible without reference to the D-Bus reference implementation.
The fact that you even NEED a (crappy) doc is a sign it doesn't use the Unix design philosophy.
In contrast, look at the Debian Control File format, which apt metadata is stored in. I parsed and wrote a dependency resolver for it WITHOUT any reference to docs. The format is self-documenting text.
X is Unix style in the sense that you can plug in different window managers, but not Unix style in other ways.
Shared library extension modules (e.g. Apache, Python, etc.) are not "classic" Unix. Classic Unix simply didn't have shared libraries (or threads). Plan 9 and Go explicitly have this heritage; they don't support shared libraries.
Apache is Unix style because it uses stable protocols between application and server, like CGI, FastCGI, etc. It also uses textual logs, unlike systemd.
I would also argue that systemd encompasses more diverse functionality than either X or Apache, which is saying a lot. The bigger a system is, the worse a monolithic architecture is.
But you're right that modern Unix doesn't follow Unix style in many ways. I am not arguing for purity -- shared libraries are useful, and graphics don't fit well within Unix style. But I do think it is worth understanding the Unix style, for very a practical reason. That reason being: you simply end up with less code when your systems are modular and composable.
Oh right, somebody looked at the spec for 15 minutes, mis-read it completely (confusing the authentication protocol with the actual IPC protocol) and wrote a blog rant about their failure in reading comprehension. Very compelling.
> The fact that you even NEED a (crappy) doc is a sign it doesn't use the Unix design philosophy.
So HTTP is against the UNIX philosophy too? Or did you also happen to implement that without ever looking at the specification?
> In contrast, look at the Debian Control File format, which apt metadata is stored in.
In other words, apples make better apple juice than oranges.
> That reason being: you simply end up with less code when your systems are modular and composable.
You seem to be under the mis-apprehension that monolithic is somehow an antonym of modular. systemd is both modular and monolithic (in your meaning of that term).
"1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, mDNS/DNS-SD, the Linux console and other things all wrapped into one.
...
3. Since systemd is very tightly welded with the Linux kernel API, different systemd versions are incompatible with different kernel versions and portability is unnecessarily hampered in many components. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, serving as an obstacle to developing software portable with both Linux variations and other Unix-like systems. It also raises some issues backporting patches and maintaining long-term stable systems.
...
7. systemd is viral by its very nature, due to its auxiliaries exposing APIs, while being bound to systemd's init. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment often makes use of systemd components, such as logind, and support for non-systemd systems is becoming increasingly difficult.
...
9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much14. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc."
For more information, read through:
http://boycottsystemd.org/ - lot of links to follow
I'm still hooting for a EGCC kind of resolution... but the way more likely outcome is that systemd is here to stay.
Go figure that it was written by one of the same dudes responsible for Pulse Audio, which was possibly the worst thing about most Linux distributions, up until now.
concessions seemed to be that Devuan seems fishy, but I'll let you read for yourself. http://www.reddit.com/r/linux/comments/2nm2u9/theyre_going_t...
Of course such true init-freedom would be near impossible. IMO people should just pick one, forking appropriately, and stop having such huge arguments over something the average user neither knows nor cares about. Just call Devuan the sysvinit fork of Debian and see how it goes...
You can't offer a choice when everything requires systemd.
For me the whole thing came to a head when i learned that consolekit (a bothersome thing on its own) was depreciated in favor of logind. And logind is tied to the hip of systemd.
There are also issues like journald that you need to have running even if your primary logging facility is syslogd etc.
At this point in time, systemd as init is just a minor part of the issue in my opinion.
And it's being built by a group of people with a history of pushing badly built catedrals onto Linux, that turn into ruins even before completion, and have to be maintained because people get used to praying there.
That is a beautiful mental image.
The "official" points by developers can be read in WP: https://en.wikipedia.org/wiki/Systemd#Reception
Most of this is a good thing. Faster. Newer code that is easier to maintain. Less reliance on shell scripts favoring declarative config files instead.
But change has lots of difficulties.
The biggest resistance though is coming from people who are simply accustomed to the old approaches and don't see a problem with them.
But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities.
I'm personally more of a Mac user than Linux user. On the Mac, 10 years ago, launchd replaced many of the processes that systemd is now replacing in Linux. Particularly for things like cron and inetd (which were horrible to configure and work with) it was a huge improvement. However, the Mac never replaced as much all at once. It was a much gentler transition. In fact, discoveryd (which does a lot of what systemd's hostname daemon's are trying to do) was only introduced in the current Yosemite.
That's just a fact of life in this industry tho.
The speed benefits come at the trade-off of integration complexity potentially diminishing them: http://freedesktop.org/wiki/Software/systemd/Optimizations/
Whether or not it is easier to maintain cannot really be objectively gauged. As for declarative configuration, I will grant that. systemd is not the first to do this on Linux, though. eINIT was, though it used XML as its configuration language (similar to launchd and SMF in fact, though not as verbose). eINIT also had the benefit of a modular plugin-based architecture, a property also shared by finit and initng.
Change does not imply progress. This should go without saying.
No, a lot of objectors simply come from having different opinions on process management and general software architectures. That said, there is a contingent who did approve of the old approaches, yes. I dislike sysvinit, but I can understand them. Serial execution with a concretely defined boot sequence that is easy to reason about can be a benefit to some. In contrast, the systemd approach eschews any definition of "boot process" or "boot sequence" that can be specifically intervened in by order, instead taking the philosophy that specifying a unit's dependencies and relative order to a target/synchronization point is enough, the rest being handled by internal transaction and job semantics.
systemd most certainly is monolithic. It is also modular, but to a partial extent. System generators and various auxiliaries (journald, but also some of the more minor tooling) cannot be disabled at build time. Certain things like Plymouth communication are also explicitly done at runtime.
launchd as a whole is still a much smaller system than systemd, at the end of the day. This is because launchd has a concretely defined purpose. systemd has little in the way of that other than vague descriptions that ultimately amount to being "as much as possible between the kernel and base libs+utils".
> But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities.
The problems start when those replacement system utilities become (more or less) tightly coupled, so if you want to change one of them (say, I want to use my own DHCP client) then you need to change all of them (and it's increasingly looking like you can't).
And that is the insidious nature of it all. the *d's panders developer laziness. What do you do when some production critical piece of code demands networkd, logind, or any of the systemd sub-daemons? Do you look to replace it, or do you roll over and replace whatever already functioning init you have with systemd?
Well, with roadmaps like this[1], one wonders if some of the criticism is really that hyperbolic or unjustified...
This in effect makes everything under the systemd umbrella tightly coupled. Can i run journald on its own, or logind, or resolved, networkd? As long as the answer is no, they mays well be one big blob.
And it is presented as such as well from a source point of view.
http://www.freedesktop.org/software/systemd/
There is no separate tarball for udev, journald, logind, or any of the other *d's that make up the systemd project.
So to you there is no difference between sendmail and postfix, they are both equally monolithic?
It also brings "new" bugs.
50% of the problem is that there is no appreciable advantage to me (as a Gentoo, XFCE user)
the fork, for some of us, has been necessary since we saw how toxic the debian constitution was in practice.
https://web.archive.org/web/20141020161905/http://forkfedora...
I am not sure anything will come of this, but I hope it doesn't fail.
Franco Lanza
Unixmedia s.r.l.
Via Cosimo Del Fante 4
Milano, Italy
DEV-on?
de-VWAN? (like Juan)
dev-oo-ahn?