Slashdot Mirror

Of course it looks rearranged. It's a header file. Some of the ELF constants come straight from the ELF spec. The #ifndef stuff is bog standard code, there are a finite number of ways of writing that and the one presented happens to be the most common. The #include is another "duh" - of course you have to #include the right header, that doesn't mean it's copied. The header file is presumably deliberately compatible with the original, hence the function definitions are prototype-compatible (while being considerably different in style).

There is nothing indicative of code copying in that PDF. The Linux header is just about as different as it can be while remaining source-compatible, as it should be.

Commenting further on that, here is a link to the System V Reference Specs, one of which is the ELF Tool Interface Standard Specification. This contains not only several constants, structures, and function names, but suggests function prototypes and programming style.

Like you said, any author wishing to build an ELF-capable system would almost have to have that exact same code. There are only so many ways to build an enum or struct following the exact TIS specifications, and there is no virtue in paraphrasing C code.

Much of the rest of the code is libc and POSIX prototypes (and more headers), all of which are covered in the System V ABI specification. Anybody wishing to build a POSIX-compatible system would have to define those prototypes.

Several of the function implementations with similarities are very basic functions. Most of the similarities are in the constant names (rather than the specific implementation of those simple functions), and the constant names are defined by ... the TIS spec. The remainder is a no-brainer. See, for example, Tab 422. This is a simple accessor method. There are only so many ways to retrieve a value from a structure...

Of course it looks rearranged. It's a header file. Some of the ELF constants come straight from the ELF spec. The #ifndef stuff is bog standard code, there are a finite number of ways of writing that and the one presented happens to be the most common. The #include is another "duh" - of course you have to #include the right header, that doesn't mean it's copied. The header file is presumably deliberately compatible with the original, hence the function definitions are prototype-compatible (while being considerably different in style).

There is nothing indicative of code copying in that PDF. The Linux header is just about as different as it can be while remaining source-compatible, as it should be.

Commenting further on that, here is a link to the System V Reference Specs, one of which is the ELF Tool Interface Standard Specification. This contains not only several constants, structures, and function names, but suggests function prototypes and programming style.

Like you said, any author wishing to build an ELF-capable system would almost have to have that exact same code. There are only so many ways to build an enum or struct following the exact TIS specifications, and there is no virtue in paraphrasing C code.

Much of the rest of the code is libc and POSIX prototypes (and more headers), all of which are covered in the System V ABI specification. Anybody wishing to build a POSIX-compatible system would have to define those prototypes.

Several of the function implementations with similarities are very basic functions. Most of the similarities are in the constant names (rather than the specific implementation of those simple functions), and the constant names are defined by ... the TIS spec. The remainder is a no-brainer. See, for example, Tab 422. This is a simple accessor method. There are only so many ways to retrieve a value from a structure...

Of course it looks rearranged. It's a header file. Some of the ELF constants come straight from the ELF spec. The #ifndef stuff is bog standard code, there are a finite number of ways of writing that and the one presented happens to be the most common. The #include is another "duh" - of course you have to #include the right header, that doesn't mean it's copied. The header file is presumably deliberately compatible with the original, hence the function definitions are prototype-compatible (while being considerably different in style).

There is nothing indicative of code copying in that PDF. The Linux header is just about as different as it can be while remaining source-compatible, as it should be.

Commenting further on that, here is a link to the System V Reference Specs, one of which is the ELF Tool Interface Standard Specification. This contains not only several constants, structures, and function names, but suggests function prototypes and programming style.

Like you said, any author wishing to build an ELF-capable system would almost have to have that exact same code. There are only so many ways to build an enum or struct following the exact TIS specifications, and there is no virtue in paraphrasing C code.

Much of the rest of the code is libc and POSIX prototypes (and more headers), all of which are covered in the System V ABI specification. Anybody wishing to build a POSIX-compatible system would have to define those prototypes.

Several of the function implementations with similarities are very basic functions. Most of the similarities are in the constant names (rather than the specific implementation of those simple functions), and the constant names are defined by ... the TIS spec. The remainder is a no-brainer. See, for example, Tab 422. This is a simple accessor method. There are only so many ways to retrieve a value from a structure...

LSB dictates RPM packages, or at least highly encourages their usage.

I have posted a comment on the FHS bugzilla on this. There was already a suggestion for using .etc.
http://bugs.freestandards.org/show_bug.cgi?id=75

Personally I couldn't care less about the name, but this should be adopted.

They can be found at http://accessibility.freestandards.org/a11yspecs/ia2/api/. From a quick look, it appears that the interfaces are under the GPL. Would this mean that any implementation that used these interfaces would have to be GPL? Surely you can't implement an interface without including the source code for the interface specification. For me, this would almost mean that any interface should be published under an MIT or BSD license, even if your want your implementation to be under a GPL. Then you would maximize sharing of the interface, while protecting your code that actually implements the interfaces. Am I missing something here?

According to this mailing list post, he's a marketing guy. Since when do we listen to marketing guys on slashdot now? Did I miss the memo or what?

It's true that in many contexts strcat is not very efficient, but the GNU extension stpcpy addresses this problem. Indeed, the example in the manual entry is of using stpcpy to implement a more efficient strcat(). Moreover, there is absolutely no need to use assembly language either to understand this or to write it. Indeed, I wrote my own version of stpcpy (actually, the wide character version wcpcpy) in just a minute recently for portability to non-GNU environments, in C.

I agree that some knowledge of assembly language is useful for understanding what is going on at the lowest levels, but this is not an example of the utility of knowledge of assembly language.

the point of having different GNOME and KDE interfaces, was so that you could have different interfaces. Now someone wants to unite them, so why even bother having one over the other?

Looks like you got caught up in the overloaded use of the word "interface". You're thinking in terms of the GUI, but this is about application interfaces. KDE and GNOME will still look as different as always, but now applications can use a single interface to install menu items for either KDE or GNOME. This is good. It's one step on the long road to wooing commercial ISVs onto Linux.

The only open question is whether or not this will work in the long run. For example, at one point the LSB was supposed to standardize filesystem locations across distros so that installers wouldn't have to know if your distro uses "/etc/http.conf" or "/etc/apache/httpd.conf" (LSB appears to have dropped that pipe dream). If distros and developers don't pick up and use these new interfaces, it doesn't much matter that they exist.

A list of Linux Standard Base compliant distros is available on their site http://www.freestandards.org/en/Products Asianux 2.0 (which Red Flag is based on) is listed as compliant so it would be reasonable to assume compliance. I've never used Red Flag so YMMV.

From what I understand almost all distros now have their startup commands in /etc/init.d. /etc/init.d usually ends up being a symlink to whatever the actual rc.d directory is.

According to LSB: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Co re-generic/LSB-Core-generic/etc.html

The only thing which is different is the actual service name. Take Apache for example, on redhat/fedora its /etc/init.d/httpd, on Debian its /etc/init.d/apache{1,2} etc.

Isn't this this similar to what the LSB distribution certification http://www.freestandards.org/docs/FSG_Imperative_W P_Public.pdf is trying to ensure? That If someone is using LSB-certified distributions, that it is guaranteed to have certain components that are needed for developers trying to reach a broad linux demographic? And as distributions adopt futher revisions of LSB, things can only get better? The biggest hurdle I see is the continuing battle over gui-toolkits. But even then, there are projects trying to make a way for developers to make gui's that will use the toolkit of the user's desktop environment, the Portland Project, I believe.

If this is the most authoritative source Microsoft can assemble to substantiate their claims Open Source is complex

No, this and this are the sites that say that. The OSS community doesn't need MS to point out flaws, when we can do it ourselves. The correct attitude to all this, of course, is to acknowledge valid points and fix them (because if you don't, well, that way lies Marketing)

Simple, have standards that people/distributions can *choose* to follow.
Projects such as Linux Standard
Base (and others, list / talk about them if you know of them) allows
distributions to have a common point and common environment.

I think GNU/Linux will learn from the fragmentation of Unix. Part of the
reason why Unix didn't develop a standard was that each closed version was
competing against eachother for customers. With Linux there is no to-the-death
competition since the work is shared and co-operative.

The author made some good points, but I'm confused why he didn't mention the Linux Standards Base. Aren't these issues exactly what the LSB is supposed to address?

Correct me if I'm wrong, but I don't think closed source software is really the main issue for most Linux users. New software is what we lack. Many people are using NVidia video cards with a closed source driver and playing Doom 3 which is also closed source. For example, I want Photoshop and Dreamweaver and Nero (the real one) to run natively in Linux.

-- Ghodmode

"there does not appear to be a clear, simple to follow outline cooperative for companies to design for the open source operating system." Is this no what the Linux Standard Base (LSB) addreses?

Have you tried here?

:wq

Oh, the LSB's influence is very minor thing, but as with life, its the little things that count most.

look at http://freestandards.org/docs/lsbbook/install-app. html and you have something that is no effort on the developer or installer, but will make a hugely beneficial difference to the sysadmin.

A GUI standard would be good too - but I doubt its time is here for Linux yet. Reminds me of the Windows Usability Guidelines that used to exist, it made Windows a much more consistent interface and was a Bible for ages, until people (ie some MS devs - mostly Office) decided that eye candy and stupidly different GUIs were what was going to sell more copies. Things have started to fall apart in Windows since then, IMHO.

Depending on what open source license the standard's implementation is released with, of course.
The most common license, (L)GPL pretty much blocks most other licenses.

I'm not sure I understand what you mean. I've never seen an open standard (documentation) released under a license designed for code. The free standards group (LSB & other free standards) release their licenses under the GNU free documentation license.

I'm not exactly an IP lawyer, but I don't see any obstacle to writing code to conform to a FDL specifcation under any license you choose.

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?

There's also another concept which helps free software to be more virus resistant : it's its diversity.

There are dozen of different distros out there, each using a different kernel, built using a different version of gcc, software linked against different libraries. Compare this to windows. The 12 different flavors of Vista that are announced are basically exactly the same OS with different functions crippled depending on the flavor. But same fucking kernel compiled with the same stupid Visual studio, linking against the same libraries.

Same reasoning could be made for architecture, Linux is does *NOT* equate to "Intel x86" (whatever do think the commmercial developpers who ship binary-only driver). You can get it on PPC, Spac, ARM, whatever else.
With some historical isolated exceptions (Alpha, Itanium), windows runs only on x86 and derivated (AMD64) architectures.

Now take in account all the customisation that end users may have made (running custom-build kernels with different optimization is very common amongst advanced linux users) which is plain impossible (except for a few gov or mil organization, nobody has access to Windows kernels).

All this leads to one conclusion : it's damn hard to have a single binary that can be run accros all possible linux installations. That's something commercial developper have to put up with. And they usually comme up with a collection of multiple packages that can run on a very specific subset of distributions (see this soft I've recently downloaded as an exemple).

For a viruses it's even harder, because the viruses must be small enough to fit inside the e-mail or the exploit's payload. So there's no option to do huge binaries with every library dependency statically compiled in (like OpenOffice.org does) or using multi-architecture binaries (like Fat-binaries on Mac).

Viruses also highly depend on specific version of kernels and libraries to be able to exploit bugs, escalate access rights, etc. There are some efforts to provide a standarised subset of libraries, etc.. (see LSB) so binary applications could be easier to make. But be sure you'll never see such an idiocy as a LSB certified, standarized exploitable kernel bug !

So, if a virus is designed in the traditionnal Windows way, it'll only be able to annoy a very small subset of all users, and only for a short period of time (version update are more frequent in Linux world - new distro every few months - than in Windows world - new OS every few year).
So yes, you're right *in theory* : there could be users dumb enough to enter their root password just to get a nice KDE applet showing the weather. But most of the time the virus it self won't be able to make it to the "asking-root-password" stage and are very likely to crash before, due to missing libraries or incompatible ABI.

The very single thing that pisses of first time Windows-to-Linux switchers - that they can't just download random SETUP.EXE files and install every crapware by clicking on it - is what protects linux users from being vulnerable to spywares and virus.

Then how are software distributed on Linux, is it possible for a virus to take this way ?
On linux there's a few different way to get new software for you system.
- For those who want bleeding edge software : getting software distributed as source and custom-compiling them. It's not trivial (see the "couldn't play Quake on Linux" trolls lying around slashdot). And in my humble opinion, the kind of idiots that just clic "yes" and give root password everywhere won't be able to do it. On the other hand, you pointed to these viruses in EXE-packed-in-password-protected-ZIP. (At least, if there's some "here's a cool source code, and those are the instruction to get it running" worm, it'll show the "quake-on-linux" trolls proof that even compiling isn't that much complicated). Very unlikely.

- The standart way most user, even

Think about the children^H^H^H^H^H^H^H^H LSB!

(They use RPM: http://freestandards.org/en/LSB)

I think everyone sees the "crap" software out there because it's all "crap" to a certain extent.

Usability is definitely not a problem specific to OSS, but it's something that OSS hasn't helped. The author's post uses Windows as the standard of usability that the Linux desktop needs to match. From the work I see in both GNOME and KDE, it's clear that Windows (with a bit of Mac OS X) is also the standard for which the OSS community is aiming. The problem with this is that the Windows/Desktop metaphor probably outlived its usefulness a long time ago. A quick read of Jef Raskin's book The Humane Interface may convince you of that.

If OSS is going to be successful with normal end-users, it needs to aim higher. Let's not ape Windows and Mac, let's come up with something genuinely new and powerful. Let's now spend our time on building yet another window manager, yet another media player, yet another word processor or yet more eye-candy (XGL anyone?). The academic community has been doing lots of exciting research into usability for a long time (check out the University of Maryland's HCIL). We need to stop pouring effort into commodity software and outmoded interaction metaphors and figure out how to use the power of the OSS development model to bring these ideas from academia into the mainstream.

I think that efforts like the Linux Standard Base are a step in the right direction, but a part of me wants to throw out everything but the lowest-level graphics routines and start fresh, and with the amount of vested interests in an effort like the LSB, that's going to be impossible.

We don't necessarily need MORE linux distributions, we need BETTER linux distributions. We also need to get the ones that are out there a little more unified. Things like the Linux Standard Base http://www.freestandards.org/en/LSB while although not the end-all solution is a step in the right direction. We don't need boocoos of distros, choice is great, but something like 5-10 GREAT distros would provide good competition yet also unify some of the effort against who you said is the number 1 problem (microsoft).

Off topic a little I know, sorry. Just thought it needed to be said.

The dependency problem goes away because a single package "depend" (lsb >= 3.1) implies the entire set of functionality required by the LSB must be present on the system. See here:

http://refspecs.freestandards.org/LSB_3.1.0/LSB-De sktop-generic/LSB-Desktop-generic/desktoppkg.html

Every single distro does its own thing and there is no standardization whatsoever.

I humblely disagree.

Filesystem Hierarchy Standard (FHS)

The filesystem standard has been designed to be used by Unix distribution developers, package developers, and system implementors. However, it is primarily intended to be a reference and is not a tutorial on how to manage a Unix filesystem or directory hierarchy.

Gentoo FHS
RedHat FHS
Suse FHS&LSB

And for binary distros there is Linux Standard Base (LSB)

The LSB specification is made up of several components, known as modules. The base specification consists the of Core, Graphics and CXX (C++) modules. The specification is further extended with the Desktop set. Each module might be subdivided into a common document plus architecture-specific documents (in some cases the subdivision is not needed). A complete binary standard for a particular processor architecture consists of the set of necessary common documents plus the matching set of architecture-specific documents.

Latest LSB Spec 3.1.0

Binary compatability not an issue? I'd have to take exception to that. For instance, while I'm not a huge fan of the LSB because of test quality, and some other issues, please note that binary compatability is supposed to be maintained across point releases. Breaking it is one of the defining aspects of a major release.

From
http://www.linuxbase.org/LSBWiki/ReleaseNotes3

"The LSB project team is proud to announce LSB Version 3.0. The specification is available for download at [WWW] http://refspecs.freestandards.org/lsb.shtml. As this is a major release, indicated by a change in the first component of the version number, there is no guarantee of binary compatibility with previous versions. The set of interfaces, the details and symbol versions, and layout of certain data structures may have changed between this release and the previous one. Thus, applications conforming to previous versions of the LSB will require recompilation and/or relinking (see also Compabitility section below)."

Clearly, binary compatability can affect developers, packagers, system admins, etc.

How can you say "Bye bye KDE" when Trolltech is part of the FSG?

From an LSB whitepaper: "without a widely supported binary standard for linux, a single vendor, de facto standard will emerge, effectively removing choice and locking end users in". I feel that as long as linux competes with itself it won't effectively compete with other commercial OS (at least for mass adoption on the desktop). Also, I'd be more interested in learing compiling stuff if the differences between distros didn't create such a moving target for the student. I'm keen to learn, but make it too hard and I'll go off and learn something different.

Nice, I get modded troll for pointing out the obvious. What the hell are you mods smoking? Here's a few links to projects just like this that blew hot air and wasted bandwidth by talking and not doing, just like this one.
http://freedesktop.org/ http://www.freestandards.org/news/press.php?id=215 &view=full/ http://www.desktoplinuxconsortium.org/

I don't see how a standard that uses RPM as the mandatory package format will ever gain enough consensus to be successful.

What kind of a standard is this anyway? For example:

Applications are also encouraged to uninstall cleanly.

Um, that's great. Where's the definition of "cleanly"? Where's the rationale? Where's the implementation notes? This thing reads like a few people got together and jotted down a few notes on what they'd like to see. This ain't a specification. Sure, they go into great detail about the format of the RPM file - but that's already an established format that they don't need to explain.

I say FUD. HP is doing plenty to support linux, as well as development. They sponsor:

- Gentoo ,GNOME,
- Linux International
- Free Standards Group (the LSB is a workgroup of these guys)
- the OSS Institute
- OSDL, Kernel.org
- etc.

HP has many people hacking the linux kernel. Of course, IBM is doing great stuff as well, but you sketched the situation in a much too black & white way.

Sure, OpenOffice is great, but commercial enterprises will stick with commercial solutions for which there is support.

I don't exactly get what you mean by support. My impression from the people and businesses I know personally is that Microsoft Office format is a big success not because of "support", but because there's a wealth of products built around it by third parties.
These 3rd-party products are crucial for the enterprise, stuff like Eletronic Content Management, being able to create document workflow and revision systems, and groupware. All this stuff integrates seamlessly with the Windows desktop and the Windows office applications. In any enterprise with a huge amount of paper and workflow, document management systems are a necessity. This is point OpenOffice proponents frequently forget: office applications are not about just the single desktop user but they are also about integrating seamlessly in an eco-system of content management software provided by theird-parties and accessing legacy documents. For instance, in my country, Brazil, legislation demmands that certain financial documents be stored for a period that outruns any document format you might have seen. This means people have to migrate very old sofware document records.
This is an area ISV working on open-source platforms could explore, an unexplored niche market. AFAIK, not even COLD solutions exists and COLD goes way back decades (ever since computers started processing bills.) And there are no equivalents of proprietary software in the open-source market (this shows you that open source developers are sometimes out of touch with their would-be customer base). People are developing groupware, but there are no ECM (Enterprise Content Management) solutions. Groupware, ERM, and ECM are the bulk of enterprise software.
If only the open-source community would take something like OpenOffice, or further develop AbiWord (which has nice plug-in functionalities), and integrate these with Mono, you would have made a serious dent in the Windows dominance. I mean, who wouldn't want to avoid expensive per-seat Microsoft licenses, plus per-seat ECM licenses? And software houses that provide ECM solution (e.g., the market leader OnBase) work with year-round support and customization, and we know this is a way of doing business that is viable for open-source (of course, they have per-seat licenses).
BTW, I really mean Mono, and not Java. Java is not an alternative on the long term, not only because of the Java's proprietary nature, but because Mono is gearing itself towards Windows-*Nix interoperability, to the point where software build with Windows.Forms will work on Mono. Additionally, having to depend on Sun's finances is a a suicidal investment of resources.
But open-source has major hurdles: it nees to standardize on OpenGroup and LSB That is to say, the Free Standards Group has to advanced by libre *Nix distros and vendors, so that software developers have an easier time with all the distros. De Icaza wrote something about this in this essay. Linux distros need to be reliable in terms of time frame for releases (which the commercial ones are), too.
My feeling is that Microsoft has foreseen a trend going against its closed-source format (OASIS, the Massachusetts imbroglio) and anticipated any possible open-source incursion in the field of content management. If these formats are truly opened, they've raised the bar for the arguments of any future switching to FOSS platforms+OO.org solutions (because, right now, as I've argued, there are no FOSS replacements for content management for the enterprise AFAIK, and there's a huge amo

Because RPM already won. It is the Linux standard. Period. Until that changes, arguing over package formats is simply political/religious and accomplishes nothing.

Linux Standard Base

Umm... I don't think the "Linux Standards Base" is the hundredth project of its type you'd have seen since the inception of Linux. Whereas there have perhaps been other attempts at standardization by small groups of individuals, the LSB has been (more or less) the first major attempt amongst the distros and major vendors to come up with binary standards.

Check out the membership of the Free Standards Group (which governs the LSB) here. Note that it includes essentially all the significant commercial Linux distros, as well as the big corporate supporters (IBM, HP, Sun). (Although I'm sure many on Slashdot scoff at the notion of Sun being associated with truly "free" standards, nonetheless they are a big corp with ties to Linux and OSS.)

Furthermore, you talk about the LSB as though it is a new project. It has actually been around for a number of years, and has been mentioned on Slashdot many times over the years. (See e.g. here, here, here, and here.) Version 1.0 started in 2000. I believe 1.1 came out in 2001, followed by 1.2 and 1.3 in 2002. Version 2.0 came out in September of this year (with 2.0.1 released in late October). Currently, there is a 2.1 release candidate available.

"Building Applications with the Linux Standard Base" has been (apparently) also published under the GNU Free Documentation License. Here is the Online version.

The group behind this is legit. They are a bunch of linux vendors and consulting firms designing standards for binary compatability across linux distributions. So in other words: a) This standard has nothing to do with any sort of open source software b) It is deliberately specific to Linux and not designed to be part of the open systems / posix.

I would have liked to hear more details in this interview on how the LSB project is going and the other activities going on at the Free Standards organization since Jon is on their Board of Directors.

Debian is listed as a "Silver Member" on their group member page.

...it is part of the Linux Standard Base and other standards of the Free Standards Group. The problem is that the standards have not been widely adopted enough. Perhaps that will change over time, particularly once LSB 2.0 is released in its final form. Presently, a few distros (Mandrake for one) are already LSB compliant and should properly install LSB-compliant RPMs regardless of the source. The drawback is that this compatibility is generally "bolted on" by installing--you guessed it--a distro-specific RPM.

RPM has been selected as the standard packaging format for LSB, and as the standard has evolved cross-distribution issues have been addressed. This had always included advocating adherance to the Filesystem Hiearchy Standard (FHS) and now includes things such as a universal package naming standard and standard implementation of printing systems. Those are among the most notorious of cross-distro difficulties we have to contend with right now.

Whatever you think of the RPM format, it serves its purpose quite well, and it is a standard. If Fedora and Mandrake and others start to work together on interoperable solutions to managing RPMs in combination with increasing support for LSB then it would mean a huge advancement in the effort to bring about widespread Linux adoption.

First, I admire Daring Fireball in all of it's pedantic glory. Maybe he is just trolling for April 1st.

OSS software is not always easy to use - there are plenty of OSS developers and users who understand this constant plight. This article doesn't seem to recognize that. Gruber always paints with a broad brush and it is hard not to be offended by what he is saying and implying in this article.

Good user interfaces result from long, hard work, by talented developers and designers.

Check this Gruber - Gnome, KDE, Easy Software (CUPS), Freedesktop, Mozilla, Ximian, Trolltech, Activestate, IBM, Sun, Redhat, SuSE, Novell, Mandrake, Debian, Open Office, Apple, and on and on, ALL have talented developers and designers on board. Some are paid, many are not. All of them write, package, repackage, extend, design, evolve, sell services around or just use OSS software. Even if the print setup on Alan Cox computer was too difficult for anyone, it was written by a talented developer and probably looked over by a talented designer somewhere later. It just didn't work this time around. So we move on. We re-examine it. I promise you we didn't need Alan Cox to tell us it needs improvement. Alan Cox is not OSS. Alan Cox problems do not reflect everyone's problems. Certainly not my co-worker who's CUPS install does autodiscover. It even connected to my amazing Apple Powerbook's shared printers running off... CUPS.

There are plenty of failures in OSS usablity. They are being fixed fast (release). The fast (release) is complimented by the fast (performance) of Linux. I use OS X everyday, don't tell me it is more responsive than Linux and it's OSS on equal hardware. You don't have enough proof to refute mine, I don't have enough proof to disprove yours. OSS is also more than just cheap software, it's cheap software that runs on cheap hardware (more on this below). And it will be good. I think it's good right now. Novell and IBM thinks it's so good right now they are rolling it out, company wide.

Talented programmers who work long full-time hours crafting software need to be paid. That means selling software. Remember the old open source magic formula - that one could make money giving away software by selling services and support? That hasn't happened - in terms of producing well-designed end user software - and it's no wonder why....

For example, look at how much Mac OS X has improved in the last three years alone. Even if desktop Linux is improving - and I do think it is - it's improving at a much slower pace than Mac OS X....

Mac OS X printing implementation was built on much of the same software as Alan Cox Fedora install. This is the panacea of the OSS business model - quality free (libre) disparate software, glued together by intelligent programmers. Further I don't understand Gruber's point of view - Apple is making money off OSS and the developers are getting paid. The support and services might be in the form of support software which may not be what the kind of support he was thinking of... but it's still services and support.

This isn't to say desktop Linux isn't growing in use. It is, and will continue to. But it's growing at the bottom end of the market - cheap $400 computers from Wal-Mart. That's a market where software usability is not a key feature.

I'm sorry but Gruber is wrong. It is a key feature in that market - according to Linux developers. Maybe not Apple developers and maybe not Microsoft developers. However, to many, many, many OSS developers, usability importance doesn't scale with price. That's a disgusting, exclusive statement by Gruber.

Meanwhile, while linux tries to infilitrate the government, the DoD is tyrying to infilitrate the linux. The DoD Defense Information Infrastructure Common Operating Environment is/was an initiative to to define a common software stack to run across multiple platforms that includes software installation, user management, and printing tools. When you talked about putting Linux on the DoD desktop, that used to mean having a DII COE stack for linux. This year DISA released a beta Linux COE kernel and then released the source code for it which can get from anonymous CVS. DISA has paired up with the OpenGroup to define a testable/brandable definition of COE. And there is a project to develop a platform independent COE stack from scratch.

Relevent URLs:

http://www.disa.mil/coe/kpc/linuxpc.html

http://gforge.freestandards.org/projects/qp-coe

http://www.opengroup.org/openbrand/coe

http://opencoe.sourceforge.net

Well, there is. It's just not very useful, because it says you can only have one dependancy. D'oh.

Wishful thinking I guess.

Perhaps. But you're not the only one thinking wishfully about this. The main packaging dudes from Redhat, Debian and yes, even Gentoo, are talking about it.

The list has gone a bit dead lately. Alain seems to have disappeared :( Hopefully it'll pick up again soon. It'd be nice to have standards for packaging metadata (which solves a lot of our current woes with packaging).

In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes. Why can't someone make something like this for Linux?

A few reasons. Firstly, these programs are tremendously complex under the hood. Almost all generic ones (even light ones like NSIS) include their own scripting language. InstallShield 6 and up has used DCOM to provide remote procedure calls between the install script and the engine (ikernel.exe if you've ever wondered what that is). They do a lot of messing around under the hood in order to make things just work.

Even then, they are too primitive for Linux. For instance, they have only basic concepts of dependancies. The lack of proper dependancy management almost brought Windows to its knees in the mid-nineties. Simply packaging every dependancy inside one self-extracting archive is simply not possible on Linux in any scalable fashion, so we have to build dependancy resolvers like apt. Windows installers tend to be GUI only. And so on.

Now, systems like apt are pretty cool. When they work, they work really well. The problem is, that they tend to be built by distro projects, and then they are relatively tied to that distro. Apt as used on Debian for instance, is not the same as apt4rpm. URPMI is Mandrake, and emerge is basically tied to Gentoo, though I'm sure it could be generalised.

So, the real solution is not to build Windows style setup.exe files. The real solution is to make something like apt, but that can be easily used by everybody, so you rarely if ever come across software that doesn't use it.

There are two approaches to solving that problem. We're trying both at once. The first is to invent a new system, independant of the existing ones. See my sig. The second is to try and standardise key interfaces in a standards body, so that apt/urpmi/emerge and others can interoperate, and so you can plug distro-neutral packages into that framework. See here. Note - most of the activity so far related to that group has been off-list, hopefully there will be action starting in a few days.

Debian 3.0 did pretty well compared to SuSE.

Link shamelessly stolen from this post.

This link tells you some LSB test suite information.

>This is surely due to the various distributions >not conforming to the LSB and FHS, rather than the >shortcomings of the package management system? >Debian is far more standards-complient than >RedHat, and Slackware is even better.

Sorry, but Red Hat's lack of complaince (or lack of willingness to comply) with the LSB is a myth.
These aren't the official results, but preliminary test results at freestandards.org show Red Hat as passing more tests than Debian, SuSE, and Caldera.

Among some of the issues that Debian were that their init scripts didn't provide a status command, and that there was no distinction in runlevels 2-5. I haven't kept up with development too closely, but my Debian installation, which has been apt-get upgraded fairly recently still has these issues.

As for Slack, last word from Patrick Volkerding that I know of is that he's taking a "wait and see" approach; i.e. he's not even bothering to strive for LSB complaince until he's convinced that compatibility is improved between compliant distributions, although to his benefit he said "I'm sure this is a step in the right direction."

I haven't used 8.1 at all, but Slackware probably has the most work cut out for it if they decide to try to move towards LSB compliance - their init levels are non-standard, their init scripts are completely non-standard (kind of a weird hybrid BSD/SysV approach), they fail a good potion of the FHS tests, etc, etc.

In other words, nit picking aside, Red Hat and Deibain are pretty much on par as far as comformance go, and Slackware is way off.

Matt

Since even BSD is moving to RPM and RPM is the mandated package system for Linux Standard Base, this would be a good project for Debian to test the waters of current technology. It would allow Debian to transition to RPM on this hybrid testbed, working the kinks out in the process. This would allow the work to go forth without disturbing the current main Debian branch. Then when the time was right, the overall switch could be made smoothly to RPM. Now's the time to act!

We are working on one. Please check out http://www.freestandards.org/printing

-ben