7 ms·

Upstream vendors and why they can be harmful

122 points by rohshall 14y ago

derefr 14y ago
> 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."
- deleted 14y ago
  [deleted]
- bkor 14y ago
  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.
  - gillianseed 14y ago
    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.
- reidrac 14y ago
  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.
  - takluyver 14y 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.
    - reidrac 14y ago
      Having used DBus in a couple of projects, the "consistent, reliable" part of your comment made me chuckle :) I agree with you. Having APIs makes everything easier and it means developers building on top of them can focus on more productive stuff. In fact I think freedesktop.org should be more relevant.
bkor 14y ago
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.
derleth 14y ago
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.)
deleted 14y ago
[deleted]
caf 14y ago
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.
gillianseed 14y ago
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.
meaty 14y ago
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...
- cperciva 14y ago
  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.)
thaumaturgy 14y ago
This submission won't make any sense without a little bit of background. (The comments here at the moment are all predictably confused.) Start here: http://lwn.net/Articles/520892/ 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 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.
- darklajid 14y ago
  Thanks for a little bit of context. 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).
blaze33 14y ago
Wouldn't it be more appropriate to talk about LinuxDesktopism? There I see part of an explanation regarding the opposite market shares between the server/HPC and desktop worlds.
olgeni 14y ago
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.)
- pja 14y ago
  I'd far rather people did that than used #!/bin/sh and assumed that sh was bash!
  - papsosouid 14y ago
    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.
- klibertp 14y ago
  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?
  - jsnell 14y ago
    The standard hack for that would be: #!/usr/bin/env bash
gavanwoolery 14y ago
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.
- dman 14y ago
  Indeed. What we need is a yet to be created firm with the engineering ethos of Trolltech attacking the problem that Apple is right now.
mixedbit 14y ago
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_Protocol 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 ;)
- papsosouid 14y ago
  I guess IANA should have given them a protocol number like they requested then, instead of playing politics because cisco employees run the organization.
  - mixedbit 14y ago
    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.
    - papsosouid 14y ago
      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.
      - mixedbit 14y ago
        I'm sorry if this isn't accurate assessment. I based it on the ACM column: http://queue.acm.org/detail.cfm?id=2090149 http://queue.acm.org/detail.cfm?id=2090149
        papsosouid 14y ago
        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.
fafner 14y ago
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.
- riffraff 14y ago
  > The lack of systemd support in *Ubuntu might be the reason for me to switch to another distribution for my Desktop. are the advantages of systemd over upstart so strong for desktop use?
- rlpb 14y ago
  > 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.
deleted 14y ago
[deleted]
zobzu 14y ago
I'm a 100% Linux user 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.

122 points by rohshall 14y ago

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

deleted 14y ago
[deleted]
bkor 14y ago
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.
- gillianseed 14y ago
  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.
reidrac 14y ago
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.
- takluyver 14y 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.
  - reidrac 14y ago
    Having used DBus in a couple of projects, the "consistent, reliable" part of your comment made me chuckle :) I agree with you. Having APIs makes everything easier and it means developers building on top of them can focus on more productive stuff. In fact I think freedesktop.org should be more relevant.

bkor 14y ago

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.

derleth 14y ago

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

deleted 14y ago

[deleted]

caf 14y ago

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.

gillianseed 14y ago

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.

meaty 14y ago

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

cperciva 14y ago
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.)

thaumaturgy 14y ago

This submission won't make any sense without a little bit of background. (The comments here at the moment are all predictably confused.) Start here: http://lwn.net/Articles/520892/ 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 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.

darklajid 14y ago
Thanks for a little bit of context. 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).

blaze33 14y ago

Wouldn't it be more appropriate to talk about LinuxDesktopism? There I see part of an explanation regarding the opposite market shares between the server/HPC and desktop worlds.

olgeni 14y ago

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

pja 14y ago
I'd far rather people did that than used #!/bin/sh and assumed that sh was bash!
- papsosouid 14y ago
  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.
klibertp 14y ago
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?
- jsnell 14y ago
  The standard hack for that would be: #!/usr/bin/env bash

gavanwoolery 14y ago

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.

dman 14y ago
Indeed. What we need is a yet to be created firm with the engineering ethos of Trolltech attacking the problem that Apple is right now.

mixedbit 14y ago

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_Protocol 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 ;)

papsosouid 14y ago
I guess IANA should have given them a protocol number like they requested then, instead of playing politics because cisco employees run the organization.
- mixedbit 14y ago
  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.
  - papsosouid 14y ago
    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.
    - mixedbit 14y ago
      I'm sorry if this isn't accurate assessment. I based it on the ACM column: http://queue.acm.org/detail.cfm?id=2090149 http://queue.acm.org/detail.cfm?id=2090149
      - papsosouid 14y ago
        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.

fafner 14y ago

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.

riffraff 14y ago
> The lack of systemd support in *Ubuntu might be the reason for me to switch to another distribution for my Desktop. are the advantages of systemd over upstart so strong for desktop use?
rlpb 14y ago
> 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.

deleted 14y ago

[deleted]

zobzu 14y ago

I'm a 100% Linux user 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.