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.
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...