Open Source Market Segment LS
Open Source Market Segment RS
Thursday, 22 November 2012 08:45

Upstream vendors can harm small projects: OpenBSD dev


A senior OpenBSD developer has complained on a mailing list that upstream vendors of free and open source software are adding in changes without any thought of whether downstream users could adapt to the change.

Marc Espie said this would hurt smaller players by not allowing them to keep up with the changes. Basically what is happening is that numerous changes are being made to Linux and smaller projects like OpenBSD cannot keep up with the changes. And, according to Espie, not all these changes are strictly necessary.

In a Q and A with iTWire, he explained in detail what he was trying to convey.

iTWire: When you talk of breaking compatibility, what exactly do you mean in layman's language?

Marc Espie: Historically, various Unices have been largely compatible with each other. This means that you could take source code from someone and compile it on your machine. On any given project, over 95% of the source code should be directly portable. There are some parts that require some adaptation, but it's fairly easy to keep that in a small part of the project. Then there's gratuitous incompatibility, of two sorts: either not knowing enough and writing code that will only work on some given machine/OS variant, because you don't know better or putting something that you know only exists on your OS at a central point in your project.

If you've been working on Open Source projects for some time, you know that the above tendency has been increasing over time, with a main focus on GNU FSF tools and some Linux stuff.

How does such an action (or actions) hurt the open source community?

Well, it can detract from some other goals. When you start porting some software to OpenBSD, you will often be stopped right at the configure stage. Because it wants bash, or gnu grep, or GNU sed, or PulseAudio. In many cases, none of these are actually necessary. They're just gratuitous incompatibility. But fixing these takes time from doing more interesting work.

Your average Linux people will then ask: what's the problem with bash or GNU grep ?

One first problem is that they're GPL. For BSD people, the GPL licence is not all that great. It takes some liberties from me, as a developer, that I still have with an MIT or BSD licence. I believe in freedom, as in, people should be able to do what they want with my source. And possibly the right thing (as in keep sharing), but not because they're forced to do so, just because they choose to do so. That's a fundamental freedom that the GPL takes away from them.

The second problem is somewhat ironic: back when the FSF was just starting up, RMS (Richard Stallman, founder of the organisation) did say "use different algorithms from existing things, so that we don't infringe on anyone's copyright". That was a good idea, from a technical standpoint as well. Complex systems require interoperability (see the basis for our current network, RFC work on that tenet), and having distinct implementations of basic tools is a great way to discover problems.

But recently, people just say "hey, I don't know the difference between GNU-sed and POSIX sed, so I'm just going to require gnu-sed, because it's easy to install, right?" without even checking whether it's actually needed. (and no, gsed -i is not a valid excuse. Come on, you need half a line of shell script to do the equivalent of gsed -i)

Actually, while working on OpenBSD, like on our implementation of m4, or of libtool, or of make, I routinely run into issues that exist in the GNU versions of these tools. Increasingly, developers have become complacent. They don't even try to be compatible. They don't even realize they are relying on weird behavior in those GNU tools that are not documented at all or even bugs, making it more difficult to run outside of a GNU universe.

We're often faced with one single issue: do we want to be more GNU compatible? Like I said, gsed -i is basically trivial to implement. But it's not POSIX (yet). It's a gratuitous problem when you're actually trying to write portable shell scripts. It's not even such a good option and particularly useful.

We'd prefer to implement options in our tools because they're a good idea, not because we have to emulate GNU stuff.

To make a more colorful comparison: imagine you're cooking a great hamburger, and some friend comes by and tries it and tells you "oh yeah, it's fine, but it does not taste like I'm used to when I go to McDonald's".

Are you going to change your recipe so that it tastes more like McDonald's?

If there is a problem with not having enough people to keep up with the changes in any project, does it not mean that you are unable to attract enough developers, rather than the claim that too many changes are being made by the projects which you are trying to maintain?

The number of developers in a project like OpenBSD is another issue entirely. Attracting new people is somewhat of an issue. The problem here is that it's difficult to keep people focused on somewhat ungrateful work. Gratuitous incompatible changes are just a big mess to sort through and to port to OpenBSD. That's definitely not sexy, not fun work.

Except for very dedicated people, you attract people because they want to do fun stuff. Sorting through someone else's garbage is not very funny, yet that's what you have to do each time you port some "Linux" software.

Yet I'm still with OpenBSD, because we do some fun stuff. One good thing about a relatively small project is that, if you're a good developer, you can quickly gain some interesting responsibilities, and touch a breadth of things that would be hard to be involved in in other projects.

But I would very much prefer that our developer base spend more time doing fun stuff than coping with stupid Linux compatibility issues.

What do you mean by "It's also quickly turning POSIX and Unix into a travesty: either you have the Linux goodies, or you don't. And if you don't, you can forget anything modern..."?

It used to be that POSIX took every good thing from UNIX systems out there and turned that into a standard, with a fair evaluation of what was good.

These days, the standards process is obviously heavily biased towards Linux, even though a lot of interesting things happen in various BSD (and under Solaris, up until Oracle took over), but you won't see these in recent POSIX.

I could talk about the strlcpy() family of functions, which was adopted by almost every open source project out there outside of the glibc, for instance. Or about how, for a lot of tools, if things keep going that way, next version of POSIX will basically document GNU-sed, GNU-make, and GNU-m4...

This is kind of offensive, especially for me, after the number of hours I've spent getting our make and our m4 into something really nice and interesting, and in some parts, totally distinct from GNU stuff, yet implementing most of the current POSIX spec...

Your other quote that caught my attention was "in some cases, you even have some people, who are PAID by some vendors, aggressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in." I guess you are talking, in the main, about Lennart Pottering and Kay Sievers, both Red Hat employees. Is this correct?

I still won't fill the blanks. But I'm reasonably certain some things are not truly necessary, the likes of systemd, to take a recent fairly obnoxious example.

In other cases, there is some delightful irony: tools like autoconf and libtool were built, in the first place, to make working with UNIX systems "simpler" and "more portable". Over the recent years, I've spent WAYS more time *fighting* with that build system to convince it to do things *correctly* for OpenBSD rather than work *with it* to do new stuff.

What do you propose as a solution to keep projects that are smaller from being crowded out? Or is there no hope at all?

Well, the "crowding out" part definitely wasn't mine. Maybe people should realize that Linux hasn't "won", if there was anything to win. Contrary to what people in (Linux Weekly News, a website which wrote about Espie's post without contacing him) did say, there's still a lot of innovation in OpenBSD, and in other BSDs too.

We don't talk about it too much, but seriously, we're still doing real security. You know, not the kind where you add a bunch of stuff on top of a UNIX OS and give a UNIX administrator enough to shoot themselves in the foot ten times over. I still don't get it. Who still thinks that by adding layers and layers of shit to "control" access rights you will get a better system. Capabilities? Everybody is still laughing hard at the old sendmail "compromise".

PAM? Give me a distribution name which never had a major stupid security hole due to PAM. The one reason we still don't have PAM is that THAT security model is flawed. Yes, big corporations and their management will wank all over it. But seriously? A system where you can so easily confuse rights that every distribution got it wrong at some point? And that's secure? Come on. (also, it's a well known non-secret that properly configuring stuff like GRsecurity of SElinux is a full-time job, and that you will often end up disabling it for anything but the most critical stuff, because the added security model doesn't fit with the basic UNIX programming model AT ALL).

Adding sexy features is the easy part. stack protection, W^X, pie. The hard part is making it work, all the way through. Most projects out there have some critical bug-fixes that come from OpenBSD. That includes GCC, KDE, GNOME, Xorg, rsync, Emacs, LibreOffice (I could expand on that list, but I can definitely remember specific bugs in each of these that we had to fix to get those security features to work)

Buffer overflows, buffer underflows, logic errors you name it.

Sometimes, this goes incredibly slow, and this is infuriating. I was involved in several big changes in OpenBSD that took a few releases to polish. In many cases, it got in, we ran into a critical BUG in some external 3rd party software, and it took a lot of time to fix all the 3rd party.

Want a current example? True memory randomization. It breaks all the JITs out there. Both Javascript V8 and all the JDKs expect all their allocated memory to fit within a 2G block of memory... yep, they encode pointer differences into 32 bits integers.

One fun thing about it is that Webkit "works around it" by allocating a big blob of 2G upfront for V8. The irony being that, these days, the browser is the most sensitive part of the desktop, BY FAR, and that you won't get anywhere if you disable Javascript. So you're trusting all your security to a JIT compiler that HAS to have a big blob of 2G of contiguous memory, and hoping there's no hole in there that can lead to running arbitrary code in there ? Like, come on... yeah, it's probably some fairly complicated exploits, and I'm too lazy to even try to write them, but are you sure you're perfectly safe ?

I believe there is hope. Especially since there are several "small" projects out there which can contribute stuff. And heck, Linux isn't sooo sure of its future life anyways. Some vendors are still distributing closed source drivers, and Linux users, as a rule, are fairly complacent about it.

And hey, maybe it's Linux that's going to get crowded out by Android (yeah, I know, it's a Linux kernel. So what? Mac OSX is a BSD kernel for the most part).

If something is not done how is the scenario going to look five or 10 years from now?

I have no idea. I am certain of one thing: a wealthy open source ecosystem benefits from a bit more diversity than just pure Linux and the GPL. Looking at the past, without OpenBSD, you would have no OpenSSH, no bgpd, no pf.

There are some cases where going to the GPL and the GNU build system, like xorg has done, is a step backwards toward isolation.


Read 39722 times

Please join our community here and become a VIP.

Subscribe to ITWIRE UPDATE Newsletter here
JOIN our iTWireTV our YouTube Community here


Thoughtworks presents XConf Australia, back in-person in three cities, bringing together people who care deeply about software and its impact on the world.

In its fifth year, XConf is our annual technology event created by technologists for technologists.

Participate in a robust agenda of talks as local thought leaders and Thoughtworks technologists share first-hand experiences and exchange new ways to empower teams, deliver quality software and drive innovation for responsible tech.

Explore how at Thoughtworks, we are making tech better, together.

Tickets are now available and all proceeds will be donated to Indigitek, a not-for-profit organisation that aims to create technology employment pathways for First Nations Peoples.

Click the button below to register and get your ticket for the Melbourne, Sydney or Brisbane event



It's all about Webinars.

Marketing budgets are now focused on Webinars combined with Lead Generation.

If you wish to promote a Webinar we recommend at least a 3 to 4 week campaign prior to your event.

The iTWire campaign will include extensive adverts on our News Site and prominent Newsletter promotion and Promotional News & Editorial. Plus a video interview of the key speaker on iTWire TV which will be used in Promotional Posts on the iTWire Home Page.

Now we are coming out of Lockdown iTWire will be focussed to assisting with your webinars and campaigns and assistance via part payments and extended terms, a Webinar Business Booster Pack and other supportive programs. We can also create your adverts and written content plus coordinate your video interview.

We look forward to discussing your campaign goals with you. Please click the button below.


Sam Varghese

Sam Varghese has been writing for iTWire since 2006, a year after the site came into existence. For nearly a decade thereafter, he wrote mostly about free and open source software, based on his own use of this genre of software. Since May 2016, he has been writing across many areas of technology. He has been a journalist for nearly 40 years in India (Indian Express and Deccan Herald), the UAE (Khaleej Times) and Australia (Daily Commercial News (now defunct) and The Age). His personal blog is titled Irregular Expression.

Share News tips for the iTWire Journalists? Your tip will be anonymous




Guest Opinion

Guest Interviews

Guest Reviews

Guest Research

Guest Research & Case Studies

Channel News