Core parts of Gnome (and probably lots of other Linux-y software, I haven't been following all of it) are all moving to require systemd. Systemd certainly promises a lot of advantages, like better handling of removable devices (and more: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530), but it is also replacing the tried-and-trusted rc approach. OpenBSD leaders in particular are concerned about systemd from a security standpoint; it has a lot of code that runs as root, it is big and unwieldy and the documentation is a mess.
So, not only were the OpenBSD developers faced with either auditing the entire systemd code base -- and then doing it again every time there's a new release -- or attempting to re-implement it in a compatible way, now they're also staring down the very short barrel of a nasty gun in which some really big stuff is going to stop working if they don't deal with it.
It's a real ugly situation, and OpenBSD really doesn't have the resources to spare to deal with this kind of nonsense. I wouldn't be surprised if this mess ends up tying up a couple of their core developers at an upcoming hackathon, where they could instead be working on something more useful than having to replace a huge part of the system that was working just fine up until Linux decided to throw it out. (Obviously there are plenty of people that would argue it wasn't "working just fine", either because they have specific knowledge about it or because "otherwise we wouldn't have needed systemd". That's not sufficient justification for forcing other developers to waste tremendous amounts of effort to re-work what was already working for them.)
Personally, I'm not a huge fan of the switch to systemd. I liked rc scripts. I've cobbled together my own rc daemon scripts from time to time; I'm not sure how that will work with systemd. I'm also seeing lots of ugly and persistent problems in NetworkMangler and whatever they're using for core audio these days; I'm a little gobsmacked that, rather than fixing those problems, some people decided to replace the init system.
I don't understand why systemd is suddenly such a hard requirement: it suggests that the Gnome developers are simply punching through the abstraction layer provided by dbus for reasons of convenience. If some part of Gnome needs a system service, it requests it via dbus and parses the response. How that service is delivered ought to be irrelevant.
Since systemd is supposed to offer all its services via dbus, is the problem really "we don't want to implement all these services that a modern desktop needs". OpenBSD et al could offer a dbus layer that implements the same set of services, but they don't want (or have the manpower) to do so. In which case, I'm not really sure they have a leg to stand on: the things systemd offers really are important for a modern well integrated desktop (or any other system for that matter) and they weren't well served by initscripts. OpenBSD is free to implement a service that offers the same dbus interfaces whenever they want, but complaining about Linuxisms is perhaps a little rich: if you want your system to remain stuck in the early 1990s then that's fine, but you can't really expect the rest of the world to hang around waiting for you to catch up.
NB If the answer to "why can't you write dbus interfaces" is "we'd love to, but the Gnome developers keep changing the interfaces every minor point release" then that's probably a valid retort...
Thanks for the lwn link, it really helped to put things in a larger perspective. And I can't help but feel that Gnome is being used here to enforce systemd dependancy for reasons other than purely practical..
I think systemd is currently the best init system when it comes to potential, however I don't like how it 'swallows' other core components like udev as I think that might have a negative impact on possible alternatives being developed.
I think systemd should compete on it's merits and not by what seems like it becoming a dependency as part of an agenda rather than a practical necessity.
It's a long and rather sad story, but since systemd started to do its own logging (using a binary format), it can optionally now link to a micro HTTP server so that you can connect to the journal on localhost in order to read these logs (http://cgit.freedesktop.org/systemd/systemd/tree/configure.a...).
I won't offer any opinions on whether this is good or bad, simply state that's what happened.
The maturity of systemd is at the root of the problem here. I switched (even for ArchLinux standards) relatively early and since then I could see how things changed continuously. There are two factors here: I appreciate active development of software and I would like things to stay compatible with previous releases at a minor cost to "progress". It is hard to get both in such a complex design space. Most of the problems are hard to predict and only come up as soon as there is active use of the system and if you never go public, there will never be active use.
Overall, jumping on the systemd bandwagon was done prematurely (at least by ArchLinux) and I think the large software packages should just give it another few months before migrating. systemd solves a lot of problems now and developers want problems to go as away before they become a feature or to pervasive to the codebase, but a little restraint might to a lot of good here.
There has to come a point where systemd announces feature completeness and stable interfaces so everybody can use it as a standard and then everybody can go for broad use and acceptance. I would hope that this gives the smaller players a chance to catch-up and much needed safety when investing resources into their own implementations.
>The maturity of systemd is at the root of the problem here.
That is pretty much what I came in here to say. It seems like OpenBSD is trying to have it both ways: Include all the latest and greatest toys and still thoroughly audit everything that changes between releases. But it's new toys, secure, cheap. Pick two.
Is it really the end of the world if OpenBSD bears a closer resemblance to Debian Stable for the sake of security? Why is 'latest Gnome' a requirement? Just stick with older versions of everything until the new APIs stabilize and mature.
But the problems with systemd aren't an isolated case, and they aren't technical, they're political. And political problems generally don't get better when a technical solution is applied; in this case, waiting it out just silences OpenBSD's voice in the potential discussion. So I'm glad they're making an effort to engage the community and look for alternatives to the political problem.
I'm deliberately not saying exactly what the political problem is – I'm not "framing" it one way or another.
Concerning NetworkManager, you might like my NCD scripting language designed specifically for programming of network configurations. http://code.google.com/p/badvpn/wiki/NCD
Wow. You developed a programming language for handling network connections; that is actually really neat. It's way past my bedtime, so I might've missed it, but is there any way in NCD to detect, say, a new wired connection, and then a timeout waiting for dhcp, and then as a fallback, configure the interface with a static ip?
I'm not sure what I think about having to edit a file every time I want to connect to a new network, but on the other hand, it would be super nice not to have to reboot every N times I switch network connections.
process lan {
# Set device.
var("eth0") dev;
# Wait for device, set it up, and wait for network cable.
net.backend.waitdevice(dev);
net.up(dev);
net.backend.waitlink(dev);
# Start doing DHCP and waiting for timeout. This spawns two additional
# processes to run concurrently (see their code below).
process_manager() mgr;
mgr->start("dhcp", "conf_dhcp_template", {dev});
mgr->start("static", "conf_static_template", {dev});
# Wait for either multiprovide("LAN-DHCP") or multiprovide("LAN-STATIC"),
# but always prefer LAN-DHCP. Even if we've already grabbed LAN-STATIC
# and LAN-DHCP comes up, we backtrack and switch to LAN-DHCP.
multidepend({"LAN-DHCP", "LAN-STATIC"}) conf_dep;
# We can reach objects as seen from multiprovide() by going
# through our multidepend() statement.
println("got ", conf_dep.result_type);
rprintln("lost ", conf_dep.result_type);
# Check IP address - make sure it's not local.
ip_in_network(conf_dep.addr, "127.0.0.0", "8") test_local;
ifnot(test_local);
# Assign IP address.
net.ipv4.addr(dev, conf_dep.addr, conf_dep.addr_prefix);
# Add default route.
net.ipv4.route("0.0.0.0", "0", conf_dep.gateway, "20", dev);
# Configure DNS servers.
net.dns(conf_dep.dns_servers, "20");
}
template conf_dhcp_template {
# First argument is device name.
var(_arg0) dev;
# Do DHCP.
net.ipv4.dhcp(dev) dhcp;
# Expose results.
var("dhcp") result_type;
var(dhcp.addr) addr;
var(dhcp.prefix) addr_prefix;
var(dhcp.gateway) gateway;
var(dhcp.dns_servers) dns_servers;
multiprovide("LAN-DHCP");
}
template conf_static_template {
# First argument is device name.
var(_arg0) dev;
# Wait 5 seconds.
sleep("5000", "0");
# Expose results.
var("static") result_type;
var("192.168.111.230") addr;
var("24") addr_prefix;
var("192.168.111.1") gateway;
var({"192.168.111.14"}) dns_servers;
multiprovide("LAN-STATIC");
}
But then be careful with your dependency names, because they are global. You can prefix them with the interface name, e.g.: concat(dev, "-DHCP") dhcp_name; .
I worked on Solaris during the Gnome transition and during the largely overlapping SMF transition. I'm not sure which was more painful or was more broken by design, though SMF surely affected more developers.
If I were making decisions for OpenBSD I would not accept a requirement to port an init replacement, but I also wouldn't be putting any resources into keeping Gnome running that could go into better integration with an alternative.
While it is nice to be able to mix and match everything rather than having choose a silo, having these large market share players like gnome dictate changes on every platform is ultimately rather destructive to having meaningful options.
I would rather run the Linux kernel for practical reasons, and often use gnome for practical reasons though I would be thrilled not to.
Showing me you can keep up with Linux running gnome isn't compelling at all, particularly if it means you are no longer doing much else. But if you can better integrate with KDE or enlightenment (or fvwm and some duct tape,) and give me an alternative to linux+gnome then I'll deal with a new kernel (and not having PAM?!)
About systemd itself: I guess so far it's really hard to say if it's worth the hassle. My experience is limited to two installations: One on a (admittedly beta level) Fedora image and running Arch on my Pi.
The latter was really pleasant, _including_ the systemd migration. I never used it before and definitely fell in love with a couple of features (The status, unifying log messages and the service status, for one).
I'd be the first to agree that there's quite a bit of room to improve. Some design decisions are questionable imho (like the stated opinion that systemd shouldn't write a text-only /var/log/messages file by default).
In the end it's always the same though: Some people are having a vision of how things should work and try to promote it. If they are successful, I'd argue that their idea has merit (or everyone else doesn't care).
"Some design decisions are questionable imho (like the stated opinion that systemd shouldn't write a text-only /var/log/messages file by default)"
I think that may have changed in the latest release (or maybe it's in the next release, but I'm pretty sure Lennart said the default was going to be to write logs).
I think that may have changed in the latest release (or maybe it's in the next release, but I'm pretty sure Lennart said the default was going to be to write logs).
See, the problem with the sentence "shouldn't write a text-only /var/log/messages file by default" wasn't the "shouldn't write a [log] by default" part, it was the "shouldn't write a text-only [log]" part. As a CLI jockey/junky/sysadmin, I for one will not accept any solution I can't grep.
As a long time Linux user, I can't but agree with the OpenBSD folks: systemd is a "solution" in search of a problem, and the only reason it is gaining any traction appears to be the same shove-it-down-the-user's throat attitude that the GNOME devs have.
Granted, there has been a proliferation of parallelized boot schemes cropping up in Linux, but systemd seems to take too much on itself. And while PulseAudio eventually settled down and solved the proliferation of audio multiplexing systems, it was a very bumpy ride getting there. I only bring that up because that was another Poettering project.
I agree entirely with the sentiment here. If you've ever had to piece together something external to your distribution you will know the pain involved. This is amplified considerably if you pick a BSD-related operating system and for no good reason.
The Linux kernel itself is a remarkably stable system as far as ABI/API is concerned (Linus you rock here), but the packages gyrating around it are completely impossibly unstable and unreliable.
A fine example of this is trying to get an SSTP client working with NetworkManager recently. The whole NetworkManager VPN thing is an epic pile of hacks with bits of UI and bits of backend sticking out all over the place. If you're using Debian stable for example, there is no chance in hell you can get a working configuration unless you go and fix the numerous broken interfaces all over the place manually and arguing with pkg-config and literally hundreds of dependencies. How the fuck this ever even worked to start with I don't know. There are massive API changes with minor versions of packages all through NetworkManager and Gnome, which is just wrong.
The underlying issue is simply shitty engineering from a large body of open source projects who don't care about upstream or doing their job properly. To name and shame: The entire Gnome project, just about anything Ubuntu have chucked out, the entire KDE project post KDE2.
It's utterly frustrating. I wish they did take a more BSD approach, which is conservative engineering i.e. think about it, get it right and leave it.
For all the people here whinging about innovation, waah waah, ship old versions etc, I doubt you've actually had to deal with these issues or build a project on top of them. There seems to be a large detachment from reality here.
As an example to back my point up, one of the reasons Windows is so damn popular is that the API is incredibly stable and software written in the mid-90s still works fine on current versions without a recompilation or any API changes. A two week old build of NetworkManager probably will break all the VPN providers...
The Linux kernel itself is a remarkably stable system as far as ABI/API is concerned
You're joking, right? There have been cases where ABIs have been broken by security patches, and users have been told that they have to choose between having a secure system and being able to use their third-party binary drivers.
(And yes, I understand the arguments about how binary drivers are evil; but I don't think users should be used as pawns in that fight.)
As other people have said, userland ABI/API is solid. I should have clarified that.
There is no reason the internal API would be as to be honest it's the Kernel's job to make the drivers sit behind that API and stay there regardless of the problems. That is the abstraction boundary.
The issue is where the abstraction boundary is. In NetworkManager for example, which is an example I'm probably just picking on, there are many more abstractions above the kernel's abstraction which are unstable.
Again, comparing to Windows, there have been several driver model revisions but the userland API+ABI is stable between them.
> The Linux kernel itself is a remarkably stable system as far as ABI/API is concerned
If we're talking about userland applications, the Linux kernel A[BP]Is have IME historically been more stable than the Glibc interfaces (which are supposedly the "supported" interfaces) layered atop them.
In-kernel interfaces for binary-only modules are a different kettle of fish altogether.
He was probably talking of the user-space ABI/API. Drivers are internal to the kernel (or should be) and Linux never made a claim that those APIs where going to be stable.
Aside from being a GNOME release team member I am also the packager for GNOME within Mageia. I find packaging GNOME to be really easy, way easier than I expected actually.
Your argument comes across as that others should work more like the way you want them to work. The "large detachment from reality" is IMO an unneeded comment, easy to make comments from the sideline.
The people who are involved with GNOME from OpenBSD side are really nice and friendly. But some in that openbsd thread have the weird notion that if OpenBSD would drop GNOME that then we'd take OpenBSD more into consideration.
Your bit about NetworkManager: The goal is that you can easily configure your network. The way of doing that at that time and for now is NetworkManager. If it isn't good enough, then promote something which delivers the same goal, but is technically better. That's how to positively and practically change things.
In that case as a Gnome team member, please take the comments I made as complaints relating to things that need fixing. I wouldn't say them if I did't stand behind my opinion.
In fact, my argument is that Gnome should adhere to sound engineering principles. This is not my sole opinion - it is a generic opinion which can be applied to any engineering project and is an established norm. "Move the goalposts, expect trouble".
NetworkManager utterly wins at easily configuring your network, but only if you have one ethernet card or a wireless card. For any other circumstance, it falls over miserably and turns into a shitfest of epic proportions which proceeds to bugger you at every available opportunity.
ifconfig is a better tool, particularly on BSD as it handles ALL interfaces equally, ironically due to sound engineering!
My efforts would be better spent writing a new desktop environment which actually cares about UNIX's semantics and architecture rather than reinventing it every few months.
In my case, I have a wireless and PPTP VPN connection. I tried SSTP but couldn't even get a build working during to API breakages.
The VPN configuration is a mess and hideously impossible to debug properly. There is no way an average end user would be able to get it working as you have to set log levels via cryptic dbus commands, start various services including network manager in debug mode and dredge through log files etc.
Add to that, the source is comment free, there is no documentation whatsoever.
That's all just shitty engineering.
The whole thing feels like it's been built by 12 year olds.
If it isn't good enough, then promote something which delivers the same goal, but is technically better. That's how to positively and practically change things.
No it's not. The way to positively and practically change things is to do them right in the first place, or failing that, fix the system you have. The "throw it away and do something new" attitude is the driving force behind everything that is wrong with Linux on the desktop.
I'm all for incremental improvements vs big rewrites. However, there are times where incremental improvement is not viable because the basic premises of the new system is conflicting with the basic premises of the old system.
Take systemd, for instance. One of its stated goals is to remove shell scripts. This is not something which can be achieved by incrementally modifying sysvinit.
I don't understand what is wrong with shell scripts. I mean after all, UNIX is designed to be put together using small programs wired together with scripts.
What systemd does is replace that elegance with a monolithic black box.
Whether it's elegant is debatable, considering how repetitive they usually are. I can understand wanting to move to a declarative approach, it makes much more sense in a lot of cases. The approach of recording dependencies by having "magic" comments is an ugly hack.
Is it any more hacky than meta-programming in LISP?
It's not elegant. Well some of it is, but most isn't. But it's well understood, matches the philosophy of the operating system and doesn't introduce any new tools or mechanisms which have a learning curve on them.
I'm not a Lisp person, but I understand that meta-programming is an integral part of Lisp. On the other hand, parsing comments to extract dependencies is special-casing shell comments for the needs of the init system. That's what I would call a hack.
As for matching the philosophy of the operating system, you go from one process which launches scripts which in turn launch programs, to one process which reads a configuration file in order to launch programs. That's a simplification. It also means that you no longer have an /etc/init.d filled with executable files. And the underlying mechanism used by systemd to order dependencies (blocking on sockets) particularly fits the Unix philosophy.
Mind you, I'm not really comfortable with systemd overtaking udev and syslog (resistance is futile...) but that's a different debate.
Besides, it's more a case of changing from a list of imperative programs replete with code duplication to a declarative model, rather than going from shell scripts to $language_of_the_day scripts. This is what I tried (and failed) to express in my earlier post.
You left out the bit where I said that complaining from the sidelines is pointless. At the moment NetworkManager exists, I focussed on that, not some theoretical situation.
Mageia is forked from Mandriva, and not very old, and Mandriva already has systemd support. I'm not surprised that Gnome has been easy for you to package for your distribution.
As far as I know, none of the BSDs are packaging Gnome 3 right now. Not one of them. Don't you think that might be signaling some trouble?
You're wrong in your assumptions. Mageia did not have systemd support. We do now though, but we had to do that ourselves.
To get systemd right for Mageia one person got involved with systemd and has sent various improvements upstream. Fixing bugs, etc, because nothing is perfect.
In any case, my point is that almost everyone at GNOME uses all kinds of different Linux distributions, so everyone is aware of that.
That GNOME is not packaged on *BSD: Why should that be troublesome if there is no involvement from them? In any case, we do get involvement from OpenBSD, just very little in comparison.
For GNOME, various distributions send patches because a released tarball does not work in their environment. This is often done in the two days between tarball creation deadline and the actual GNOME release. This does not happen too often btw, but this is not limited to any specific distribution.
What I am trying to say is: to make something work you have to work together. If you expect something perfect, I find it logical it turns out as a disappointment.
Lennart has outright said that systemd won't run on BSD (http://lwn.net/Articles/452865/), and now Gnome is saying it won't run (major components at least) without systemd. How is this about BSD devs needing to "work together"? Come on. You're talking about a major refactoring of core aspects of BSD until it becomes, basically, Linux.
I have no idea why you're going off there about "perfect" when that's not what anybody else is talking about.
Don't make this about BSD's involvement. The Gnome team has clearly just made a decision to support Linux, and Linux only.
Lennart has said that systemd won't run on BSD in exactly the same way that OpenBSD have said OpenSSH won't run on Linux. There's a separate portable branch of OpenSSH. Anyone is free to maintain a portable branch of systemd.
I'm not talking about BSD working together. I'm talking to participate. If you don't then you're ignored. IMO I've been quite thorough to explain my point-of-view, would appreciate if you could at least understand what I'm trying to say. An us-vs-them is not helpful.
Which is my point, if you don't involve yourself at all in the discussion, then it is going to be logical that sometimes a decision will be taken which didn't take some issue you had into consideration.
> As far as I know, none of the BSDs are packaging Gnome 3 right now. Not one of them. Don't you think that might be signaling some trouble?
But is that trouble for Gnome, or trouble for the BSDs? I suspect the affected users are a rather larger percentage of the BSD userbase than of the Gnome userbase.
The BSDs are inarguably falling behind when it comes to active, daily, "regular desktop" users, and a lot of that is due to the struggling they're doing with hardware support and with desktop environments. Either the BSDs are going to end up relegated for a long time to server-only OSs (arguably they already have been), or they are going to somehow commit massive resources to catch up (possibly inventing their own replacement pieces along the way), or they are going to disappear completely.
And it is that third outcome that really should make anybody that cares about Linux crap their pants, because the BSDs have some very very nice architectural features and have collectively contributed a lot back to the Linux ecosystem. In some ways, they are way ahead of anything that Linux has to offer. (pf versus iptables is an easy example. I think I would weep with joy if Linux ever threw out iptables and replaced it with pf.)
If the support for BSD dwindles down below a certain point, that's going to be bad for the entire Linux community too.
Unfortunately, a lot of people seem to be either inexperienced in either Linux or BSD and don't know any better, or they are short-sighted and don't see any reason to be concerned about the long-term viability of the other.
Either the BSDs are going to end up relegated for a long time to server-only OSs (arguably they already have been), or they are going to somehow commit massive resources to catch up
Actually, with all the disdain for GNOME 3 and Unity (that I can't fully understand), I think the BSDs actually have a window of opportunity. Make or take a desktop environment that those clamoring for GNOME 2 or KDE 3 love, integrate it very well with your base system, and make a very predictable ABI, ABI, and development schedule. Now that almost everyone seems to be involved in crazy desktop experiments, such an oasis of quiet would probably attract lots of UNIX hackers.
If the support for BSD dwindles down below a certain point,
It doesn't exactly help that there are four major BSDs (if we don't count Mac OS X).
> Actually, with all the disdain for GNOME 3 and Unity (that I can't fully understand), I think the BSDs actually have a window of opportunity.
I agree, but none of the BSD projects has the developer resources to take advantage of that opportunity right now. It would be a massive undertaking, and, unlike many other aspects of OS development, would require very serious long-term commitments. That's what makes this new screw-you attitude in Linux upstream so frustrating for the BSDs; it's taking groups of developers that are already stretched really thin, and it's placing even greater demands on them, and for pretty silly reasons in some cases. You really can't blame the BSD developers for feeling sabotaged.
So I think it's more likely that another desktop environment project that still has sane developers, like xfce, will end up getting some more activity while being easier to install on the BSDs (and consequently better supported there).
> It doesn't exactly help that there are four major BSDs
Yeah, the fallout between NetBSD and Theo was unfortunate. Each of the BSDs has a specific focus now that doesn't really fit with the others; I'd bet on them all evaporating rather than merging.
> Make or take a desktop environment that those clamoring for GNOME 2 or KDE 3 love, integrate it very well with your base system, and make a very predictable ABI, ABI, and development schedule
The reason that KDE 4 and GNOME 3 are tragedies is that the KDE 3 ecosystem is way too big to replace. Hundreds of developers worked for years to build KDE 2.x and 3.x.
We have the source code for KDE 3.5, it's just not practical to maintain it with the resources and manpower available outside the project.
If it's not practical to merely maintain existing code, I'm not sure I have words for how hard it would be to create a viable replacement. Mind-boggling. Stupendous. Impossible.
>It doesn't exactly help that there are four major BSDs
Yes it does. This weird misconception that all the developers of different BSD lineage OSes would all be working together one a single system otherwise is ridiculous. There are 4 because the people working on them wanted 4. If netbsd disappeared, those developers wouldn't just switch to an OS they don't care for, and aren't interested in. Having 4 OSes means there are more developers in total, and given the licences, code is shared between the 4 systems. It is entirely a gain for all 4 of them to have the other 3 exist.
Except that Linux pretty much shows that a focused effort has far better chances to succeed. Even after the AT&T/Novell lawsuit, FreeBSD was technically mostly ahead of Linux, it also had a license that was more attractive to business. Still, Linux got ahead and became more popular. Even among companies.
I have no idea what you are trying to say. You don't appear to have read what I said at all. There is no magic "just be focusing" power. You can't just tell people to stop doing what you want, and start doing what you don't want because some random guy on the internet thinks it will make some random software you don't care about more popular. The netbsd devs don't care about making freebsd more popular, deleting 3 of the BSD lineage operating systems won't make a focused effort on the remaining one, the remaining one would still be right where it is now, and the devs of the other systems would simply not be involved. This would be a loss, not a gain, as the remaining system would no longer have 3 other OSes to pull code and ideas from.
You are doing the equivalent of saying gnome developers should just delete gnome and start working on KDE instead. The gnome developers aren't interested in KDE. If they were, they would be KDE developers, not gnome developers. This is the same with the BSD lineage operating systems. NetBSD developers aren't going to become FreeBSD developers just because you think it would make them do better in a popularity contest they didn't enter. If they wanted to develop FreeBSD, they would be doing so.
But even if no-one's using desktop BSD, the interesting code in it won't disappear, and neither will the people who write that code. Perhaps I'm being short sighted, but I don't see much danger to the Linux ecosystem from BSD's userbase dwindling.
Good software isn't like a real-world monument; people don't spend effort to go back and revisit it later and gawk at it. Good software either gets championed by someone, or it fades forever into obscurity. (I wrote a really amazing hack years ago ... in COBOL. Maybe you've heard of me?)
Likewise, the people that are contributing to BSD right now are doing so because they believe in what they are working on. Although some of them are true cross-platform developers, many others would never make the switch. It would be agony trying to work in Linux if you're, say, Theo de Raadt. Seriously, I wonder if that might be his own personal version of hell.
I use a lot of both -- Debian, an Arch-like thing, OpenBSD, FreeBSD, and have for years. The only reason that I know that iptables has serious shortcomings is because I've used pf. If I had never used the BSDs, I would have no idea what I was missing out on. If I had twenty more hours in a day, I might even be tempted to make iptables more pf-like.
pf is kind of my go-to for BSD cheerleading, but it shines in other core areas too. For instance, Linux is really only just now getting stuff that looks like a distributed or cluster file system; but BSD has had this for quite a while already. Heck, one of the best options for a while in this area was HAMMER, developed by one guy for his personal BSD. And if you wanted something a little bit more mainstream, FreeBSD has supported ZFS for a long time -- Linux is still catching up there. Or, there was the new malloc that OpenBSD developed a few years ago, that ended up revealing old memory-related bugs in all kinds of software (e.g. http://undeadly.org/cgi?action=article&sid=2008070815522...).
There's simply no way that all those people would be doing the same kind of work in the sort of environment that Linux is fostering right now.
I think, being a BSD user, we're probably not concerned much about that. Gnome 3 accounts for a miniscule proportion of users. It's less relevant that Gnome 3 doesn't work on BSD to the BSD projects than Gnome if you ask me.
Bad PR for Gnome would cost more than bar PR for BSD.
Anyone is free to help out and ensure that GNOME runs on BSD. But if nobody spends any effort, then don't complain when it goes wrong.
At the moment even the feedback is pretty bad. There is 6+ months of development all done in the open, to only hear much later that some decision made 9+ months ago had a unforseen side-effect.
I can choose between giving up a simple, reliable OS or giving up a convoluted and obnoxious desktop interface that is essentially indistinguishable from the competing convoluted and obnoxious desktop interfaces. Guess which one I am likely to choose.
> As an example to back my point up, one of the reasons Windows is so damn popular is that the API is incredibly stable and software written in the mid-90s still works fine on current versions without a recompilation or any API changes.
Windows started from a different position. Backward compatibility makes sense when you have all the applications. And it results in you having to maintain a sh*tload of legacy APIs and modules. Microsoft has a different budget and works as a stricter organized company. Linux Desktop lacks the manpower. But on the other hand Linux has to move forward.
It certainly has to settle down a bit in the future. But things like NetworkManager, PulseAudio, Systemd, Wayland are introduced because they solve existing problems. You can certainly argue about implementation aspects but I don't think you can argue about the problems they are solving.
> Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine...
What a weird doublespeak paragraph. By "innovate and do cool things," the author seems to mean "ship, and rely on, old versions of software."
I think he's complaining about the "Linux-centrism" of some projects.
What I find ironic is that those Linux focused projects are turning more like BSD: a tightly coupled system.
If I want my app to work best with X and I need to interact with some stuff that it's only available on X, that's it. I may provide an alternate way of doing things, but I may not.
For example: I may use DBus to speak with NM to see if I the system has network connectivity, but what if DBus or NM are not available? Some time ago you would put effort on that possibility, now you may not because... DBus and NM are everywhere!
That's what is changing I think, although I'm not sure if Espie means exactly that.
In some cases it's the "brand" thing I can't understand, like "only for Ubuntu" that started about 2-3 years ago.
> Some time ago you would put effort on that possibility, now you may not because... DBus and NM are everywhere!
Which sounds like a good thing. People have put in a lot of effort on things like DBus and NM, so that applications can use a consistent, reliable API. That's rather a waste if every application author still has to handle the case when they're missing. They're valuable precisely because we can build on top of them.
I'm slightly playing devil's advocate, but that's actually pretty close to my real view.
He means more that some software is not shared (or available to) with everyone. Systemd is very explicit in that only Linux is supported. I guess pulseaudio is also a problem.
A large part of open source is to share the source code so that others can take that work and do their own cool things / innovate. But then it has to be available.
Yes but isn't that a core problem, if you want to make the best use of something (in this case Linux) you will want take advantage of all the features it offers.
From what I gather the problem is that other systems (in this case *BSD) doesn't support certain features either because they don't mesh well with the BSD system(s) and/or has a lack of manpower to implement them.
The Linux Desktop can't stand still to accommodate some minor platform. I understand that a move to systemd and in the future to wayland will have problematic consequences for BSD support. But the changes are made for good reasons and to bring the Linux and Free Software Desktop forward.
Systemd is much better for Desktop uses. The major reason is that it is fully designed to support hotplug. Which is something you have to constantly deal with on Desktop/Laptop systems. Disks are plugged in, Network connection isn't ready, and so on. It is also much faster and has a lot of other nice features. The lack of systemd support in *Ubuntu might be the reason for me to switch to another distribution for my Desktop.
Wayland finally allows us to get rid off all the legacy crap we have to carry around with X11. There is a reason why it is developed by the Xorg devs.
Pulseaudio had its reasons as well. Such as having useful support for Bluetooth- or USB-audio. Per-application audio settings and so on.
Of course you can argue with certain details in certain implementations. But I don't think that we can argue about the problems those solutions solve. Maybe you are happy with the setup you've been using since the 90s. But for most people the times are changing.
It is certainly sad that the BSDs don't have the manpower to keep up. However we can not expect the Linux Desktop to stand still because of them. The Linux Desktop itself lacks manpower and is fighting an uphill battle. Supporting minor systems will only drag it down.
> Systemd is much better for Desktop uses. The major reason is that it is fully designed to support hotplug.
This is exactly why upstart was invented, long before systemd existed.
> Which is something you have to constantly deal with on Desktop/Laptop systems. Disks are plugged in, Network connection isn't ready, and so on. It is also much faster and has a lot of other nice features. The lack of systemd support in *Ubuntu might be the reason for me to switch to another distribution for my Desktop.
Ubuntu uses upstart, which handles everything that you have specified just fine. You may well have a good reason to switch away, but you have failed to state your case here.
> This is exactly why upstart was invented, long before systemd existed.
Except that upstart didn't deliver too much, unlike systemd. Fedora used upstart (RHEL6 still does) and it wasn't very different from the traditional SysV init. I also wasn't able to figure out how to use it to its full potential, it looked too complicated. On the other hand perhaps I'm biased because Lennart provided a series on systemd for administrators.
The changes to X11/Weyland are an even bigger issue for non-Linux platforms than Gnome.
Even if the BSDs had unlimited manpower it would be extremely inefficient to try to keep track of all the changes to what has become a Linux specific project.
systemd is not better than init for any use right now. My guess is that it is unlikely to ever be, but predictions are hard, especially about the future. As far as pulseaudio, it's basically a bloated version of esd, which was another project trying to solve the same problems that also sucked.
I'm taking a "wait and see" approach to Wayland. Clearly X needs to die. Many times before people have tried to kill it and it's still here; Wayland seems to have a lot of backing though.
>The Linux Desktop can't stand still to accommodate some minor platform.
The current strategy of charging backwards at full speed doesn't seem like a great plan though. We're not getting closer to linux on the desktop being plausible, we're getting further and further away. Making a typical linux desktop system even more complex, brittle, and fragile than windows is not a good way to compete with windows.
The development within Linux is going much quicker than anything else can keep up. Within GNOME only very recently we got some non-Linux using contributors. Portability just for portabilities sake is not a goal anymore.
This is somewhat ironic, as excluding OpenBSD feels way too similar to how Linux is/was excluded in favour of Windows. But if almost all the people spend their time to make their Linux distro better, then this seems like a natural thing to occur.
Hmmm... well I certainly see the problem from 'their end' in that they find themselves 'incompatible' with external projects on which they have relied on since they are nowadays increasingly being developed with 'Linux in mind'.
However it's also hard to fault the obvious urge from Linux and the surrounding Linux-oriented ecosystem of making sure components integrate better so the result is a 'full system' which takes advantage of advancements made to the Linux kernel and it's surrounding core components.
I can't say one is right and one is wrong, I guess it's all about which side of the fence you're on.
When OpenBSD was pissed off by proprietary HSRP protocol designed by Cisco, they decided to implement their own protocol (not compatible with HSRP) and use the same IP protocol number 114 without IANA approval. http://en.wikipedia.org/wiki/Common_Address_Redundancy_Proto... This created a serious mess for system administrators and gives a good example of how to handle compatibility and standards related issues ;)
I guess IANA should have given them a protocol number like they requested then, instead of playing politics because cisco employees run the organization.
Sure, but OpenBSD could have chosen some reasonably safe number that would not be in obvious conflict with Cisco equipment and would make users life easier. Instead they decided to have a childish revenge on Cisco.
It didn't make our life any harder, and using a different number wouldn't make our life any easier. We use cisco, juniper and openbsd, this caused exactly zero problems.
Yeah, that is a hilarious attempt to misrepresent the situation. Notice how he pretends they did it "to strike back", when they actually did exactly what he wants (try to get a number from IANA) and they refused to give them one because "that's just VRRP but different, it doesn't deserve its own number". The right choice was taken away from them, all they could do is use a number that is either used already, or will be handed out later. They chose the least bad option of using the number of VRRP, which IANA claimed they were too similar to.
Note that some of these things are grumbled about within the Linux community too - there's plenty of complaining about pulseaudio, and systemd is very unlikely to ever be universally used by Linux distributions.
Starting from small things, it would also be great to stop using #!/bin/bash in scripts for no apparent reason (hint: "it's my default shell" is not a good reason.)
It isn't a choice between "do it wrong A" and "do it wrong B". There are a whole host of options, one of which is "do it right". Relying on a non-standard shell to be in /bin is bad, relying on non-standard shell extensions to be in the standard shell is also bad. So either use the standard shell as the standard shell, or use whatever nonstandard shell you want by calling env to find it.
I am not well versed in shell magic, but this one bit me quite a few times because, being on FreeBSD, my bash lives under /usr/local/bin (and I installed it just for the scripts written by other people, too).
I'd like to ask you what can I do with this, ie. how can I modify those scripts so that they work both on my machine and on others'? I don't want (obviously) to symlink bash executable to /bin. I guess that using plain sh, which actually is in /bin wouldn't be good either, because (I suppose) if author wanted bash it was on purpose. How to write shebangs so that they are compatible with Linux and BSD at the same time?
I would love to see a group of hackers get together to create a real (i.e. not a weak ARM device) computer and operating system, for profit, but open source. It seems like people have mostly given up on this notion, as if its impossible to create a competing device. In the 70s/80s, a few people launched brands like Apple, Microsoft, and Amiga; I know things are harder now but it is far from impossible.
Why for profit? So that people have both an incentive and means to work on the product fulltime.
I find systemd & others are hurting Linux as much as it hurts BSDs.
In fact, just look at the ArchLinux forums, its FILLED with systemd issues. And most people know by now about the "disable pulseaudio, use pure alsa" trick to solve "all Linux audio issues". Heh.
The case for Linuxism is that Linux has the underlying tools applications require to deliver the user experience users want, and if OpenBSD (and this is from an OpenBSD list) wants to run those applications it should provide the same tools.
A better case against Linuxism is that portability encourages modularity, which is good for reasons far beyond portability. Having to do some things in a different module because they can't be done the same way on all systems encourages you to separate concerns, which leads to code that's easier to reason about and, therefore, less likely to be buggy.
The historical perspective is "You think this is bad, sonny, be glad you're not trying to convince people to play nice with Eunice." (Eunice was a Unix-like environment running on VAX/VMS.)
Start here: http://lwn.net/Articles/520892/
Core parts of Gnome (and probably lots of other Linux-y software, I haven't been following all of it) are all moving to require systemd. Systemd certainly promises a lot of advantages, like better handling of removable devices (and more: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530), but it is also replacing the tried-and-trusted rc approach. OpenBSD leaders in particular are concerned about systemd from a security standpoint; it has a lot of code that runs as root, it is big and unwieldy and the documentation is a mess.
So, not only were the OpenBSD developers faced with either auditing the entire systemd code base -- and then doing it again every time there's a new release -- or attempting to re-implement it in a compatible way, now they're also staring down the very short barrel of a nasty gun in which some really big stuff is going to stop working if they don't deal with it.
It's a real ugly situation, and OpenBSD really doesn't have the resources to spare to deal with this kind of nonsense. I wouldn't be surprised if this mess ends up tying up a couple of their core developers at an upcoming hackathon, where they could instead be working on something more useful than having to replace a huge part of the system that was working just fine up until Linux decided to throw it out. (Obviously there are plenty of people that would argue it wasn't "working just fine", either because they have specific knowledge about it or because "otherwise we wouldn't have needed systemd". That's not sufficient justification for forcing other developers to waste tremendous amounts of effort to re-work what was already working for them.)
Personally, I'm not a huge fan of the switch to systemd. I liked rc scripts. I've cobbled together my own rc daemon scripts from time to time; I'm not sure how that will work with systemd. I'm also seeing lots of ugly and persistent problems in NetworkMangler and whatever they're using for core audio these days; I'm a little gobsmacked that, rather than fixing those problems, some people decided to replace the init system.