Linked by Oliver on Fri 11th Mar 2011 23:32 UTC
GNU, GPL, Open Source "Now that Linux is the most popular free Unix-like operating system, it shouldn't be a surprise that some projects have begun treating non-Linux operating systems as second-class citizens. This isn't out of contempt for the BSDs or OpenSolaris, it's just a matter of limited manpower: if almost all the users of the application have a Linux operating system and if all the core developers are using Linux themselves, it's difficult to keep supporting other operating systems. But sometimes the choice to leave out support for other operating systems is explicitly made, e.g. when the developers want to implement some innovative features that require functionality that is (at least for now) only available in the Linux kernel."
Thread beginning with comment 465845
To view parent comment, click here.
To read all comments associated with this story, please click here.
TheGZeus
Member since:
2010-05-19

It's not really "them and us".
It's two different approaches, and I think it's cool that way.

I use Debian (linux kernel) on most machines, but for something like, say, a music-performance computer, a production server, custom embedded device, I'll be going BSD all the way.

Day-to-day, I want the latest stuff, and I'm fine with working out the kinks myself.

There are two very different thought processes behind both working-on and using BSD/Linuxen, and within the two of them, you get further divisions about what the best method of getting to that goal.

I have much love for the BSDs (though OpenBSD is still somewhat intimidating, and NetBSD will run on a toaster, but not my V880, those are my only complaints. Oh, and the NDA-related modules in FreeBSD, which I can't see myself needing).

You can see a somewhat lesser form of this division within the Linux distros, and even just in Debian!
Sid = Bleeding edge
Testing = Cutting edge
Stable = Solid, and unmoving (and dull ~_^)

Reply Parent Score: 2

oiaohm Member since:
2009-05-30

It's not really "them and us".
It's two different approaches, and I think it's cool that way.


them and us is wrong. But set party putting head in sand over particular items been marked to go end of life and not working on a solution has lead to a lot of the current breakage.

There will always been difference. But the portability divide is only as large as it now due to the need to address problems.

program->hald->kernel and back. Remember context switches are slow.

Hald is legacy of Unix when it did not support dynamic libraries. So there is need for a common dynamic lib to replace hald in some areas. Not a common daemon any more.

dbus even if it was still doing all of Hald. Difference is dbus support per application secuirty. Hald does not.

Lot of tech designs have there time to die. Incompatibility between Linux and BSD has expanded because BSD is simply not ready.

Really it would have been stupid for Linux developers to go out alone and try to design a new common library for all posix platforms if those platforms would not cooperate. Best option is to go on with Linux only solutions and wait for the hell to catch up with BSD and the like.

systemd is based of apple launchd design and expanded on to take advantage of the features Linux kernel offers. Now why is not BSD doing the same.

BSD developers have sat in one place too long that is the problem. Does the BSD service system offer fast startup? Nop. Has linux developers been searching for faster ways to start the system yes. upstart and many other different startup systems to freebsd.

BSD arguement we better wait for the innovation to settle. Fine. We will settle. We will simply not design a system that suits BSD because BSD was not their providing there limits.

Wait for innovation to settle is basically say when you massively have something that now does not suit you stiff. Why innovation is underway design errors can be simply fixed.

To late once the system is design as settled and locked down to be saying lets change features now. That is were BSD is now. Lot of features are locked down based in udev design. Because bsd devd developers were not in the design teams to provide feedback on what they required.

Simple fact waiting for innovation to settle. Is to wait be left in a stuffed up position and become hard to remain compatible. Linux is currently the dominate market share. BSD have to accept this.

Just like when particular Unix's were the dominate market share that if BSD did not take part in the standard processes they got railroaded. Has not the BSD guys learnt from history they got railroaded with posix standard before linux existed.

Reply Parent Score: 1

Soulbender Member since:
2005-08-18

Hald is legacy of Unix when it did not support dynamic libraries.


Uhmm..how old do you think HAL is? Older than shared libraries? Seriously?? This amazing ignorance pretty much disqualifies you from being taken even remotely serious on this topic.

Now why is not BSD doing the same.


Becase they dont want systemd? I havent ever heard anyone in BSD complain about systemd not being portable. Heck, BSD and Linux doesnt even use the same starup system now.

Does the BSD service system offer fast startup? Nop


Yep but who cares? its a pointless, penis-measurement metric.

BSD arguement we better wait for the innovation to settle.


That's not a BSD argument or attitude. Now you're just making shit up.

Edited 2011-03-12 06:24 UTC

Reply Parent Score: 7

TheGZeus Member since:
2010-05-19

tl;dr

Just write it in your native language. I've done translation work, and speak ~4 languages.
Even if I don't speak your native tongue, I'm sure you can express yourself better in your native tongue, and that I have the skills and/or tools needed to translate it well enough for my own understanding.

As it stands 4 sentences gave me a headache.

I know I don't do very well when trying to talk tech/computers in Japanese. I've tried, and failed pretty spectacularly.
(My comedy style suits Japanese/Japan better, though)

Edited 2011-03-12 06:49 UTC

Reply Parent Score: 1

phoenix Member since:
2005-07-11

Hald is legacy of Unix when it did not support dynamic libraries. So there is need for a common dynamic lib to replace hald in some areas. Not a common daemon any more.


Uhm, hald is only a couple of years old. And there were working hardware abstraction / detection layers before it (like devd on FreeBSD).

systemd is based of apple launchd design and expanded on to take advantage of the features Linux kernel offers. Now why is not BSD doing the same.


Because it's not needed? And no one has stepped forward to make a case for it that stood up to even the most basic of questioning.

Does the BSD service system offer fast startup? Nope.


Bzzt, wrong. I can boot a FreeBSD system in under a minute. Of course, I can also boot a Windows XP system in under a minute. And I can configure a Kubuntu station in such a way that it boots in over 2 minutes.

Has linux developers been searching for faster ways to start the system yes. upstart and many other different startup systems to freebsd.


What is everyone's obsession with boot times? If you are rebooting your system so often that you notice a 30s savings ... then you need to reevaluate your setup. Why are you rebooting that often?

Sure, a system boot should not take 15 minutes. But getting to a login screen in 5s, with everything still initialising in the background, isn't anything to brag about either.

I've yet to see anything actually useful in upstart/systemd, other than making it impossible to know exactly how things are working, or to debug things.

There's something to be said for deterministic behaviour (where things always start in the same order and always end up in the same state).

There's something to be said for having a single, human readable *and* human editable text file managing the configuration.

Anyone who says that GRUB2's configuration layout is better than GRUB1's menu.lst seriously needs to get their head examined. upstart vs sysvinit (even with all its warts) is the same. systemd isn't much better (Really? You can't support a system where /usr is a separate filesystem from /? Really? And you don't see a problem with that?)

Innovation is good. Code churn for the sake of code churn is not.

Perhaps if Linux devs put more than 30 minutes of thought into something, actually *designed* something before coding it, sub-systems would last more than 12 months, and downstream projects would actually have time to incorporate all the feature before having to start re-writing things for "new shiny sub-system".

Reply Parent Score: 11

pfgbsd Member since:
2011-03-12


systemd is based of apple launchd design and expanded on to take advantage of the features Linux kernel offers. Now why is not BSD doing the same.


The BSDs have had launchd for a while .. in the ports tree. It may just be that for most purposes the traditional BSD system just works OK, and it's not difficult to install something different (like launchd) for those that need it.


BSD developers have sat in one place too long that is the problem. Does the BSD service system offer fast startup? Nop. Has linux developers been searching for faster ways to start the system yes.


FreeBSD has softupdates: some Linux developers were interested but none had the skills to do it. What's wrong about having different interests?


Simple fact waiting for innovation to settle. Is to wait be left in a stuffed up position and become hard to remain compatible. Linux is currently the dominate market share. BSD have to accept this.


The BSDs will not disappear because linux evolves faster into the unknown. some developers actually *like* stable APIs. The linux community has to accept this.

Reply Parent Score: 2

A420X Member since:
2011-02-02

It's not really "them and us".
It's two different approaches, and I think it's cool that way.


I agree, I wasn't trying to say that there is a them and us situation, more that people in both camps are often too quick to jump to a parochial response to issues like this.

Maybe if there was less of this attitude there would be more willingness from devs in both camps to jump the fence now and again and we wouldn't be forced to choose between "portability and innovation" quite so often.

Reply Parent Score: 1