That site does seem to show an odd disconnect, it seems to mention "init-freedom" alongside "...the first goal of removing systemd...". Surely true "init-freedom" would be to give the end user a choice between sysvinit, bsd init, sysmtemd, launchd, android's init, and so on.
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...
Compare to Gentoo. Gentoo defaults to their homegrown OpenRC. But Gentoo is all about choice and so systemd is an option and works perfectly well. That's "init-freedom". If someone doesn't like systemd and removes it from their distro, that's OK with me. But calling that "init-freedom" seems weird. Maybe they should call it something like "sysv-freedom", if that's what they mean.
Sadly the one thing that dissapears in this debate is that systemd has long since gone beyond being a init.
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.
The same freedom that leads to all the many, many flavors of linux gives a great diversity of ideas. 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 wonder sometimes if it were possible for everyone to contribute to one linux desktop if the situation would be different today.
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.
Same here, except with a Mac as the host. I really like the setup of a OS X developer environment and tools, with the ability to summon Vagrant boxes or whatever else on command.
I know exactly what you mean. But we both know these are very different things. For most people, their tablet and phone works absolutely seemlessly, with drivers, apps, downloads etc just working they way they want them to. It just never works that way on the Desktop unfort. I know loads of "average" people who have tried to use MINT/Ubuntu but eventually a big chunk end up reaching for Redmond after they spend too long looking at StackExchange trying to figure something out.
It doesn't matter; there are literally more phones and tablets than there are desktop/laptop computers. Desktop/laptop is irrelevant in the future.
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.
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".
> after they spend too long looking at StackExchange trying to figure something out.
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.
Cheapest laptop on zareason: $699
Cheapest laptop on thinkpenguin: $599
Cheapest laptop on system76: $799
(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.
I know this is a problem, that is why one of my side jobs is custom building Linux machines locally. I do tech support, and if the client doesn't need Windows specific software or it runs perfectly under Wine I'll set them up with Linux builds and notebooks. I have several Chromebooks I'm versed in reformatting and know they work flawlessly and on what kernel versions that happens.
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.
No they couldn't make WinNT dominant if they wanted because WinNT's source code isn't freely available.
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.
The comment I was replying to suggested that the diversity (the forks) of Linux were the reason Linux would never win the desktop. I made my comment to make two assertions: First, that the desktop is irrelevant today because more people use phones and tablets, and the spread will continue to grow. Second, that the forkability of Linux made it possible for Android to exist...and, to practically destroy every other competitor for the phone and tablet (except Apple, but Android has a very comfortable, and growing, lead over Apple).
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.
It's also interesting to notice that Android is developed in a fundamentally different way to the myriad of mutually incompatible GNU/Linux distributions: Android is developed in cathedral style by a single centralized organization that is able and willing to define categorically the APIs that ISVs can target and keep them stable.
This is a huge factor for its success, considering all previous efforts of coordinating distros (e.g. LSB) pretty much failed.
I can't remember the last time I had to fix a driver problem on Linux.
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....
I remember, ten years ago I had to compile the kernel module for my sound card manually, because it was not part of the mainline kernel. shrug
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.
screwing with command line nonsense to make wifi and audio work reliably on my laptop isn't learning, it's technical masturbation. I want to use my computer to do actual work, not make-work.
This was within the last 12 months on ubuntu and a lenovo laptop, btw.
As if that was different on Windows. Windows only works smoothly until it does not, and then you inevitably have to invoke some command-line tool you never heard of before and won't find any documentation for, or you have to edit some arcane registry key.
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).
Hmm, I possibly would have agreed with you up until XP, when it was very very buggy and crash prone, but after that for the average user I really doubt that is the case. Thought I think we can agree to disagree depending on our respective experiences.
This. I'm not saying modern Windows is fault free. It may have an inconvenient user interface for some things, it may not always do the thing you want it to etc. but it never fails to boot, everything but Apple hardware runs it flawlessly and it has a massive third-party software selection.
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.
This is way OT, and I'm pretty rusty in Windows land, but there used to be a tool you could run if you booted to a command prompt from a windows install disc that would rewrite ntldr and the boot sector. bootmgr.exe maybe? Something like that. Not all hope is lost!
The context is that he is tech illiterate. So much so that I tried to get him to just use a gui tool on his windows notebook to put Ubuntu on a 2GB flash drive to save his files but he couldn't do it.
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.
People have so varying experiences it's not even funny. I guess fail to boot means some update was required to initrd that didn't make it, but it's not something that would be common among the mainstream stable distributions. I've certainly never seen it on hundreds of machines.
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.)
My day job is managing a company network of about 100 Windows clients, running anything from Vista to 8.1.
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.
"I wonder sometimes if it were possible for everyone to contribute to one linux desktop if the situation would be different today."
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.
"The amount of time and effort I spent wasted on package incompatibilities, instabilities, and debugging strange hardware/driver related issues isn't worth it."
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).
The cost isn't zero, but it's proportional to how many other people are likely to have encountered the same pain point. If you run a desktop OS with 5% of Windows' market share, you're going to have more trouble finding help (or at least sympathy) when things go south.
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.)
That would make for an interesting whitepaper by someone. A country by country or regional calculation of the costs of implementing open source.
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.
Some hardware is well supported by Linux, some is not. Same with Windows, though most vendors support Windows if they support anything on x86. But it's not always that clear-cut. Particularly on laptops, if you diverge from the OEM-included drivers you can have issues. I had a Dell laptop that I obtained second-hand, and I reinstalled my employer's stock Windows 7 ISO on it. It randomly blue-screened even with the latest appropriate graphics drivers, until I went back to the Dell website and found the exact version of the driver needed for that laptop.
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.
It is far from zero. On Windows, it is just not considered Microsoft's problem by most people - the blame is spread across lots of different software vendors/developers.
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.
MS does seem to support Outlook 2003 with IE9 and even released a hotfix for an incompatibility. IE11 was released close to the end of support of Office 2003 though, I wonder what is the support policy in that case.
Yes I have. And Rawstudio. And Raw Therapee. And while darktable is the fastest evolving one it's still not close enough. But I'm keeping tabs on it. Lightroom is slowing down and to be honest it's way past the diminishing returns elbow at this point so maybe next year. I no longer do photography professionally so it's less and less of an issue.
"becomes difficult to compete with the wider marketplace"
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.
Sure, there are long term high level strategic interests that could be helped for sure.
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."
Big issue here is the issue that open source has with designers. It's really frustrating to try to get a clear vision executed in the "doocracy" of an OSS project, where developers will often implement features to "scratch an itch".
Yeah, it's hard not to see that as something it would be good to get past. Developers deal with that at the architecture level decently enough. Maybe the filling in part is just less fun than it is for software so it's harder to get volunteers? Maybe it's how credit/social capital works in a different community? It is frustrating, those skills make such a difference.
"Because non-technical/non-contributing users are nothing but a drain to FOSS projects."
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.
These problems you describe aren't present for the people being asked to solve the problem, so they don't volunteer their time to fix it.
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.
I take issue with the idea that if every developer was pulling in the same direction we would be somewhere better than where we are now.
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.
Linux is a kernel. Linux distributions target a variety of different users, and that's where the fragmentation comes from.
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?
Some things on Linux were broken from Day 1 like drivers and X because it they were easier. I doubt a coherent team could have fixed these without rewritting which taks too much time. It took MS 6 years to make XP into Vista, I doubt OSS people operate on that kind of timeframe.
XP to Vista took 6 years because MS had huge plans for Longhorn. It took some time to build these things, then some more time to decide they won't be ready any time soon and throw them all away.
In all fairness, they did not throw all of their plans away - some of the more visible ones, like WinFS, yes, but from what I know, they reworked a lot of Windows' internals going from XP to Vista/7, like the audio and the network stack.
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.)
I'm for sure not feeling the love for systemd, it seems un-UNIX and a solution looking for a problem, and change for the sake of change. That said, not so big on the idea about a fork, I'd rather see debian do the normal debian thing, and support both things, maximizing freedom. That said, if that can't happen, a fork is inevitable - for the love of god pick a better name.
I don't think anyone really considers sysvinit to "follow Unix". In fact, I'd say sysvinit is more of a historical accident than anything. An actual example of a service manager that follows the Unix philosophy would probably be daemontools and its derivatives (s6, perp, nosh, daemontools-encore and runit).
When I first started using Linux, I found SysV init very intimidating (along with the rest of the system). When I eventually stumbled upon Slackware, and then FreeBSD, I was euphoric about how simple it was to configure system startup.
Which, I guess, is why the BSDs feel a lot less pressure to replace their init/rc system than Linux distros.
With the caveat that I haven't kept up closely with systemd
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).
I was one of those burned by Pulseaudio and the way Lenart basically dumped the project as soon as it got enough traction and before it was stable or truly functional. The design was, as you point out, very reminiscent of systemd - one giant, poorly documented and not very well tested audio system was supposed to replace all other parts of the Linux audio stack (above the kernel drivers) and give us near-realtime performance and a lot of fancy device management and dynamic control. Short form: it didn't until he had already moved on.
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.
Those are good questions, but answering them won't fit in a comment. It takes more like a book.
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.)
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.
If you don't think the content of that book is relevant to the systemd debate, then you haven't read it. I'd like to see you point to a better book about the Unix philosophy.
I've been using unices for over 20 years now (first was ultrix, then truos, sunos, solaris, hpux, aix, linux, netbsd, freebsd, osx) and I don't believe there is such a thing as a unix philosophy.
Give the Art of Unix Programming and honest read, and I'm
sure you will come around.
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).
> systemd breaks the Unix design style because it's monolithic:
> But the problem is that all the binaries are released together, without well-defined interfaces.
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?
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."
The problem is that systemd is making it impossible to create a system where you can use either it, or another init. A fork may be the only way to avoid it, and it's quite probable that this fork will lose GNOME in a few years.
I'm still hooting for a EGCC kind of resolution... but the way more likely outcome is that systemd is here to stay.
> it seems un-UNIX and a solution looking for a problem
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.
Assuming this actually going somewhere, I have mixed feelings about this. On the one hand, it might allow us to get over those intense - and usually pointless - arguments (to put it politely) about systemd. (Personally, I don't have very strong feelings about systemd, but I get the impression it could use some time to mature before becoming the centerpiece of a GNU/Linux system.)
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.
Many people complaining about it is that it doesn't follow the Unix philosophy. I think that it's not so much that systemd is un-UNIX like (after all, it could be argued that X-windows is un-UNIX like too). I think the problem that people are having with it is that it is a cathedral that is getting erected right in the middle of their bazaar.
(personally, I don't mind systemd, but I also didn't mind SysV, or BSD init styles either).
Also, it's a badly built cathedral, that most people see that will have problems in the future.
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.
There are so many problems with it that it's not possible to tl;dr them. But Google will help you. There are so many posts flaming it (for good reasons) that it will be easy for you to understand everything.
In short: it's taking over Linux userspace. It's slowly leading us to a point where systemd will be "the Linux middleware", and all apps (above it) and the kernel itself (under it) will not work without systemd.
systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services.
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.
I haven't used systemd yet, but I'm concerned about having to learn a completely new way of doing things. I manage a number of servers, and it would be a huge inconvenience figuring out systemd. The old way works fine for me. Unfortunately most of the servers I work with are CentOS, and it seems Redhat has switched to systemd so I'm not entirely sure what I'll do in future. I guess now I have another option.
Yes, of course. I occasionally learn a new language (or develop one), and I'm regularly using new APIs. However this completely changes everything about managing servers, for no compelling reason. It will create a large amount of hassle for no significant benefit.
No compelling reason? you should probably read the docs a bit more. If you don't have any philosophical concerns with systemd, then you will find a lot to love there.
I just re-read some docs, and I still can't see any compelling reasons. I'm not concerned about booting a few seconds faster (I only reboot my servers once every year at most). Regarding memory footprint: that has never been an issue. Binary logfiles are a disadvantage to me.
Binary logs and the amount of new code which these developers are incorrectly assuming will be stable. It is a total disaster in my opinion. I fell in love with using Linux because everything is text files. Binary approaches will only make using linux more cryptic.
This is a disingenuous presentation, though I would not expect any different from a systemd proponent, or opponent, for that matter. I wrote about the follies of systemd debates here: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
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".
> systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services.
> 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).
More correctly, you can't just use networkd as your dhcp client unless you have systemd as init. You could however use dhcpcd on top of systemd (tho the latter would likely make a lot of noise about "missing functionality").
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?
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.
Well, with roadmaps like this[1], one wonders if some of the criticism is really that hyperbolic or unjustified...
Sadly it drags the whole debate into an argument over semantics. Yes, it is not monolithic in the sense of one binary running everything. But at the same time everything ties back to systemd running as init.
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.
Some people don't like it per se, but mainly what they don't like is that it's going to be the only viable init system in Debian, since many maintainers don't have any intention to support the others.
The originators direct english speakers to pronounce the name as "dev-one". but, hey, i've heard a lot of different pronunciations of 'linux' and even 'debian' over the years, so what ever floats yer penguin.
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"
Or some other "-ild" word besides "wild". Gild? Mild?
Definitely not DildOS though. :)
Debrogas:
"Debian rid of gnome and systemd"
Retains the Latin flavor of Devuan, in any case.
Rejected bloopers, from my personal cutting room floor:
BSDOS:
"Because systemd, of course, sucks"
Windows:
"What-I-need Debian: out with systemd"
# # #
However, in the end, I think a really good name for this fork would be:
Defiant!
But: not pronounced like the word "defiant" but with emphasis on the first syllable, so it sounds like debian: 'DE-fih-ənt.
"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
(Also pronounced differently to sound like Debian.) PRO: changes only one letter in Devuan, and deletes one. CON: less abrasive than Defiant. It's deviant because it's forked; it deviates from some originally intended path.
On the one hand, this seems wildly misguided; the Debian distribution for people who don't want to run systemd is still just Debian, and that'll remain the case through at least jessie, and for as long as people continue putting effort into keeping it working. So it's sad that the effort going into this fork doesn't instead go into maintaining the necessary infrastructure in Debian. I'm sure the maintainers of systemd-shim and cgmanager would welcome additional contributors.
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.
There are several arguments I can see in favor of a fork.
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
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.
From their manifesto: Dear Init-Freedom lovers, The Veteran Unix Admin collective salutes you. Does this group expect to be taken seriously? Read Cory Doctorow's "When Sysadmins Ruled the Earth" and get over it.
I've been waiting for this fork. It means I can install a .deb-based distribution again. Here's hoping this is as successful as Libreoffice or X.org has been.
huh? this is the first release to really require systemd. how could you have been waiting for a fork when one wasn't even necessary until a release that isn't even marked stable yet.
134 comments
[ 3.4 ms ] story [ 181 ms ] threadOf 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.
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.
This was within the last 12 months on ubuntu and a lenovo laptop, btw.
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.
http://www.darktable.org/
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?
http://zorin-os.com/
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.
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.
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...
https://web.archive.org/web/20141020161905/http://forkfedora...
I am not sure anything will come of this, but I hope it doesn't fail.
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.
http://en.wikipedia.org/wiki/Ad_hominem
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?
http://dbus.freedesktop.org/doc/dbus-specification.html
> 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
http://en.wikipedia.org/wiki/Systemd
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.
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.
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...
[1] http://0pointer.de/public/gnomeasia2014.pdf
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.
http://seclists.org/oss-sec/2014/q4/592
50% of the problem is that there is no appreciable advantage to me (as a Gentoo, XFCE user)
DEV-on?
de-VWAN? (like Juan)
dev-oo-ahn?
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?
Or some other "-ild" word besides "wild". Gild? Mild?Definitely not DildOS though. :)
Debrogas:
Retains the Latin flavor of Devuan, in any case.Rejected bloopers, from my personal cutting room floor:
BSDOS:
Windows: # # #However, in the end, I think a really good name for this fork would be:
But: not pronounced like the word "defiant" but with emphasis on the first syllable, so it sounds like debian: 'DE-fih-ənt."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:
(Also pronounced differently to sound like Debian.) PRO: changes only one letter in Devuan, and deletes one. CON: less abrasive than Defiant. It's deviant because it's forked; it deviates from some originally intended path.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.
the fork, for some of us, has been necessary since we saw how toxic the debian constitution was in practice.