Slashdot Mirror


Squaring the Open Source/Open Standards Circle

Andy Updegrove writes "Before there was Linux, before there was open source, there was of course (and still is) an operating system called Unix that was robust, stable and widely admired. It was also available under license to anyone that wanted to use it, and partly for that reason many variants grew up and lost interoperability - and the Unix wars began. Those wars helped Microsoft displace Unix with Windows NT, which steadily gained market share until Linux, a Unix clone, in turn began to supplant NT. Unfortunately, one of the very things that makes Linux powerful also makes it vulnerable to the same type of fragmentation that helped to doom Unix - the open source licenses under which Linux distributions are created and made available. Happily, there is a remedy to avoid the end that befell Unix, and that remedy is open standards - specifically, the Linux Standards Base (LSB). The LSB is now an ISO/IEC standard, and was created by the Free Standards Group. In a recent interview, the FSG's Executive Director, Jim Zemlin, and CTO, Ian Murdock, creator of Debian GNU/Linux, tell how the FSG works collaboratively with the open source community to support the continued progress of Linux and other key open source software, and ensure that end users do not suffer the same type of lock in that traps licensees of proprietary software products."

23 of 255 comments (clear)

  1. Open Standard != standards in Open Source by El_Muerte_TDS · · Score: 4, Insightful

    This article is more about standards in Open Source development, specifically Linux
    To me Open Standards are much more important than Open Source. Open Standards allow Open Source solutions to be created that are compatible with the other solutions.

    1. Re:Open Standard != standards in Open Source by S.O.B. · · Score: 3, Insightful
      Thridly, Libraries need to be rehashed to have far better backward compatability. IF I have glib 22.9.8.3 and a app that is compiled against 7.2.1 the app had damn well better run under 22.9.8.3 and what moron thinks it's a good idea to link against a specifically named lib instead of it's normal generic symlink? How many times have you installed and app and found it looking for a specific version of a lib in the /lib directory instead of the generic symlink?

      I totally agree. I've had Java programs compiled with 1.1 still run under 1.5 (aka 5.0). I've also seen mainframe programs run for almost a decade without needing to be recompiled. In the Linux world you can't have a 0.0.0.1 change in the glib or kernel version without having to possibly force a recompile.
      Finally - pick a fricking installer/packager and use it. IF you all love RPM so much then let's all use it. An RPM for Ubuntu should work flawlessly for REdHat,Mandrake,and Slackware. There is no excuse for them to not. I know that I will get pages of excuses from people on this point but I counter with the fact that XFCE, Mozilla, Crossover office, can all install on any distro... Are they simply that much better programmers than the rest of you?

      I'm glad it's not just me. Try explaining to anyone outside the Linux community that they can't install a particular program because the RPM they just downloaded wasn't created for their distro, kernel version, glib version and has dependencies on a dozen or so libraries that are either missing on their machine or are incompatible with the ones already installed. Now I know that there are a ton of tools out there to help you with this but they aren't exactly for the casual user.

      It's this type of situation that drives people to Windows and will keep Linux as a distant second place.

      Now before anyone labels me a Linux hater, I'm not. I just think it could stand some improvement to make it easier to use in order to reach a larger audience.
      --
      Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
  2. It aint open standards that "killed" Unix by yeOldeSkeptic · · Score: 5, Insightful

    Unix was killed by the high price of licenses. Unix during the early 1990's was supposed to be for the big boys --- the enterprise customers willing to pay up to 10,000 USD per seat for a Unix license.

    With the license for Windows NT starting at less than 1000USD, the enterprises which formed the majority of the paying Unix customer base soon found a way to make do with NT and delete their Unix installations.

    It wasn't open standards and the fragmentation that did Unix in, it was plain hubris among the Unix vendors who cannot fathom a future where a cheaper Windows NT would replace the robust, stable and widely admired Unix they are selling.

    1. Re:It aint open standards that "killed" Unix by IntlHarvester · · Score: 4, Informative

      While that might have been true, there was a standards brawl called the "UNIX Wars" right before Windows NT showed up. So clearly some people were frustrated with the state of standardization in the Unix world.

      UNIX vendors also basically stopped workstation development (X11, Motif, CDE etc) in the early 90s when NT showed up, giving up the desktop without much of a fight.

      --
      Business. Numbers. Money. People. Computer World.
  3. Does it handle KDE/GNOME install paths already? by vdboor · · Score: 4, Informative
    The talk about the LSB is nice, but one of the major problems of Linux is the diverse locations where KDE and GNOME are installed. Some use /usr, others use /opt/kde3, or /opt/kde/3.x. Does the LSB already address this issue? These diverse paths are the main reason I can't deploy one RPM/DEB/TGZ package for all Linux distributions.

    All mainstream package formats have the full installation path hard-coded in the archive. LSB does not address this yet. The other problem of RPM, namely binary compatibility between different library versions, is already solved by compiling with apbuild. This works surprisingly easy, and allows my to provide one single package that can be installed everywhere [1].

    [1] I can recommend to compile packages at Slackware because Slackware ships most packages without patches. Compiling an app at SuSE for example, made binaries depend on ABI changes caused by SuSE patches.

    --
    The best way to accelerate a windows server is by 9.81 m/s2 ;-)
    1. Re:Does it handle KDE/GNOME install paths already? by linvir · · Score: 3, Insightful
      Basic inconsistencies like these frustrate people attempting to switch
      Wrong. Nobody switching to Linux gives a shit what directory their KDE is installed in. Believe it or not most people have more important criteria that they demand from their computers, and are much more likely to switch back to Windows if they are required to look in their KDE directory in the first place.

      "If you want a product more like Windows, then use Windows. We don't want our product dumbed down."
      This is the OSS Godwin. People turn to the OMG WINDOZE!! argument when they know that they're wrong and their elitism is threatened. Unless you know for a fact that you got that response from developers, I'm willing to bet it came from newly converted teenagers itching to shit on their old OS and get closure on their newfound superiority.
      The basic file structure of GNU/Linux needs a major overhaul. Furthermore, now that we have menu standards that both KDE and Gnome use, is it too much to ask that programs include themselves in the menu when you install them?
      These two points are very related. Just how hard can it be to have a standard menu.xml file that can be read by all WMs and DEs that use the menu concept? You could have them all keep their own private one too, so as you don't get a load of slow KDE apps polluting the menu in WindowMaker, but their locations should be well documented and static. Or even better, every distro could have a central xml file in somewhere like /var, where desktop apps could append themselves into, supplying their name, the location of an icon, and category. Then all the WMs and DEs could simply parse that file for changes periodically.

      But ideas are easy to come by, and even easier to spew out into a Slashdot post. The devil is in writing the code and getting the standards adopted.

  4. Fear of fork. by killjoe · · Score: 4, Interesting

    The article summary is a bit of a flamebait. In order for a product to fork there must be two forces in action.
    1) Licensing that allows a fork.
    2) Frustrated users who feel like they can't shape the future of the product via existing channels.

    This is why there are at least three forks of java and none of perl. I suppose one could argue that the forks of Java are not true forks but attempts at re-engineering but the end result is the same.

    Will linux fork like Unix? Well in a way it already has, there is real time kernel, different kernels for devices etc but not in the way the article talks about it. The article isn't talking about forks per se it's talking about distros. The author seems to have missed the point that the Unix forks were actual forks in the kernel not "just" distros.

    Weird article really. Kind of pointless too.

    --
    evil is as evil does
    1. Re:Fear of fork. by Enderandrew · · Score: 5, Insightful

      Linux is a kernel, not an OS, but in common parlance, Linux might as well refer to the OS.

      As an OS Linux is horribly fragmented. That is why people flock to a popular distro like Ubuntu, regardless of whether or not it is the best distro.

      Personally, I do believe that the community needs fewer distros. There should be three methods for installing, period. Something like apt-get, emerge and then installing from a downloaded RPM. You shouldn't see different binaries for different distros. A Linux app should be an Linux app, period.

      If we had true standards, we'd have fewer distros. But how many methods and standards do we have for installing programs? For file structures? For menu structures?

      In what I believe to be a perfect world, there would only be maybe 8 major distributions of Linux.

      Home/Personal
      Developer
      Media Center
      Server

      For each of those 4, you get a focus on either GTK or QT apps. Regardless, the file structure, configuration files, menu structure, etc. would be the same for every distro.

      And while this will NEVER happen, I think we need one major development kit, instead of GTK vs QT. When it comes to aesthetics, visual style and usability, I can certainly understand people wanting a choice between Gnome and KDE. But when I design an app, I should build it on one toolkit, and then it should work on both Gnome and KDE, letting Gnome/KDE handle how it looks, etc. As it stands now, the dependency chains are ridiculous. If I use KDE but want a few GTK apps like Firefox or GAIM, I have to install half of Gnome.

      --
      http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
  5. But who IS certified? by wandm · · Score: 5, Interesting

    I'd like to support the nonfragmentation of Linux - as I guess many would. But looking at the LSB 3.0 certified list http://freestandards.org/en/Products, just shows Red Hat, SUSE and Asianux. Are these all the choices I have?

    Could someone please explain me?

  6. Splintering by ronanbear · · Score: 4, Insightful
    Splintering is also something that helps Linux innovate so rapidly. If you have a good idea and are willing to do the work you can pick a distro that suits your needs. If there isn't one for you or the distro maintainers aren't receptive to your ideas you can fork a distro and experiment on your own.

    Sure this leads to some incompatabilities and duplication of work but there are several ways for developers to mitigate this. Open standards are essential as they allow code be ported between distros rapidly. Another good idea is for devs to be involved (in some way) with using multiple distros. Different projects could work together more closely to achieve better interoperability.

    Its an essential aspect of forking to accept that many forks are dead ends and should be allowed to die or merge back into the tree where desirable. There are many good projects out there and it isn't really in everyones interest to reinvent the wheel continuously.

    --
    the more they over-think the plumbing the easier it is to stop up the pipe
  7. Karma Burning by Big+Sean+O · · Score: 4, Funny

    All your (Linux Standards) Base are belong to us.

    --
    My father is a blogger.
  8. NT didn't displace UNIX by drsmithy · · Score: 5, Insightful
    It displaced Netware.

    Similarly, Linux isn't displacing NT, it's displacing commercial UNIX.

    The overlap of functionality between NT and Linux is, really, quite small. There aren't many cases for which Linux is a good solution, where NT could also be (and vice versa).

  9. LSB is a misleading, limiting and silly name by munro · · Score: 5, Insightful

    The funny thing about the LSB is that it concerns APIs for use by userland programs -it has _absolutlely nothing_ to do with the kernel. All of the requirements for LSB compliance concern calling conventions, executable formats, libc, POSIX facilities, filesystem layout an other extra-kernel configuration, most of which any UNIXoid system could support.

    There are no obstacles to Darwin, *BSD and Solaris systems meeting LSB compliance, because it has nothing to do with kernels and everything to do with the specific details of a UNIX userland environment.

    Generally I don't get into 'Linux' vs 'GNU' discussions but the LSB is once case where I feel the name 'Linux' is used completely inappropriately.

  10. Re:Unix is dead by ems2 · · Score: 4, Funny

    "Not only is UNIX dead, it's starting to smell really bad." - Rob Pike 1991

  11. Re:Unix is dead by FidelCatsro · · Score: 3, Funny

    Oh dear, This means I have a room full of Zombies at my office

    --
    The only things certain in war are Propaganda and Death. You can never be sure which is which though
  12. FUD alert by Cardinal+Biggles · · Score: 3, Informative

    What's this about "various types of licenses" under which Linux is supposed to be available? Linux is GPL, so forking is possible, but there is no risk of UNIX-style fragmentation because the source is open and copyleft. For somebody to create a "closed Linux" they would have to start from scratch. You can't add closed bits to GPL software and keep them hidden, so any incompatible Linuxes ("fragments") could always be re-connected by users irritated about the differences.

    The nonsense about UNIX displaced by NT and NT in turn displaced by Linux already set off my alarm, but the above really is FUD designed to further somebody's personal agenda.

    It is not possible for UNIX-style fragmentation to happen to Linux, because of the GPL.

  13. Unix never died by Steeltoe · · Score: 3, Interesting

    From the submission:
    Unfortunately, one of the very things that makes Linux powerful also makes it vulnerable to the same type of fragmentation that helped to doom Unix - the open source licenses under which Linux distributions are created and made available.

    I believe fragmentation has very little to do with the issue concerning the doom of UNIX. My three top reasons are:

    1) Price of purchase
    2) Expensive/hard to administer
    3) Stagnation in development

    Users want the cheapest, easiest and most feature-filled solution. It's pretty straightforward actually, and a Personal Computer with Windows was the first to fill the niche, if you leave out Apple.

    Apple lost because they wanted monopoly on _both_ hardware and software, while Microsoft only wanted to control the OS (in the beginning). More importantly, Microsoft was better at hyping/marketing their next generation, something that Apple has learned to do better in the recent years.

    UNIX and IBM lost because they failed to scale down to personal PCs, which is where the commodization of computing happened in the 90's. IBM and other mainframe dealers refused to understand the Personal Computer (too much vested in big contracts), thus the clones took over along with Microsoft Windows while the dinosaurs waited it out.

    Without the IBM PC Clone, the computing world would probably look very different today. In those days it was very attractive to be able to upgrade the PC, exchange parts and use commodized hardware for the whole rig. Many tasks which rented expensive CPU-time on UNIX mainframes, were moved over to PCs during the 90's.

    Fragmentation, no doubt, can be very bad for development, but it is also a boon since it leaves developers free to explore different avenues regardless of politics and limitations. I think once a system becomes popular enough like "Linux", the demand for standardization will pull it together. Hey, even the BSDs keeps compatibility with "Linux".

    What killed UNIX was lack of creativity, focus, commodization, too much control and maybe most importantly: arbitrary high prices just to milk customers.

    Linux may have killed off UNIX (oh what irony), but NT have been beating the crap out of it for many years. Linux and UNIX never actually competed on even terms, because UNIX has already been pretty much abandonded for a long time - it's owners only keeping it for milking the last drops.

    My pet peevee with bash and the GNU utilities is the lack of standards, and lack of further development of the command-line. In that regard, I hope "Linux" can progress without having to be beat by Microsoft releasing a better command-line.

    POSIX is really an antique joke compared to what could be possible via the command-line. So the trap "Linux" might fall into, is the same as for UNIX: stagnation, because most users drool at eye-candy and not the actual implementation in the back-end. However, maybe the cost of switching command-line is not worth the gain, time will tell.

  14. Re:Cpt. RMS to the rescue! by DrSkwid · · Score: 3, Insightful

    If you're going to say it's GNU/Linux because of the wonderful userland (and not because of glibc) then perhaps you should call it Bell-Labs/GNU/Linux

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  15. It was the licensing that killed NetWare. by khasim · · Score: 3, Insightful
    NetWare would broadcast its serial number on the network.
    It killed Netware completely by offering all the network functionality with an operating system! No more installing drivers (ie buying an OS and then buying a NOS, just buy NT and have both).
    You could not install two NetWare boxes with the same serial number. They would kick out all the users. If you had a single license for 25 users, that's all you could have until you purchased more licenses.

    NT did not broadcast its serial number. You could buy a single copy of NT and install it a thousand times. If you needed a new file server or a temporary file server, it was so much easier to setup another NT box.
    Similarly, NT drove off commercial Unixes - you never hear about AIX or HPUX anymore.
    Yes you do. But they're still in the organizations that had them before.

    What has changed is that Windows servers swept through the smaller companies. Those companies never had a *nix box. They might have had LANtastic or NetWare or nothing, but they did not have *nix.
    However, the factors that made the NT market (ie cheap whilst still being good enough for purpose) should be the factors that make Linux kill NT in just the same way.
    Okay, I can agree with you on that.
    The trouble is, that Linux doesn't provide all that - although its price trounces Windows, and its feature set is damn good, it just doesn't have the 'polish' or the standardisation that matters to a business.
    I guess that depends upon what business segment you're talking about.

    Linux has been showing double digit growth for the past 5 years (maybe longer). Businesses are deploying it. At the server level.
    No business will go Linux for general purpose use (ie, if you standardise on a distro to run a particular app, then you're fine, but you have a controlled ecosystem) where users use it to do everything because it doesn't have the "shrink-wrapped" approach to apps.
    Now you're talking about the desktop segment.

    The corporate desktop segment is different than the corporate server segment.

    And the biggest problem with the corporate desktop segment is all the Access databases that have been built over the years.

    The 2nd problem is all the not-supported-or-sold-anymore Windows apps that users "absolutely must have to do my job" that they've acquired over the years.

    Changing 10 servers is easier than changing 10 workstations for users who've spent 10 years with the company.
    This is the big issue, and it keeps Linux in the realm of the hobbyist market (we'll ignore the outsourced, this-is-what-you'll-get approach from a big consultancy).
    You might want to take a look at Google before you talk about "hobbyist market".
    Once those 2 things are there, so I can take a binary package and install it on whichever distro I use (its Linuix after all, isn't it? - at least that's what Joe User will say) then Linux will be accepted a lot more readily.
    I'll have to disagree with you on that.

    While that would be nice, it is far more likely that one distribution will become dominant and that distribution's structure will become the de facto "standard".

    And it seems we're already on that path with Red Hat and Ubuntu.
  16. Fragmentation is desirable. by erktrek · · Score: 3, Informative

    I thought forking and merging (thanks to the license) are strengths of Linux. It's an evolutionary development process where the best or most popular ideas rise to the top. Basic standards arise out of the most widespread/adopted projects.

    It's hard for me to see in this chaotic (but necessary) environment how much external control developers are willing to have "imposed" on them by such standards - unless of course from a development/technical standoint it makes sense.

    My understanding is that Linux really isn't in the game of competing with anybody (Unix, Windows or otherwise) anyway. it's just about the code, love of things computers and a new way of doing things.

    E.

  17. Ah yes but by The+Cisco+Kid · · Score: 3, Informative

    Linux has one thing Unix never did - if someone forks it and does something innovative, then ther forks/branches can use it too, thanks to the GPL. The varous 'Unix' flavors didn't allow that.

  18. It was a Number of Things by Greyfox · · Score: 4, Insightful
    Fragmentation was never the biggest issue -- you tended to buy one vendor's UNIX for your shop anyway. For the most part a C program compiles cleanly between one UNIX and the next, though HP/UX 9 was a bit odd when it came to networking code. UNIX licenses weren't cheap back in the day and they didn't make UNIX run on cheap PC hardware. Back in '89 a base copy of SCO Xenix for the 286 ran about $1200 through Techdata. If you wanted a C compiler, X11, man pages, or TCP/IP networking you had to sprint for all those separately. You could get BSD, apparently, but there wasn't a lot of easily accessable information on installing it and it sounded like it'd be an exercise in arcane lore.

    There was an arrogant attitude toward PC hardware in the mainframe and workstation market. If you wanted to do real computing, you wouldn't use a PC -- those were just toys! Drop 15 grand on our workstation and then we'll talk. Well PC's WERE toys for a few years, but you had to have blinders on to see that they weren't going to make progress. That arrogant attitude persisted while the 386 and then the 486 came out, while all the while Windows NT and to a smaller extent OS/2 started stealing more and more business from the traditional UNIX vendors.

    And while the UNIX vendors arrogantly believed they had a better product, not a single one of them ever made an effort to push the GUI portion of UNIX beyond CDE (Well... except NeXT and SCO, but SCO's offering was a step back from CDE.) Gnome, KDE and Enlightenment were all efforts of the Open Source community and to my knowledge Sun's really the only one of the old guard to even consider using one of them. Hell, even Afterstep is a step up from the commercial vendors' offerings.

    In the end it was cheap Intel hardware and cheap Intel operating systems that did the old guard in. Windows on a pentium made a server that worked well enough that it was impossible to justify the price jump of an order of magnititude to get just a little bit more. And I doubt there are more than a handlful of companies that would even consider putting UNIX on an employee's desk. Had the old guard of UNIX vendors played their cards right and embraced PCs as a natural extension of their high-end UNIX systems, things might have gone differently.

    The current situation is rather interesting. The cost of Windows licenses is significantly more than the cost of Linux licenses. Microsoft can't really compete with free, so they have to find other avenues of attack. That, more than fragmentation, is the biggest danger to Linux. Most commercial companies only deal with RedHat or SUSE anyway. I don't know what the future will bring, but we most definitely live in interesting times.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?