Crowding out OpenBSD [LWN.net]

Crowding out OpenBSD

Posted Nov 15, 2012 15:04 UTC (Thu) by mikemol (subscriber, #83507)
In reply to: Crowding out OpenBSD by khim
Parent article: Crowding out OpenBSD

I wouldn't dream of "full portability". To me, that includes Linux, Windows, various BSDs, FreeDOS and places with 12-bit bytes. Even outside of practical considerations, to me "full portability" is a phrase that represents a paradox.

The way I see it, you have a tester program with a database of things to check against, and you give it an operational mode for the classes you care about. I.e. "warn me about anything you know of that's incompatible between Xorg and XFree86. Give me an error for anything that's incompatible between FreeBSD, OpenBSD and GNU." or "Give me an error for anything incompatible with unix-like systems [where that would mean common Linux environments, FreeBSD, OpenBSD, QNX...]"

I'm not suggesting the programmer should be demanded to provide support for all known platforms. I'm suggesting a programmer should be able to decide what platforms he'd like to support, get an advance rough idea at the parts of his program that are incompatible with that set, cull his supported platform set down to something manageable, and manage that.

The tool I'm describing would also be useful for people doing the active porting work, since it can immediately draw their attention to the places which need work.

(Log in to post comments)

Crowding out OpenBSD

Posted Nov 19, 2012 9:03 UTC (Mon) by ortalo (subscriber, #4654) [Link]

Hmmm, strictly speaking, it seems that this should even be a reference to the 70s and... C no?

BTW, note that C is the primary unifying factor between Linux and the BSDs in fact... and the main difference with the dominant proprietary OSes.

Crowding out OpenBSD

Posted Nov 20, 2012 9:05 UTC (Tue) by cmccabe (guest, #60281) [Link]

One of Java's slogans was "write once, run everywhere."

I guess the implication was that C programs always required tweaking to run on platforms other than the ones they had been written on, and Java programs would not. Of course it didn't quite turn out that way in practice-- for example, Hadoop is mostly written in Java, and the process of porting it to Windows is still ongoing.

It's hard to find a free lunch in computing. Even harder to find a type of free lunch that someone else hasn't already spent years looking for.

Crowding out OpenBSD

Posted Nov 20, 2012 11:52 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Uhm. I've been running Hadoop on Windows for _years_. The main stumbling block is setting up an SSH daemon, but even without it you can use Hadoop for certain limited tasks.

Crowding out OpenBSD

Posted Nov 21, 2012 21:33 UTC (Wed) by cmccabe (guest, #60281) [Link]

Yes, there's a branch of hadoop called branch1-win that has been modified to work well on Windows. There's a JIRA tracking its progress here: https://issues.apache.org/jira/browse/HADOOP-8645.

Crowding out OpenBSD

Posted Nov 20, 2012 12:11 UTC (Tue) by man_ls (subscriber, #15091) [Link]

The idea was actually that a single "binary" (bytecode actually) could run, unmodified, on several platforms. Yes, "write" here is grossly misused.

Given that the bytecode was in fact interpreted by the VM (and later compiled on the fly), the comparison to compiled languages was misdirected: Java had the inconvenience of having to compile and the slowness of interpreted languages, but none of the advantages. It would have been more appropriate to compare with interpreted languages such as Python or Perl, but then Java would have lost big time since VMs were only available for a handful of platforms and the competition can run, unmodified, on tens. Here by "platform" I mean a combination of OS and processor architecture.

Nowadays Java is JITted and fast. But then again so is the humble javascript...