Building Applications with the Linux Standard Base

← Back to Stories (view on slashdot.org)

Building Applications with the Linux Standard Base

Posted by timothy on Monday December 20, 2004 @09:00AM from the little-bricks dept.

r3lody (Ray Lodato) writes "Just because Linux is under the GPL, some people believe that it's pretty standardized. Actually, each distro has its own little additions and, consequently, quirks. Writing an application to work reliably under all variations is not a slam-dunk. The Linux Standard Base Specification seeks to provide the common ground that all Linux apps should adhere to, and therefore make reasonably sure that they will work as advertised. Building Applications with the Linux Standard Base is a reference manual for application developers to make sure their programs will work across the Linux map." Read on for the rest of Lodato's review. Building Applications with the Linux Standard Base author Core Members of the Linux Standard Base Team pages 246 publisher Pearson plc publishing as IBM Press rating 8 reviewer Ray Lodato (rlodato AT yahoo DOT com) ISBN 0131456954 summary Very dry reading, but a lot of useful information packed into a slim 246 pages.

I've been involved with IBM products and documentation since the late '70s, and their documentation has traditionally come in two flavors: user's guides, and reference manuals. The former are meant to be read cover-to-cover (more or less), and the latter are meant to be looked at for specific bits of information. This book falls more to the reference manual side of the spectrum. Consequently, reading it cover-to-cover was a little dry, but the information needed to get an application certified with the Linux Standard Base (LSB) was clearly laid out.

Building Applications with the Linux Standard Base (published by IBM Press and available on your favorite bookstore sites) is laid out in five large parts: Introduction, Developing LSB Applications, Certifying for the LSB, Contributing to the LSB Project, and Using LSB Resources. Except for the first part (Introduction), the book gives specific examples, and many, many references to the opengroup.org website's sections on the LSB.

It becomes obvious as you go through the book that the Linux Standard Base is still evolving. The authors (13 core members of the LSB team) frequently allude to how the project can (and should) be extended to increase its scope and sophistication. Two chapters (Adding New Interfaces..., and Adding New Architectures...) cover (albeit skimpily) what's needed to update the specification.

Backing up for a moment, Part II (Developing LSB Applications) describes in detail (with examples) the Dos and Don'ts of coding practices. It then explains carefully how an application should be packaged for distribution (RPM), and finally wraps up with a section on porting Solaris apps to the LSB. In each chapter, step-by-step instructions are given when appropriate. Differences in filesystem hierarchy, signal handling, and program options are all laid out to help you through.

Part III goes over the LSB Certification process. Both runtime environments (distros) and applications are covered. Again, the book lays out the process in a step-by-step approach.

The last part in the book talks about the various resources available: the written spec, the test suites, and various usage guides. The chapter on using the LSB test suites shows how much thought went into making sure a successful test ensures a certifiable (in a good way) application.

All in all, Building Applications with the Linux Standard Base, has what you need if you're developing a commercial-grade Linux distribution or application. Once your product has passed the testing described inside, you can be confident that it will work on almost anything Linux. Very dry reading, but a lot of useful information packed into a slim 246 pages. I'd give it a 7 for writing style, but a 9 for content: total=8/10.

You can purchase Building Applications with the Linux Standard Base from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

282 comments

Standards by Anonymous Coward · 2004-12-20 09:02 · Score: 4, Funny

Ah, yes, standards. So many good ones to choose from.
1. Re:Standards by Smilin · 2004-12-20 09:05 · Score: 4, Funny
  
  One of several standard responses?
2. Re:Standards by baquiano · 2004-12-20 10:53 · Score: 2, Informative
  
  Actually, a variation on a standard authoritative quote:
  
  The nice thing about standards is that there are so many of them to choose from.
  -- Andrew S. Tanenbaum
  
  --
  You're bound to be unhappy if you optimize everything. --Donald Knuth
3. Re:Standards by Anonymous Coward · 2004-12-20 11:03 · Score: 0
  
  Ok, I remastered Knoppix. But, found that a lot of things that I wanted did not work, so I changed some of the scripts, some quite a bit. That's the thing with Linux, everyone has their own recipe. If I had to adhere to some standard, then I might not get what I want, and I'd be going at it again!
4. Re:Standards by owlstead · 2004-12-20 11:47 · Score: 1, Redundant
  
  No, that is:
  
  The nice thing about standards is that there are so many of them to choose from.
  
  Andrew S. Tanenbaum
5. Re:Standards by andywebz · 2004-12-20 18:37 · Score: 1
  
  Say it with me. You must be...
  
  --
  Saying "I'll probably get modded down for this", is a magnet for my -1 mod token. I hate to disappoint.
Actually... by drgroove · 2004-12-20 09:03 · Score: 4, Funny

... writing apps that work across distros is really easy - it's called Java. :)
1. Re:Actually... by tetranitrate · 2004-12-20 09:08 · Score: 1
  
  but its pronounced pah-sux.
2. Re:Actually... by deadlinegrunt · 2004-12-20 09:09 · Score: 1
  
  Nice
  
  --
  BSD is designed. Linux is grown. C++ libs
3. Re:Actually... by Anonymous Coward · 2004-12-20 09:12 · Score: 0
  
  Working across distros is one thing...is there some sort of speed requirement? Even java has its "forks" in terms of its components, but I guess as long as you stick with swing, you'll be ok.
  
  Then there's the idea of going web-based on everything. Nothing quite like a LAMP solution to all your app needs. :) Want to move across distros and OSes? Standardize on firefox as the browser.
4. Re:Actually... by 1_interest_1 · 2004-12-20 09:12 · Score: 1
  
  Of course what happens when you have a various dependencies and they are not packaged with the application?
  
  What 'standard' directory do you propose that those are placed in?
  
  Is that 'standard' the same for all Linux flavors?
5. Re:Actually... by powerlinekid · 2004-12-20 09:13 · Score: 1
  
  Good point...
  
  Now for me to write my drgroove loves java flame counter application that can be deployed across all distros.
  
  --
  
  can't sleep slashdot will eat me
6. Re:Actually... by MrRuslan · 2004-12-20 09:14 · Score: 3, Interesting
  
  What about Mono www.mono-project.com
7. Re:Actually... by Anonymous Coward · 2004-12-20 09:15 · Score: 0
  
  ... writing apps that work across distros is really easy - it's called Java. :)
  
  ha!! write once...debug everywhere
8. Re:Actually... by Anonymous Coward · 2004-12-20 09:21 · Score: 0
  
  Complete and utter bullshit. There is no Java on Debian PPC.
9. Re:Actually... by Anonymous Coward · 2004-12-20 09:22 · Score: 0
  
  ... writing apps that work across distros is really easy - it's called Java. :)
  I thought it was called Common Lisp :-)
10. Re:Actually... by Anonymous Coward · 2004-12-20 09:22 · Score: 1, Insightful
  
  Please learn Java before commenting.
  
  Thank you.
11. Re:Actually... by JamesOfTheDesert · 2004-12-20 09:27 · Score: 1
  
  writing apps that work across distros is really easy - it's called Java. :)
  All major or popular distros have a common GPL'ed JVM and standard libraries? About time.
  
  --
  
  Java is the blue pill
  Choose the red pill
12. Re:Actually... by Anonymous Coward · 2004-12-20 09:27 · Score: 0
  
  Unfortunately, there is no commercial-grade JVM that complies with an ABI versioning standard like the LSB. This means that the Java bytecode interpreter cannot be distributed as part of an LSB package, and can't be guaranteed to "run anywhere."
13. Re:Actually... by cthrall · 2004-12-20 09:29 · Score: 4, Funny
  
  You misspelled "Python."
14. Re:Actually... by jo42 · 2004-12-20 09:35 · Score: 5, Informative
  
  ...and I've see Java apps (i.e.InstallAnywhere) that stopped running because a distro changed from XFree86 to X.Org. The (Sun) JVM was expecting a certain library to be there, it wasn't, and boom!! - it fall down...
  Mandatory "Java Sux!" - me
15. Re:Actually... by Anonymous Coward · 2004-12-20 09:38 · Score: 0
  
  Nor on PA RISK. Nor on a number of systems that I have seen entire codebases of C recompile for without problem.
  
  Sad that C is still the most portable language for non-gui stuff (read: networking and command line tools). Of course, you may have a hell of a time downloading all of the gnu tools to make your stuff work, but at least it runs natively after the compile.
  
  I just encountered another problem with Java: the fact that the language makes memory management problems go away (a la garbage collection) also makes it incredibly difficult to write an application that needs to process 4 gigs of data quickly. Even Lisp readily allows manual memory management when you need it. Oh, and memory maps in Java (since 1.4) have to be the worst implemented good idea they have ever had (no, that was swing).
  
  *sigh*
  
  I actually have some nice numeric stuff that I wrote in Java for distributed computing. After the initial startup, the JIT compiler does a good enough job that the slowdown (vs C++ compiled with the intel compiler) is an acceptible tradeoff thanks to the ease of writing a distributed computing platform. Unfortunately, as soon as the data starts getting big enough to be interesting, the whole thing throws out of memory errors. I put manual paging code in place, but the performance degraded to the point where I don't have access to enough computers to compensate for the slowdown.
16. Re:Actually... by MightyMartian · 2004-12-20 09:45 · Score: 1
  
  > ... writing apps that work across distros is really easy - it's called Java. :)
  
  And when Java finally can run with anywhere near the performance of a native binary, let me know. As it is right now, it's a neat language whose practical applications are limited by the performance penalties.
  
  And putting that aside, it still can have dependency issues, unless you plan on doing pure vanilla coding.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
17. Re:Actually... by WebCowboy · 2004-12-20 09:49 · Score: 4, Insightful
  
  Dunno about you but I don't find Java all that easy across distros either.
  
  Java apps aren't immune to dependency issues either and I'm not aware of any widespread effort on the scale of LSB to create a compatibility and deployment standard.
  
  Dont forget the biggest dependency of all--you need a JVM to run Java. That still needs to be packeaged like any other app. Let me know when there is a GPL-compatible JVM, available in an LSB-compliant package that will install and run cross-distro...and wont break if you use a different X server or non-standard hardware...then we'll talk.
  
  Yes, Java can be written once to run everywhere, but you often still have a few hurdles to clear during compilation and installation.
18. Re:Actually... by abigor · 2004-12-20 09:56 · Score: 2, Interesting
  
  Er, Java is the probably about the most deployed server app language on earth...do you actually know what you're talking about? Have you ever worked in a real situation with Java?
  
  "As it is right now, it's a neat language whose practical applications are limited by the performance penalties."
  
  Okay, so I've answered my own question: no. You may want to go and check out this company called IBM sometime.
  
  And yes, I'm talking client side also. The Visual Paradigm UML tool is a nice example of a great Java app. Runs on Linux too, of course.
  
  As an aside, there was a time on Slashdot when people actually knew what they were talking about when the subject of programming came up (back when I had a five digit uid). As the parent so clearly demonstrates, those days are gone.
19. Re:Actually... by theantix · 2004-12-20 10:03 · Score: 1
  
  Um, sorry, name the operating systems and distros that ship with a JVM?
  
  --
  501 Not Implemented
20. Re:Actually... by ScytheBlade1 · 2004-12-20 10:18 · Score: 5, Funny
  
  "Saying that Java is nice because it works on all OSes is like saying anal sex is nice because it works on all genders."
  
  --A friend of mine, aka Orlphar
21. Re:Actually... by Smurfboy · 2004-12-20 10:24 · Score: 1
  
  He meant Perl.
  
  k.h.
  
  --
  k.h.
22. Re:Actually... by Pseudonym · 2004-12-20 10:34 · Score: 3, Funny
  
  Oh, no no no. Java is "write once, run anywhere". Common Lisp, on the other hand, is "write anywhere, run once".
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
23. Re:Actually... by MightyMartian · 2004-12-20 10:39 · Score: 0, Redundant
  
  Have you actually run a Swing app on anything but high end equipment. The nice thing I like about Linux is that can make older hardware sing, but when you run Java apps, they just suck resources. Perhaps some limited types of apps can run at near native binary speeds, but you know what, don't try to sell me that Java GUI apps do, because they don't.
  
  When I want an app that I can run on a Windows box or a Linux box, I'm not looking for an app that runs slowly on both. At the moment, Java gui apps are neat toys.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
24. Re:Actually... by MonsoonDawn · 2004-12-20 10:57 · Score: 1
  
  No. He just means it requires a shit-load of coffee.
25. Re:Actually... by Alan+Cox · 2004-12-20 11:05 · Score: 1
  
  I can't even get a java app for my phone to run portably. It totals the java vm on some friends phones (they have to quit all java stuff to get back to sanity). Works great on Nokia.
  
  "Write once - debug everywhere" is horribly true.
26. Re:Actually... by Anonymous Coward · 2004-12-20 11:09 · Score: 0
  
  There is a port of the Quake2 Engine for Java. It's almost up to the speed of the C original.
  http://www.bytonic.de/html/benchmarks.html
  
  Java nowadays generally beats C++ though it is easy to write slow Java programs if you're too inexperienced with Java. C is generelly still faster but not always. There are some surprising places where Java even beats out C.
  
  The future is even more bright thanks to the absence of pointers. The compiler and VM always know where a reference points to and what is to be found there. More optimizations are possible.
  
  Swing may not be the best, it has some huge startup time, but if that's unsuitable, what's stopping you from using SWT that accesses native widgets?
  
  Anyone citing performance problems and Java hasn't seen current VMs perform in server mode.
  
  And who cares about that remaining factor less than 3 difference to C when it is safe, has no buffer overflow and PCs double their speed all N months anyway.
27. Re:Actually... by grumbel · 2004-12-20 11:32 · Score: 1
  
  # java
  -bash: java: command not found
  
  As long as their isn't a finished and useable Open Source implementation Java stays a major pain to use on an Open Source OS. Sure, Suns marketing speach might make you believe its portable, but I never had so much throuble with getting software to run than I had with java programms.
28. Re:Actually... by Anonymous Coward · 2004-12-20 11:47 · Score: 0
  
  So Java is great for other reasons?
  
  I'm confused.
  
  --TV
29. Re:Actually... by Tribbin · 2004-12-20 11:55 · Score: 3, Insightful
  
  I'd like to state that in this case a layer lower than the virtual machine is not working.
  
  If the virtual machine is not working properly, it's like running an x86 executable on a sparc.
  
  --
  If you mod this up, your slashdot background will turn into a beautiful sunset!
30. Re:Actually... by owlstead · 2004-12-20 11:55 · Score: 1
  
  Neh, compilation is pretty fine. You just compile it on the developers machine, and if the PATH and CLASSPATH variables are fine, then the Java application runs fine. I admit that getting those paths right can be sometimes hazardous. Even though Java 1.5 has versioning support and more configuration options, they are not quite there yet.
  
  For your GUI: use SWT to use a GTK toolkit underneath. That will probably solve your X problems, and lets your Application have a native look and feel (which is a must IMHO). Obviously you will have to include SWT in your distribution. But hey, if you develop for windows not every library is pre-installed as well.
31. Re:Actually... by Chandon+Seldon · 2004-12-20 12:12 · Score: 1
  
  Anal sex doesn't cover the Female - Female case natively. This can be worked around with conversion tools, but it's not as convienent as a case-specific protocal.
  
  In conclusion, your statement ("Saying that Java is nice because it works on all OSes is like saying anal sex is nice because it works on all genders.") seems highly accurate.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
32. Re:Actually... by Anonymous Coward · 2004-12-20 12:44 · Score: 0
  
  Just because openGL is fast doesn't make java fast. If I had an OpenGL library for bash, I could port the Quake2 engine to bash. It wouldn't mean that bash was fast, just that an OpenGL wrapper existed.
  
  Oh, and please write a java app that can multiply two 2000*2000 double matrices. Oh, that's right, you can't because you run out of memory. And java has no way to deal with that problem. C and C++ do.
  
  The only places Java beats out C are in string intensive applications that check the size of the string frequently. There exist sized string libraries for C. Just because the default is null terminated doesn't mean that is all that exists.
  
  C++ compiled by intel's compiler will generally beat any Java VM. This becomes more true if the C++ code uses a decent replacement for the STL, of which I haven't found a good implementation of yet (although, sadly, microsoft's is pretty close).
33. Re:Actually... by JamieF · 2004-12-20 12:51 · Score: 2, Insightful
  
  >At the moment, Java gui apps are neat toys.
  
  I guess IBM, Oracle, SAP, Intel, Novell, Red Hat, Wind River, and others desperately need you as a consultant to tell them that they should stop using Eclipse and rewrite their developer tools in C. Why don't you email them and suggest that?
  
  GNOME is pretty slow too. What's that written in again?
34. Re:Actually... by xouumalperxe · 2004-12-20 13:32 · Score: 1
  
  Slackware, v9.1 and v10.0 both package java and javac. Since those are the only two versions I've used, I can't assure you of the rest. I think gentoo and debian probably also "package" a JVM, but do those even count? :)
35. Re:Actually... by naden · 2004-12-20 15:41 · Score: 1
  
  Dont forget the biggest dependency of all--you need a JVM to run Java. That still needs to be packeaged like any other app.
  
  It needs to be packaged ONCE, and then it will be fine for all future Java applications.
  
  Let me know when there is a GPL-compatible JVM, available in an LSB-compliant package that will install and run cross-distro
  
  GPL is important in this situation, why ? You are referring to a licensing issue, not a technical one. Also Java is available as an RPM or as a self executable so it should install and run cross platform without any problem. LSB or no LSB.
  
  and wont break if you use a different X server or non-standard hardware...then we'll talk.
  
  Can you please explain where different Xserver/hardware combinations have affected Java apps. Or are you just trolling ?
  
  --
  Funtage Factor: Purple
36. Re:Actually... by Furry+Ice · 2004-12-20 16:20 · Score: 1
  
  Java cannot run everywhere. Java can only run on platforms that have a useable JVM. If your only goal is to write an application to run "cross-distro" (which I take to mean Linux) that you might as well write something that can run on all flavors of UNIX. Pick Perl, Python, Ruby, or whatever blows your hair back. You'll find it much simpler than trying to get Java running on OpenBSD!
  
  If you want something to work on Windows, Mac, and a subset of UNIX including Linux, Solaris, AIX, and HPUX, then Java is a reasonable choice. Using Java strictly for UNIX is actually counter-productive.
37. Re:Actually... by Craig+Ringer · 2004-12-20 18:12 · Score: 1
  
  'fraid I can't agree. I'm a heavy Python user myself, but writing portable Python apps is a pain. The code is portable, sure - but the user generally has to download, compile, and install things like mxDateTime, a DB interface, a GUI toolkit, etc. That, or use the distro shipped versions that may or may not be up to date and compatible.
  
  Sure, I could use Tkinter and Gadfly, but for many purposes that just doesn't cut it, and Tkinter wastes a lot of my time compared to Qt.
  
  Java may have an awful GUI toolkit (Swing) but at least it's there - and SWT from Eclipse is pretty darn impressive.
  
  Generally I choose to use Python anyway, but if my app was to be very widely distributed and I couldn't just tell people "get non-mouldware versions of Python and the libraries" I'm not sure Python would be worth the trouble.
38. Re:Actually... by Taladar · 2004-12-20 18:39 · Score: 1
  
  Java does behave the same on all distro:
  
  It doesn't work flawless on any of them.
  
  --
  Linux is not Windows
39. Re:Actually... by L'homme+de+Fromage · 2004-12-20 18:55 · Score: 1
  
  Solaris
40. Re:Actually... by Oestergaard · 2004-12-20 19:51 · Score: 0, Flamebait
  
  If the Java garbage collector worked,
  every Java program would delete itself immediately upon startup.
  
  - me.
41. Re:Actually... by Oestergaard · 2004-12-20 19:59 · Score: 1
  
  That seems overly restrictive...
  
  As I see it, conversion tools are only necessary in the female-female scenario if both subjects must use both hands for eating at the same time.
  
  Or am I missing something in your analysis of the (arguably special case) scenario? :)
42. Re:Actually... by Taladar · 2004-12-20 20:13 · Score: 1
  
  Thanks but no thanks. I would prefer not to have Windows-packaging shit on Linux where every Programs brings all the Libraries it needs and thus either overwrites the different versions or I have two or three versions of the same library in RAM to support the same number of apps.
  
  --
  Linux is not Windows
43. Re:Actually... by LQ · 2004-12-20 21:35 · Score: 1
  
  ...and I've see Java apps (i.e.InstallAnywhere [zerog.com]) that stopped running because a distro changed from XFree86 to X.Org. The (Sun) JVM was expecting a certain library to be there, it wasn't, and boom!! - it fall down... Mandatory "Java Sux!" - me
  So linux sucks and you blame java?
  I've used lots of distros over the years and have concluded that if an app doesn't come with the distro, it usually won't work. Unless it's java, then it might.
  Linux is still fit only for the hobbyist or professional with an IT department's support. In the latter case, they pick one distro and stick with it.
44. Re:Actually... by mollymoo · 2004-12-21 00:34 · Score: 1
  
  OS X
  
  --
  Chernobyl 'not a wildlife haven' - BBC News
45. Re:Actually... by markandrew · 2004-12-21 00:36 · Score: 1
  
  100 million romans can't be wrong! ;)
46. Re:Actually... by Anonymous Coward · 2004-12-21 03:10 · Score: 1, Interesting
  
  Actually the topposter is right. While there is a lot in java that we all use and sometimes it seems like we need no external libraries etc, we often do. Strangely there is little in the way of standardisation for this practice in java. there's the whole CLASSPATH thing, but this is where the problem occurs, cause where does the classpath point to on a distro? What libraries can be found there?
  
  I've seen a lot of java programs that just ship their own copy of libraries, because it is so much easier than having to worry about where to find your libraries, or telling the user he needs to "install" a certain set of libraries, which doesn't really mean anything in java. At least, this is my take on things.
Non Sequitur by pete-classic · 2004-12-20 09:04 · Score: 5, Insightful

Just because Linux is under the GPL, some people believe that it's pretty standardized.

Does anyone see how one thing is supposed to follow the other?

-Peter
1. Re:Non Sequitur by MikeMacK · 2004-12-20 09:07 · Score: 1
  
  Yeah, I missed that, one covers how a product is developed, one covers how it is released.
2. Re:Non Sequitur by pete-classic · 2004-12-20 09:13 · Score: 2, Insightful
  
  Huh? Neither "GPL" nor "standardized" represent either of these things AFAICT.
  
  -Peter
3. Re:Non Sequitur by Eric+Giguere · 2004-12-20 09:21 · Score: 3, Insightful
  
  Doesn't releasing something under GPL pretty much guarantee a loss of standardization? GPL = "Go, procreate and live".
  Eric
  How to detect Internet Explorer using the headers
4. Re:Non Sequitur by FooBarWidget · 2004-12-20 10:05 · Score: 2, Funny
  
  Then by your reasoning, we should kill democracy because having two ore more different milk manufacturers is bad.
5. Re:Non Sequitur by remahl · 2004-12-20 10:10 · Score: 1
  
  No, that does not follow from his reasoning. He didn't say that "go, procreate, live" and the loss of standardisation is bad.
6. Re:Non Sequitur by Tribbin · 2004-12-20 11:58 · Score: 1
  
  While it makes it much easier to be standardized, it does not mean that people will do just that.
  
  --
  If you mod this up, your slashdot background will turn into a beautiful sunset!
7. Re:Non Sequitur by bit01 · 2004-12-20 20:03 · Score: 1
  
  Doesn't releasing something under GPL pretty much guarantee a loss of standardization? GPL = "Go, procreate and live".
  
  Of course not. Commercial licenses are far worse. They usually try to block duplication, reverse engineering and compatibility. Forcing competitors to be different.
  
  GPL open source competitors at least have the option of being the same if they want. BSD style open source allow value add's that cannot be incorporated into the original and again can cause balkanisation and incompatibility.
  
  I don't want to get into a GPL v. BSD debate here. I don't use BSD style licenses myself but I have no problem with people who do. It's still far better than the average closed source license, where the real problem is.
  
  ---
  
  It's wrong that an intellectual property creator should not be rewarded for their work.
  It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
  Reform IP law and stop the M$/RIAA abuse.
How about building applications for unix? by Anonymous Coward · 2004-12-20 09:05 · Score: 1, Insightful

There may not be that many linux-specific high-quality standards, but linux follows closely most relevant unix standards. So why not just build your applications for the Single Unix Specification and ignore any linux-specific features?
1. Re:How about building applications for unix? by DreadSpoon · 2004-12-20 09:55 · Score: 4, Interesting
  
  First, that doesn't work in real life, where even the "real" UNIX systems don't follow the various UNIX standards perfectly.
  
  Second, SUS and other UNIX standards don't cover binary portability at all, which is usually far more interesting to _users_ than source compatibility. I haven't and never will look at the source of most the apps I run, but I _do_ know that I want to be able to run them. I don't want to have to compile things myself, wait for others to compile and package them, and/or hunt through hundreds of packages for the same software to find the one that works on my systme. I want to go to the upstream software's site, click Install Software, and have it work. And that's 100% feasible, assuming the apps sticks to a standard like the LSB and your distro is LSB compliant.
  
  Third, there's also then the issue of proprietary apps which don't even have the option of making users compile the source. Unfortunately, there are proprietary apps out there, there are people who _want_ to use proprietary apps even in the face of existing OSS alternatives, and that's that. The LSB largely exists to serve those apps, in fact.
2. Re:How about building applications for unix? by dbacher · 2004-12-20 10:12 · Score: 1
  
  Not to mention, pop up "configure.sh" and look at how many of the problems a typical project has to work around because some *nix variant pukes if you Malloc 0x2020 bytes or some other nonsense...
  
  --
  If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
3. Re:How about building applications for unix? by networkBoy · 2004-12-20 10:40 · Score: 2, Insightful
  
  Not trolling here, but that illustrates how M$ and Windows are being successful.
  
  If this (LSB) actually takes off it could be what allows *nix to displace windows in the Joe Sixpack Desktop. All Joe currently knows is that he has a windows computer, so he looks for software that says Windows on it. With this as a replacement Joe's information complexity does not change just =~s/windows/LSB/g and Joe's happy.
  
  What I see here instead is:
  1) My way of implementing portability is best(Java)
  2) No it's not (Python)
  3) You're right, mine is (PERL)
  
  Whatever people. Until the developers can agree on a minimum compatibility spec that can be advertised (possibly LSB) Linux will only be in the data center.
  -nB
  
  --
  whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
"linux standardization" by stratjakt · 2004-12-20 09:07 · Score: 5, Insightful

This is about the hundredth project of it's kind that I've seen since linux' infancy.

Good luck to it. I'd love see a "works with linux" stamp, and have distro choice be completely irrelevant.

It's absolutely necessary if linux is to go anywhere worth going commercially.

--
I don't need no instructions to know how to rock!!!!
1. Re:"linux standardization" by Anonymous Coward · 2004-12-20 09:10 · Score: 0
  
  Yes, standardize things.
  
  And no, you may not assume /bin/sh is bash. If you are using bash features, use /bin/bash.
2. Re:"linux standardization" by grub · 2004-12-20 09:10 · Score: 1
  
  "Works with *BSD" would be easier. 3 main "distros" but each is its own complete package not just a kernel with various GNU packages thrown in.
  
  --
  Trolling is a art,
3. Re:"linux standardization" by Frohboy · 2004-12-20 10:08 · Score: 2, Informative
  
  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.
4. Re:"linux standardization" by runderwo · 2004-12-20 10:41 · Score: 3, Interesting
  
  LSB is nothing new. It's been around since 1998. It's also a vendor consortium, which means nonprofits like Debian have no say in the standards they publish. That fact alone will unfortunately limit its uptake to the commercial distributions, and in the end probably just cause a greater divide between the commercial and noncommercial distros.
  
  --
  LRC, the best-read libertarian site on the web
5. Re:"linux standardization" by Anonymous Coward · 2004-12-20 11:02 · Score: 0
  
  Good luck to it. I'd love see a "works with linux" stamp, and have distro choice be completely irrelevant. It's absolutely necessary if linux is to go anywhere worth going commercially.
  
  True. However, because this doesn't exist, the simplest and most practical way to address this issue (and the issue of administrators not having to learn the differing tools of every distribution of Linux) is for corporations to just standardize on the most popular Linux distribution. So they'd basically want to choose Redhat if they want to maximize compatibility with proprietary apps whose source they can't get.
  
  Which means that if this issue of compatibility is important to you, then Redhat is the clear best choice. No vendor will release software that won't run on Redhat. If you carry that a little further, it means that when it comes to commercial use, the set of all Linux that is practical to use more or less equals Redhat.
  
  Now, to my point: it isn't necessarily a lie when Sun equates Redhat with Linux. It's just a practical assessment.
  
  Furthermore, if you don't like it when people say that Redhat equals Linux in a practical sense, then the best way to solve that problem is to put in place some standards and make any compatibility issues go away, so that the argument that it's only practical to stick with the most mainstream distribution is no longer a good argument.
6. Re:"linux standardization" by Stevyn · 2004-12-20 11:08 · Score: 2, Interesting
  
  This discussion has been brought up several times here on slashdot. It always consists of the same arguments.
  
  There are those that feel it's not important. Those that feel it's absolutely critical. And those that claim it already exists.
  
  Well, it is important and it doesn't already exist. Four package managers that usually work don't count as a standard. That's just the shotgun method of hoping one of them will hit the target.
  
  What helps linux growth in one area hurts it in other areas. Developers and distros keep trying to reinvent the wheel. The worst is when it doesn't work, the response is "well, it doesn't work too well on windows so what do you think of that?" (not from developers, but comments on here).
  
  I think the only way developers could agree on one standard would be if someone high up the chain like Linus either came up with an idea or picked one and people worked on improving it. However, it's been my understanding that this is not something he would want to do.
  
  Until then, I'll keep using portage ;)
7. Re:"linux standardization" by Wild+Wizard · 2004-12-20 11:58 · Score: 1
  
  It's also a vendor consortium, which means nonprofits like Debian have no say in the standards they publish.
  
  And to make it worse they even state that RPM may become required in the next version.
8. Re:"linux standardization" by Anonymous Coward · 2004-12-20 14:58 · Score: 0
  
  4 main distros, not 3.
9. Re:"linux standardization" by Anonymous Coward · 2004-12-20 15:06 · Score: 0
  
  Free|Open|Net
  What is the other?
10. Re:"linux standardization" by Taladar · 2004-12-20 20:35 · Score: 1
  
  Which will ultimately kill the Project. RPM is the one worst package format ever. Everyone except the commercial distros knows this and uses a better packaging tool.
  
  --
  Linux is not Windows
11. Re:"linux standardization" by Taladar · 2004-12-20 20:38 · Score: 1
  
  As long as people standardize outdated technologies like rpm this will not change. You need at least something like portage or apt to get all distros together.
  
  --
  Linux is not Windows
12. Re:"linux standardization" by mollymoo · 2004-12-21 01:53 · Score: 1
  
  You forgot the biggest BSD, indeed the biggest *nix-alike distribution on the desktop, Darwin.
  
  --
  Chernobyl 'not a wildlife haven' - BBC News
13. Re:"linux standardization" by Bob+Uhl · 2004-12-21 08:13 · Score: 1
  
  .rpm is the equivalent of .deb, not apt. And apt runs atop rpms these days--I'm happily using it with Fedora Core 2 & 3. rpms are actually pretty nice. Not perfect, but decent.
make configure by elgatozorbas · 2004-12-20 09:08 · Score: 1

Does this mean the "make configure" checks will be shorter, because stuff if standardized? Or where will this be visible for end-users?

Z
1. Re:make configure by eln · 2004-12-20 09:11 · Score: 1
  
  I doubt it. Even if everything is supposed to be standardized, the "make configure" checks still have to be sure whatever system its on conforms to the standard. Besides, most projects use the same checks as every other project, so there's not a whole lot of harm in checking to make sure everything is how you expect it to be before compiling.
2. Re:make configure by Arker · 2004-12-20 09:21 · Score: 1
  
  Does this mean the "make configure" checks will be shorter, because stuff if standardized? Or where will this be visible for end-users?
  
  No, the whole LSB thing is pretty well irrelevant to software. It's about binary package compatibility, and only really interesting or useful for people that want to try and sell linux binaries instead. Which is one of the reasons you'll find lots of important people (Volkerding comes to mind) either apathetic or openly contemptuous of the thing, while the support for it comes mostly from folks like RedHat and Suse/Novell that are in the business of supporting their distro as a platform for things like, for example, Oracle, that are not and likely never will be available any other way.
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
3. Re:make configure by dbacher · 2004-12-20 10:19 · Score: 1
  
  Yes, it does (contrary to the other two posts).
  
  Currently, configure.sh usually has to probe for a lot of libraries, to determine what's available on your system. If you require LSB, you don't need to probe for any library or function that is part of LSB.
  
  This is similar to requiring ISO or ANSI C/C++. If you require ANSI C++ v3, then you don't have to probe for a lot of information.
  
  For example, a common probe in configure.sh is to determine byte width. If you can be sure you're running on only ANSI/ISO compilers, you can just pull in stdtypes, and use int32, uint32, etc. and friends, and you have template functions that can return sizes, limits, etc.
  
  You can be sure IO Streams is there and that the base STL is there, and have a firm foundation to build from.
  
  The issue is most projects won't be brave enough to tell their users "we're only supporting systems with the LSB baseline."
  
  That's why we still have checks for work around for bugs in SunOS 3 going in to new code, becuse nobody is brave enough to tell the Sun OS users, "You know what, just install GNU C and the GNU libraries so that we don't have to keep dealing with 20 year old bugs."
  
  --
  If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
it's lame that... by xyeeyx · 2004-12-20 09:11 · Score: 4, Insightful

...programs can break on subsequent versions of linux because something has been moved or changed. Come on, guys. Maybe the reason linux isn't mainstream yet is because it's so hard to get your feet on the ground before the rug is pulled out.
1. Re:it's lame that... by Pinkfud · 2004-12-20 09:22 · Score: 1
  
  Somebody needs to write a standard for what and where dependencies are installed. Few things are more aggravating than trying to fix a missing dependency when you don't even know where the app expects it to be.
  
  --
  The world is my oyster. That's why it's always in a stew.
2. Re:it's lame that... by Feyr · 2004-12-20 09:27 · Score: 2, Insightful
  
  that's called ldd and strace. those let me solve missing deps problems in under 5 minutes
3. Re:it's lame that... by Jeff+DeMaagd · 2004-12-20 09:55 · Score: 1
  
  What bugs me is that nearly every time there is a Firefox update, half the extensions I use are broken or disabled by Firefox because the extension doesn't mark itself as being compatible with a version number that didn't exist when the last extension revision was made.
4. Re:it's lame that... by Archangel+Michael · 2004-12-20 09:56 · Score: 2, Insightful
  
  SCUSE ME, but shouldn't the average user not have to worry about such things? I mean, I can and do use make and ldd and strace and all that, but then again I am a professional. Mom on the other hand isn't, and shouldn't have to worry 'bout such things.
  
  Linux will not get to the desktop until such time as one can walk into a store (or online) and buy SUPERDEEDUPER Tools for Linux for 49.95 and have it work, out of the box on all the major distros (SuSE, Redhat, Fedora, Debian ..... ).
  
  --
  Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
5. Re:it's lame that... by cortana · 2004-12-20 10:04 · Score: 1
  
  How can the extension possibly claim that it is compatible with a version of the extensions API that didn't even exist when the extension was written?
  
  You have the choice between extensions being disabled (big deal--wait for them to be updated), or extensions breaking horribly, possibly causing data loss, when you upgrade...
6. Re:it's lame that... by Anonymous Coward · 2004-12-20 10:46 · Score: 0
  
  And if you need to use tools like ldd and strace to get your applications running every time you do a system upgrade, then it's not truly for a mainstream business environment. I can hear it now, "blah blah blah you should hire more skilled system administrators"... Regardless of whether or not someone has the skill to do it or not, that is not an acceptable amount of time spent accounting for update variance in a business environment. You think that your IT manager won't let you switch everything over to Linux because they hate you or are anti open source? Wrong. They won't let you switch everything over to Linux because of stuff like that which understandably scares the hell out of them.
  
  I'm glad that your system upgrade related downtime is relatively low on what is most likely a low volume or personal server or workstation... but in a high availability situation, it's not an acceptable risk.
  
  I don't understand why so many people are against this sort of standardization. So much of the open source movement is about religiously holding onto standards because they are a good thing. Are so many people shunning standards simply because they've got clever workarounds? Sometimes it almost seems like people are purposefully obfuscating the system to make themselves feel smart for knowing how to use it and therefore being able to post snarky slashdot posts about people who don't. You might as well walk around with bull horn yelling "I AM SO SMART!!! EVERYONE WORSHIP ME!!! I AM THE LEETEST!!!"
7. Re:it's lame that... by jayed_99 · 2004-12-20 11:04 · Score: 1
  
  ...programs can break on subsequent version of Windows becuase something has moved or changed. Come on, trolls. Maybe the reason windows spreads most of the viruses on the internet is because it's so hard to get your PC online without getting 0wn3d.
8. Re:it's lame that... by Feyr · 2004-12-20 11:10 · Score: 1
  
  i'm not against this sort of certification, and as another poster pointed out it's not an acceptable thing to do for a home user.
  
  but for businesses applications, it's perfectly fine.
  if you have to fear that your system "upgrades" are taking too long, your HA setup is flawed. it is not a risk, it should be part of your quality testing no matter if it's supposed to work or not.
  
  my managers don't fear linux, in fact most of our shop is on linux. most applications Just Work, yet we STILL test them... even on supported distros, just in case something is wrong, or someone fat fingered the config. part of life, it should be part of your plan
9. Re:it's lame that... by Chandon+Seldon · 2004-12-20 11:12 · Score: 1
  
  Linux will not get to the desktop until such time as one can walk into a store (or online) and buy SUPERDEEDUPER Tools for Linux for 49.95 and have it work, out of the box on all the major distros (SuSE, Redhat, Fedora, Debian ..... ).
  
  Why's this? One of the big advantages of Linux is that anything you'd reasonably expect to find in SUPERDEDUPER TOOLS is prepackaged by your distributor.
  
  In fact, even Windows has moved away from "go to the store and buy random crap" to "go on the net and download random crap". For most of this software, the Windows version is lower quality and shareware compared to Linux's high quality open source app.
  
  The only real quesion is relevent commercial applications. It would be nice if you could go to BestBuy and get Lotus Smart Suite for Linux in a box with some CDs.
  
  But if you think about that for a bit, it's a lot smaller of an issue than you'd think. First, there's no real obstacles to releasing software like that for Linux... Loki Installer works pretty well. Second, with OpenOffice being a free download, you don't really need SmartSuite.
  
  The "Existing Downloadable Tools are Fine" statement makes most boxed software pretty much irrelevent. Antivirus software is not an issue currently for Linux. With standard "Office Suite" stuff, eithor OpenOffice is fine or you want Microsoft Word. With graphics manipulation stuff, eithor The Gimp is fine or you want Photoshop.
  
  We could probably make a short list of commercial software where it not being available boxed for Linux in the store really matters... but I don't think that the lack of boxed software for Linux in general is really a relvent thing holding it back from Desktop usage.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
10. Re:it's lame that... by Abattoir · 2004-12-20 13:45 · Score: 1
  
  What, you mean like libdb?
  
  Or glibc?
  
  Or the kernel itself?
  
  Incompatibilities due to minor differences in versions in the above are a great source of frustration for me. I have a customer running Red Hat 2.1 instead of RH3.0 (their other environment) because their application isn't supported on anything newer, due to differences in the glibc between RH 2.1 and RH 3.0.
  
  It would also be really nice if LVM were supported on RH 2.1, and ReiserFS were supported on 3.0. As it is, my SAN storage is all custom and difficult to manage due to lack of support for both of these technologies across all the systems on the account.
11. Re:it's lame that... by AbbyNormal · 2004-12-20 14:12 · Score: 1
  
  This is also why I know of a lot of shops are not jumping into the mix, and migrating over their NT systems to A linux system. Its just too risky though and there is no standard "bridge".
  
  Its easy to write a program in NT, package it up with the free MS installer and all the dependencies, in one nice executable file.
  
  There doesn't seem to be a single full featured platform that meets NT developers in the middle. I think Mono is getting close, but is nowhere near primetime.( Perl is promising as well).
  
  I could only imagine what would happen to Linux, if a project came out with an easy RAD IDE that worked on any OS and had the full steam/publicity as say Firefox.
  
  --
  Sig it.
12. Re:it's lame that... by Taladar · 2004-12-20 20:47 · Score: 1
  
  Why don't they use API Versioning and all Extensions using APIs that don't change don't break and the others that use changed ones get disabled? Why use the global version number?
  
  --
  Linux is not Windows
13. Re:it's lame that... by bit01 · 2004-12-20 20:49 · Score: 1
  
  Linux will not get to the desktop until such time as one can walk into a store (or online) and buy SUPERDEEDUPER Tools for Linux for 49.95 and have it work, out of the box on all the major distros (SuSE, Redhat, Fedora, Debian ..... ).
  
  You are applying the M$Windows model of software development/distribution to the open source world. This is a common error by closed source developers.
  
  In the open source world everything that the average user may need and is of adequate quality is already included in the distribution.
  
  Remember, open source is free (libré). Good quality distributions will include everything they think their target user will need, including support for standard hardware and major application areas.
  
  For more specialised application software the creators/distributors, if they have any sense, package the software in the way that is appropriate for their target user. In the open source world this is usually, not surprisingly, in source form, though many packages distribute binaries.
  
  ---
  
  It's wrong that an intellectual property creator should not be rewarded for their work.
  It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
  Reform IP law and stop the M$/RIAA abuse.
14. Re:it's lame that... by cortana · 2004-12-21 03:05 · Score: 1
  
  Well, the global version number _is_ the API version. The developers are making the assumption that the APIs break every new release of the software. This is a conservative decision, one that errs on the side of caution. After all, even though the API and ABI match exactly, if the behaviour of one of the functions changes, the API _is_ broken.
  
  But, if you want to override the extension manager, you can re-enable your disabled extensions. Google for more info.
15. Re:it's lame that... by Archangel+Michael · 2004-12-28 07:36 · Score: 1
  
  You want to force people into a new paradigm. You cannot. You must move them by showing them the way. My point in the original post is people are used to doing things a certain way, because that is what they are used to (catch 22). They don't change simply because someone tells them there is a better way.
  
  You must SHOW them the better way. For instance, IE vs Firefox. The average M$ user doesn't know, or even if (s)he does know, doesn't NEED to change. However, if you show them a BETTER way, they will use it.
  
  It is experiential.
  
  --
  Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Application level isn't such a problem by grahamsz · 2004-12-20 09:11 · Score: 3, Insightful

An effort to make device driver standards would mean a lot more to lots of us.

That would make it easier for manufacturers to make linux supported hardware and know that it worked.

Every linux user needs linux compatible hardware, but relatively few need commercial software.
1. Re:Application level isn't such a problem by grub · 2004-12-20 09:18 · Score: 1
  
  An effort to make device driver standards would mean a lot more to lots of us.
  
  That would make it easier for manufacturers to make linux supported hardware and know that it worked.
  
  I think you're putting the cart before the horse. The manufacturers are the ones that write the hardware specs to which drivers are written.
  
  --
  Trolling is a art,
2. Re:Application level isn't such a problem by slux · 2004-12-20 09:36 · Score: 1
  
  It isn't a good idea and here's why.
3. Re:Application level isn't such a problem by LordNimon · 2004-12-20 09:36 · Score: 1
  
  He's talking about the kernel interface, so that drivers don't need to be rewritten every six months like they do today.
  
  --
  And the men who hold high places must be the ones who start
  To mold a new reality... closer to the heart
4. Re:Application level isn't such a problem by ink · 2004-12-20 10:11 · Score: 1
  
  Actually, the author has a simple reccomendation:
  
  So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.
  
  Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .) If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very little effort on your part.
  
  --
  The wheel is turning, but the hamster is dead.
5. Re:Application level isn't such a problem by slux · 2004-12-20 10:26 · Score: 1
  
  exactly, so no "standard API" and certainly no binary modules which I presume was what the parent perceived to be in need of such a standard.
6. Re:Application level isn't such a problem by dbacher · 2004-12-20 11:40 · Score: 3, Insightful
  
  2.6.8 to 2.6.9 broke ABI.
  
  --- QUOTE from someone who doesn't get the problem
  Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .) If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very little effort on your part.
  ---END quote from someone who doesn't get the problem
  
  Wrong.
  
  The kernel developer goes into the GPL source code, and marks the driver as "incomplete" or at absolute best makes it compile. Not actually having the device, in all likelyhood, the code is then comitted, untested, to the kernel.
  
  At some later point in time, a week or a month down the line, some unsuspecting user installs the updated kernel, and their device starts having random, untrackable problems. They come to the list, and are told by a dozen people that the kernel developers aren't responsible for drivers, and that they should talk to whoever actually maintains the driver.
  
  After finding the appropriate mailing list for the particular driver that the kernel developer broke, the user posts a question about is there a patch, and receives e-mails from not less than 10 trolls telling them "it's open source, fix it yourself." Their message is in a sea of messages in all caps with too many question marks and exclamation points, where a developer is going around in circles with a user who can't afford a keyboard with a shift key, and can't afford to buy a vowel (they are expensive, you know).
  
  Finally after all of this, the device driver developer sends them back a reply "sorry, I've not had a chance to test with the new kernel yet, run the old version while you wait." Then the developer gets around to posting a patch.
  
  If you're lucky, it's a device a lot of people use, people get angry about it, and it gets some attention fast. If you're unlucky, you've got a device that needs the older kernel and a device that needs the newer kernel, and you have to make a choice between the two and wait for the other driver to get upgraded.
  
  The odds of another user capable of it getting off their ass and actually researching, fixing, and posting the fix are virtually nil.
  
  Here is the scenario for Windows:
  Insert your device
  Boot the computer
  Windows says "there's a new device, put the disk in"
  Windows copies the device driver
  Windows possibly reboots (this is rare for most device classes, but some still need reboots)
  Device works
  
  Now you can argue about bluescreens or whatever, but it is a better model in that Microsoft's kernel team takes no time maintaining device drivers. There's a clear ABI division between their kernel and their drivers, and that division changes only at major versions of the kernel.
  
  This is the thing. When I get the kernel, I'm getting thousands of drivers I don't want or need. Most of these aren't being actively maintained, and are being updated so that they compile but aren't undergoing any level of testing at all.
  
  The kernel developers do not perform unit testing on the drivers (there is no facility for them to do so), and do not typically have the hardware or the large number of hardware, software combinations that need to be tested.
  
  So no, putting it in the kernel tree does absolutely nothing to solve the problem.
  
  --
  If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
7. Re:Application level isn't such a problem by grahamsz · 2004-12-20 13:06 · Score: 1
  
  Not all drivers can be released as GPL.
  
  Some drivers include proprietory information that can't be GPL'd. Most hardware manufacturers license IP from other people and naturally can't give that away as open source.
  
  I'm not saying this is right, or the way things should be - but it does seem to be true.
  
  I'm not even sure that all drivers need to be in the kernel. I don't see why we cant have stable interfaces for wireless drivers, for USB devices, firewire devices etc...
  
  Attitudes like this guys don't help linux. Sure if linux were the world's #1 OS and all the cool new hardware needed to support it... then this would be great. But the truth is that we are playing catchup and making it more difficult for hardware vendors to provide support.
8. Re:Application level isn't such a problem by romi · 2004-12-20 17:43 · Score: 1
  
  Amen. Anyone who thinks that Linux driver compatibility problems somehow magically disappear once the driver is released with the kernel clearly has never worked on such a driver.
  
  A kernel ABI is not *just* about making the lives of proprietary vendors easier; IMO, the anti-ABI camp is throwing out the baby with the bath water.
9. Re:Application level isn't such a problem by Anonymous Coward · 2004-12-20 19:21 · Score: 0
  
  Please explain why it works reasonably with Windows and quite well with Solaris. Please explain why Linux could not do it BETTER than Windows and Solaris.
10. Re:Application level isn't such a problem by Taladar · 2004-12-20 20:54 · Score: 1
  
  Strangely the only drivers that make problems all the time on my PC are the two or three drivers that are not packaged with the vanilla kernel (NVidia and Ndiswrapper).
  
  --
  Linux is not Windows
11. Re:Application level isn't such a problem by Spy+Hunter · 2004-12-21 04:08 · Score: 1
  
  This discussion is almost as old as Linux, and Linus's answer is the same: A stable driver ABI means closed-source binary drivers, and he doesn't want closed-source binary drivers, therefore he will not freeze the ABI. Plus he likes the freedom to change the ABI because it allows easier improvements to the core kernel. If you don't agree, it is pointless to complain here. Linus is not going to suddenly change his mind after over 10 years.
  Projects like ndiswrapper prove that it is possible to maintain a driver compatibility layer outside the kernel. If you really want a stable driver ABI for linux, develop it yourself, because Linus isn't going to do it for you.
  
  --
  main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
12. Re:Application level isn't such a problem by ink · 2004-12-23 06:26 · Score: 1
  
  Agreed. And even then, the new Nvidia installer is pretty slick. It finds what kernel you're running; checks a list of available ones online, and if it cannot find a match, will automatically compile a new one for you (all in a pretty curses interface). Their ABI bindings are hidden with some source glue that goes in the kernel. This may not be "the Windows way to do things", but it works just fine on my systems. Very few drivers are binary-only anyway; most hardware manufacturers make money on sales, not on driver IP...
  
  --
  The wheel is turning, but the hamster is dead.
Extract from book by oexeo · 2004-12-20 09:18 · Score: 4, Funny

File naming protocol
------
Characters in filename names are a rare commodity, to be used wisely.
Filenames should be abbreviated to the point of obfuscating any meaning:
Why use "print" when you can use "prin," why use "prin" when you can use
"pin," why use "pin," when you can use "xb."

Standard output formatting protocol
------
When printing a table of data to standard output, there is no need to
label rows and columns. Linux users are elite professionals, they
instantly know what the endless rows and columns of hex values,
abbreviated acronyms, and various other standard and non-standard
variables represent.

In the rare occasion that a Linux user is unsure what some data
represents, he will simply view the source, if the source is not
available, he will disassemble the executable, and read the assembly code.

If you must label columns and/or rows, please
follow guidelines set out by the "File naming protocol" section.
1. Re:Extract from book by Anonymous Coward · 2004-12-20 09:31 · Score: 0
  
  No, he has a point. Maybe if things were labeled better there would be less confusion.
  Look at OS X. They have longdirectory names, such as "Applications" Ooooo - I wonder what goes in there. Or maybe "Library". I can't figure out what resides in there.
  Half the people in my class still thing /usr is short for 'user' and not 'unix system resources'
2. Re:Extract from book by jacksonj04 · 2004-12-20 09:32 · Score: 1
  
  Sod funny, give that man 'Insightful'.
  
  With Windows and Macs, you can just jump in and do stuff. With Linux, even if you have a GUI, there's no chance without referring to the man pages. And how do you know you need to go "man ???" to get a help page?
  
  --
  How many people can read hex if only you and dead people can read hex?
3. Re:Extract from book by Anonymous Coward · 2004-12-20 09:37 · Score: 0
  
  With Windows and Macs, you can just jump in and do stuff.
  
  Trivial stuff that Microsoft or Apple allow you to do. If the length and breadth of your aspirations is changing your desktop background, then sure, you can do stuff.
  
  The point with Linux is that it's open ALL THE WAY DOWN (at least until the bloody hardware driver "firmware". Bleurgh. But that's not linux's fault.). I use linux because I want my OS to conform to my wishes, not vice-versa.
4. Re:Extract from book by PenGun · 2004-12-20 09:39 · Score: 0
  
  Oh gee you have problems with bin for binary and lib for library, how cruel of Ritchie et al.
  
  Pookie the reason its shortened is so it types faster although completion can help here. I guess people like me who alias ls to ll are just part of the problem.
  
  PenGun
  Do What Now ??? ... Standards and Practices !
5. Re:Extract from book by Fizzl · 2004-12-20 09:40 · Score: 1
  
  Or maybe "Library". I can't figure out what resides in there.
  
  The documentation?
  
  --
  Bot Assisted Blogging
6. Re:Extract from book by Anonymous Coward · 2004-12-20 09:43 · Score: 0
  
  That's good. You are quickly understanding the subtle humor that quite frankly *IS* slashdot.
  
  One last word to the wise before you go off on your own young grasshopper:
  
  "All your base" doesn't actually belong to them.
  
  No go. Run! I have faith.
7. Re:Extract from book by Kenshin · 2004-12-20 09:49 · Score: 1
  
  Half the people in my class still thing /usr is short for 'user' and not 'unix system resources'
  
  Wow. You learn something every day. (Really, I just did.)
  
  --
  Does it make you happy you're so strange?
8. Re:Extract from book by Fizzl · 2004-12-20 09:51 · Score: 1
  
  And subtle sarcasm...
  
  Sorry. In true /. spirit I neclegted(sp?) to read the last paragraph thus failing to see the humour was already implied...
  
  --
  Bot Assisted Blogging
9. Re:Extract from book by cortana · 2004-12-20 10:07 · Score: 1
  
  Oh my god! In order to use a system I have to read a MANUAL?
  
  Oh, and I found out about man pages in the install guide that came with my distribution.
10. Re:Extract from book by cortana · 2004-12-20 10:19 · Score: 1
  
  Remind me never to use utilities written by you. It means I won't be able to pipe the output through awk and get sensible results, without wasting my time addint corner cases to strip out the row and column headings. Thanks a bunch!
11. Re:Extract from book by harves · 2004-12-20 10:28 · Score: 2, Interesting
  
  From The Free On-line Dictionary of Computing (19 Sep 2003) [foldoc]:
  
  usr User. The "/usr" directory hierarchy on {Unix} systems. Once upon a time, in the early days of Unix, this area actually held users' home directories and files. Since these tend to expand much faster than system files, /usr would be mounted on the biggest disk on the system. The root directory, "/" in contrast, contains only what is needed to {boot} the {kernel}, after which /usr and other disks could be mounted as part of the multi-user start-up process.
12. Re:Extract from book by Michael+Woodhams · 2004-12-20 10:36 · Score: 2, Interesting
  
  Characters in filename names are a rare commodity, to be used wisely.
  
  In a previous job, I was (among other things) maintaining a tool for installing updates to a big vertical-market ap. We got a bug report that it was throwing errors over some file. On investigation, we found a java file with a file name over 100 bytes long, which was more than 'tar' could handle.
  
  We could have done some workaround on 'tar', but instead we bounced it back to the developers and told them to fix their *#$*%&#^ file name. Descriptive file names can go too far.
  
  --
  Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
13. Re:Extract from book by Anonymous Coward · 2004-12-20 10:45 · Score: 0
  
  I've seen also "user system ressources". What usr really means is one of those great mysteries that baffle humanity.
14. Re:Extract from book by Anonymous Coward · 2004-12-20 10:51 · Score: 0
  
  Don't you think it would have been better to fix "tar" instead?
  
  Yes, I know... It's not a bug. It's in fact a feature of tar to make sure people don't use filenames that are too long...
15. Re:Extract from book by Anonymous Coward · 2004-12-20 11:17 · Score: 0
  
  The same way you no to click "START" to shutdown your computer.
  
  The same way you know "EXCEL" is a spreadsheet, and a large blue "e" means to opens the internet.
16. Re:Extract from book by Chandon+Seldon · 2004-12-20 11:21 · Score: 1
  
  Not true.
  
  Current version of KDE / Gnome (and at this point even previous versions going back a couple years) are realistically about as learnable by exploring as Windows or a Mac.
  
  If you put a random person who is used to a Mac and has never used Windows or Linux before in front of a properly set up Linux machine he'll have no more trouble performing the following tasks than he would if it were a Windows machine - in neither case would I expect that he'd need the documentation:
  
  Surfing the Web, Checking Email, Sending Email, Creating a simple word processor document and printing it, Scanning in a picture / adding a textual caption to it (i.e. With the gimp) / and uploading it to his website by FTP, joining an IRC channel and talking, doing instant messaging
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
17. Re:Extract from book by 0racle · 2004-12-20 12:00 · Score: 1
  
  I have never seen what the hell these things mean, for instance why is /etc where config files are, since config files are anything but simply more of the same thing. I'll still pronounce /usr as user.
  
  --
  "I use a Mac because I'm just better than you are."
18. Re:Extract from book by owlstead · 2004-12-20 12:08 · Score: 1
  
  Well, if that kind of thing is called a feature I am calling quits. I've had too much problems with burning MP3 CD's where the filename was too long. With a backup application it is way worse. It should simply support endless filenames. If I wan't my hdd backed up I do not want to be hindered by some stupid application enforcing its standards on me. Especially not when I am in a hurry.
  
  Note that Java supports inner classes, and concatenates the inner class name to the name of the owner class. The class names only have to be about 46 characters long for a class with ONE inner class. This goes only for the compiled classes, the source files do not use the inner class name.
  
  Still, 100 characters is a bit much.
19. Re:Extract from book by logpoacher · 2004-12-20 13:11 · Score: 1
  
  Wow. You learn something every day. (Really, I just did.)
  Sorry, dude, 'fraid you didn't. It really does mean "user". It used to be where the user accounts lived - /usr/fred, /usr/kt, and so on.
  But it gradually got filled with increasingly important system stuff, because it was usually the biggest area on the disk, sort of how /usr/local is now. Then the SVR4 filesystem revision came along, endorsing /var, /opt, and /home, and /usr was relegated to non-essential system stuff. The Unix System Resources thing is a sort of unofficial backronym.
20. Re:Extract from book by logpoacher · 2004-12-20 13:30 · Score: 1
  
  Half the people in my class still thing /usr is short for 'user' and not 'unix system resources'
  Nope. It's "user". Users' home dirs used to live there. The system stuff is a new-fangled thing, based on the way people used to use /usr as a good place to stick weird application directories there that only needed to be on-hand when the users were on hand, like X. Of course, gradually, these applications have became almost essential, and are now part of a system distribution.
  However, it's ok - after all, half of your class are right! :-)
  And if you want some fun .... you can always try re-propagating the rumour amongst your buddies that /etc stands for "extended tool-chest"! It doesn't, of course - it's just "everything else", from the days when you only had /lib, /bin, /dev, /usr, /mnt, /tmp and /unix. From the POV of a Unix system inventor, config files and utils were just "other stuff"!
21. Re:Extract from book by Taladar · 2004-12-20 20:59 · Score: 1
  
  The Problem with CD Burning is not the App but the CD Standard that does not allow longer names.
  
  --
  Linux is not Windows
metastandard by Doc+Ruby · 2004-12-20 09:21 · Score: 3, Interesting

The biggest pain in the ass I find in writing complex apps that interact with other complex apps, across different Linux distros, is the different filesystems. Where's the meta-FS-standard, where either "make" or at runtime my app can access a filesystem path under one distro's namespace (ie, on which the app was designed), and have it translated to the distro under which it will run?

"That's the nice thing about standards... there's so many to choose from!" - Anonymous PHB

--
--
make install -not war
1. Re:metastandard by Anonymous Coward · 2004-12-20 09:25 · Score: 0
  
  Cool! You have just proven that you don't know what a filesystem is. At all. Maybe you shouldn't comment on writing software?
2. Re:metastandard by Anonymous Coward · 2004-12-20 10:05 · Score: 0
  
  "the different filesystems" != "the different filesystem layouts"
  
  a different AC who was also a bit confused for a moment. clear writing is a tricky skill.
3. Re:metastandard by Doc+Ruby · 2004-12-20 10:32 · Score: 1
  
  The whole field is confusing in that it lacks specific nomenclature in common speech. For example, when my HD crashes, "the filesystem" is ruined - but of course *your* ext3 instance on *your* HD is unaffected. As usual, the context clues into the reference. The other AC was so obnoxious that they decided that the "filesystem" to which I refered was one which wouldn't make sense in my post, so they had an excuse to attack. Your more polite post at least falls into ambivalence. While the "charitable" logical deduction, among people trying to learn more from each other about filesystems, distros, and "Building Applications with the Linux Standard Base", is the directory structure and its problems for cross-distro developers.
  
  --
  --
  make install -not war
4. Re:metastandard by Anonymous Coward · 2004-12-20 11:31 · Score: 0
  
  Oh, I knew what you *wanted* to say. But you didn't.
5. Re:metastandard by Doc+Ruby · 2004-12-20 11:34 · Score: 1
  
  Of course you could tell: I posted "filesystem path under one distro's namespace", which makes the subject perfectly clear. You're just a fLamer.
  
  --
  --
  make install -not war
6. Re:metastandard by Chandon+Seldon · 2004-12-20 12:21 · Score: 1
  
  I'm having trouble visualizing a case where your issue would be more than an inconvienence solvable through a config file.
  
  For example:
  Let's imagine for a second that for Apache, each distro's premade package puts the log files in a different place, none of them the same as where the source package puts them by default. (This is probably true, but I'm not sure.)
  
  So, you right a program to analyze the apache log files. When it goes to find them, it looks in some places where they should be (perhaps "/usr/local/apache/logs" and "/var/log/apache"), and if it doesn't find them it dies with "Error: Can't find Apache logs, please specify their location in the config file at /etc/logscan/config".
  
  So...
  
  Give an example where A.) The list of expected paths + config file solution doesn't work and B.) This is something you'd really be distributing and expecting to work on other people's systems and C.) This isn't distro specific enough anyway that it would be reasonable to have distro-specific versions (i.e. KDE Kontrol Center).
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
7. Re:metastandard by Doc+Ruby · 2004-12-20 14:55 · Score: 1
  
  It *is* an inconvenience: that's another way of saying "pain in the ass", which I posted. That "config file" of course has to be populated with the directory structure map between distros. Which is what I asked for in my post. Why should each app reinvent that wheel every time they turn it? That's why we have tools like "getopts". So I'm talking about a tool like that. The mapping is deterministic, so it's a straightforward problem to solve once, for everyone. The amount of collective time spent criticizing my post, and my responding to it, could probably have been spent making the tool instead, if we preferred constructive programming to backbiting.
  
  --
  --
  make install -not war
8. Re:metastandard by Chandon+Seldon · 2004-12-21 00:42 · Score: 1
  
  How would you design the tool that you discribe? Where would it get the path information?
  
  I'm assuming you'd want to be able to say stuff like get_path("apache_log") or even redhat2debian("/usr/share/apache/log"). In that case the translation tool would need to have a database of different file paths - a much more failure-prone and maintnence intensive proposition than my config file solution - especially since distribution package maintainers would (do) populate the packaged config file with appropriate values.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
No! by The_DOD_player · 2004-12-20 09:23 · Score: 0, Offtopic

Come on people, that is not insightful,.. flaimbait at best.

- Java is slooooow (yes it is, just because its a fun language, doesnt make it any less slow). It's certainly not something you would want to code your browser, fps-game or webserver in.

- Every GUI Java application feels like, well,... like Java.

- Java doesnt run smoothly on all platforms. Maybe it just me, but Java has caused me trouble on all platforms I have used (Windows, RedHat, Debian and Gentoo).
1. Re:No! by arkanes · 2004-12-20 09:27 · Score: 1
  
  I'm a die-hard Java hater but I have to say that a web server is actually one of the few applications that Java can actually perform really, really well at. Java in client applications makes my skin itch, though.
2. Re:No! by Anonymous Coward · 2004-12-20 09:34 · Score: 0
  
  Java is slooooow ...
  
  Java CAN BE slow. I have helped develop a large sales-force automation tool for a well-known online news site and its related subsidiaries. Our first alpha version was indeed very slow starting up. Once started, it was fine, however. We applied some very rudimentary multi-threading design methodologies to the start-up process and, voila... an app not noticeably different from a C++ application insofar as startup time goes.
  It's a poor craftsman who blames his tools.
3. Re:No! by drgroove · 2004-12-20 09:35 · Score: 1
  
  Well written Java applications have little to no performance differences from native C/C++ apps.
  
  Swing-based GUIs do have a differing look and feel than native apps; IBM's SWT GUI toolkit resolves this issue by allowing Java GUIs to appear as native ones.
  
  I haven't experiences the problem of Java not running smoothly on various OSes. Windows, OSX, Solaris, various Linux distros - no probs.
4. Re:No! by Anonymous Coward · 2004-12-20 09:47 · Score: 0
  
  BTW, if you are referring to Tomcat, this has as much to do with the Tomcat developers being superheroes as it does to every improvement Java has managed for that particular type of application. The overhead on Java networking keeps dropping.
  
  I found a tutorial online for learning the new IO stuff in Java. The target application was a scalable, but minimal web server. Aside from the fact that the code had a bug that made it platform dependent (the "chunking" on the nio channels should not be relied on to be greater than 2 bytes, which this particular tutorial required for its check on the end of an HTTP request), the code ran extremely fast and did scale to support hundreds of simultaneous connections with no noticable performance degredation. All this for code that could be implemented in an hour (two, if you need to hunt down the above bug). Of course, this is all because the new IO libraries are very thin wrappers around native routines.
5. Re:No! by Anonymous Coward · 2004-12-20 10:06 · Score: 1, Interesting
  
  Swing based GUIs do have a different look and feel: they look like crap and they feel sluggish. Even the native look and feel doesn't feel native. If you have a C++ app that responds as slow as a Java swing app, you must be using the worst C++ gui library ever.
  
  Swing is *inherently* slow. The architecture is so reliant on delegations at various levels with pluggable look and feels that it has no chance of performing fast. Fortunately, a large number of applications do not require a super-responsive GUI. However, try building a decent Gantt chart that responds to clicks and drags like MS Project. You will find that Swing simply can't scale that well (and Project sets the bar fairly low).
  
  Java file access is pretty damn slow, though it got a speed boost in 1.4.something. It's now at least acceptable as long as the file is text. Parsing binary data in java is a pain in the ass, and also inherently slow because it has to drop into native calls and then bounce back up into java code.
  
  Java memory maps are fucking amazing. I can't imagine how anyone could develop something so slow and want to release it. They are a fucking joke. C and C++ memory maps are at least a hundred times faster.
  
  What the fuck do you mean by "well written?" Do you mean "text based networking code?" Because that is the only thing that Java does extremely well. Java is incredible for text based protocols (and I think C sucks, but I probably just haven't found a good library yet).
  
  Even on numeric stuff, Java would do well if it wasn't for the startup time. Compare a java app to a C++ app compiled with intel's compiler (no fair using g++, I they have some sort of rule that C++ must compile badly). Or compare it to gcc compiled C code. For small data files, the startup time kills the java app. For medium files, they perform about the same. For large files, Java runs out of memory and dies well before C or C++ (1.5 Gig memory limit? Why?). Oh, and also don't do a comparison on the Apple G5. The g++ optimizer is even more retarded on that (just stack allocate a 10000 by 10000 int array and set all values. Look at the awesome code that is generated).
  
  I know how JIT compilers work. I know every JVM available for Linux and Windows. Linear sweep register allocation just doesn't compare to a good graph coloring allocator. On a register rich chip like the PPC, it shouldn't matter, but on x86 it certainly does.
  
  Oh, and I have made simple string processing benchmarks that show Java performs better than C, it isn't that hard (hint: \0 terminated strings take linear time to check size).
6. Re:No! by Pseudonym · 2004-12-20 10:41 · Score: 1
  
  no fair using g++, I they have some sort of rule that C++ must compile badly
  
  Actually, the rule is that unlike the Intel compiler, G++ is cross-platform. Unfortunately, the IA32 architecture is a bitch to compile for.
  
  Most modern compilers are designed for modern architectures, and the GCC suite is no exception. Unlike a modern architecture, the IA32 has effectively zero integer registers and precisely zero floating-point registers (that you can actually treat as registers, anyway). Basically, the IA32 is the exception to every rule.
  
  Mind you, the IA64 is even worse in this respect...
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
7. Re:No! by AgentCharlieBrown · 2004-12-20 10:42 · Score: 1
  
  What about the gnu java compiler that produces binary code from java?
8. Re:No! by quantum+bit · 2004-12-20 10:59 · Score: 1
  
  Swing-based GUIs do have a differing look and feel than native apps; IBM's SWT GUI toolkit resolves this issue by allowing Java GUIs to appear as native ones.
  
  Yeah, but though SWT on any platform, and GTK+ on Win32 with a certain theme may _look_ like the native widgets, the problem is that they're not .
  
  Besides not "feeling" the same, some things that affect native widgets won't work with those since they're basically just bitmaps. For example, themes (think windowblinds, or XP themes engine on Win32; custom theme engines on GTK or QT). Screen readers, unusual font sizes. All of these don't interact correctly.
  
  I've even run into copy/paste problems with swing before -- some third part programs don't interact well.
9. Re:No! by Anonymous Coward · 2004-12-20 11:53 · Score: 0
  
  Errr, SWT uses native widgets -- that's the whole point to its existence. Also, the bog-standard AWT that has shipped with every Java runtime since 1995 uses native widgets - you don't even need complicated 3rd party libraries (ie, SWT) to get a totally native look and feel.
  
  Swing apps, when well developed, can look and perform well. But you don't have to use Swing at all. Use AWT for native widgets, and Swing for flexibility.
10. Re:No! by Anonymous Coward · 2004-12-20 12:33 · Score: 0
  
  It doesn't work so well for code that does asshole things like Class.forName("mypackage.myclass"); Also, it uses gnu classpath for its standard library, which is not yet complete. Also, some stuff like RMI had bugs in it last time I used it (makes sense, RMI uses reflection, and reflection wasn't implemented fully).
  
  Bottom line: if it works, use it. It doesn't always work.
11. Re:No! by ScrewMaster · 2004-12-20 12:49 · Score: 2, Insightful
  
  It's a poor craftsman who blames his tools.
  
  Absolutely true, and I can't tell you how many times I've heard otherwise-talented programmers blame their development environment for performance or stability issues. My attitude is usually something on the order of "Stop your bitching, get off your ass and deal with it."
  
  Conversely though, it is a good craftsman who picks the right tool for the job. Most languages can, to some degree, accomplish most tasks, just not necessarily well ... it's best to pick a language optimized for the task at hand. Or even parts of it: I've worked on many applications where I would use, say, C or assembler for time-critical or compute-bound modules, and something easier to work with for the GUI and file-management layers.
  
  What irritates me are programmers that learn a couple of languages and insist upon using them for everything, whether it's a good design choice or not.
  
  --
  The higher the technology, the sharper that two-edged sword.
12. Re:No! by xouumalperxe · 2004-12-20 13:16 · Score: 1
  
  AFAIK, java is no longer based on bytecodes, but rather JIT compilation. This means it CAN and WILL be slow as molasses in the winter when first starting up, but will probably be just as fast as your usual C program when running. The garbage collection bit could slow it down, but I don't think its impact is tremendows.
13. Re:No! by AusG4 · 2004-12-20 17:51 · Score: 1
  
  Your response is troll/flamebait at best, "clueless" at worst.
  
  Java GUI apps... go ahead, criticize java for not performing well in the context of a cross platform GUI app. All it needs to do is properly re-create an acceptable interface on every possible native GUI library. How hard can that possibly be?
  
  It's not like half the native GTK+ or QT apps aren't just as unusable, or that no serious GUI apps are written in Java anyways. You could write a GUI app with PHP and it's QT bindings, but why bother? Red herrings do not a point make.
  
  On the other hand, server side... the only thing that's slow about java is your understanding of it's progress since, well, 1997 or so, when you're comment may have been valid. Server-side java performance is about as good as PHP or .NET if you have half a clue of what you're doing.
  
  That said, I can write a pretty poor, slow-ass PHP app just as easily. So what's the point?
  
  As for Java not running well on all platforms... our company (and most others) have server side apps running on Debian, Solaris, OS X and Windows without issue.
  
  So I'd suggest that, in your case, problems likely exist between chair and keyboard.
  
  --
  bash-3.00$ uname -a
  SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
14. Re:No! by Taladar · 2004-12-20 20:08 · Score: 1
  
  It is the byte-code that gets interpreted or JIT-compiled. And I don't really see any reason to argue performance with Java as long as there are other problems (like compatibility between versions) that prevent use of Java to create interoperable apps that work in a year or more with the JRE that is current then (so other apps which need the new version can run in parallel)
  
  --
  Linux is not Windows
15. Re:No! by AusG4 · 2004-12-21 00:05 · Score: 1
  
  Of course, this is all because the new IO libraries are very thin wrappers around native routines.
  
  This is, of course, the point of Java.
  
  You say it like it's just Java "cheating" somehow.
  
  --
  bash-3.00$ uname -a
  SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
FreeBSD has it figured out by gtrubetskoy · 2004-12-20 09:24 · Score: 3, Interesting

Actually, each distro has its own little additions and, consequently, quirks. Writing an application to work reliably under all variations is not a slam-dunk.
IMHO, this is one great advantage that the FreeBSD project has - there are no "distros".
1. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 09:31 · Score: 0
  
  Isn't that pretty much the same as saying, "That's the thing I like about Gentoo, there are no distros?" FreeBSD, OpenBSD, and NetBSD are the equivalents to the Linux distro. BSD is the base for all of them, while the Linux kernel and a set of pretty standard GNU and non-GNU components form the base to most Linux distributions.
2. Re:FreeBSD has it figured out by dema · 2004-12-20 09:31 · Score: 1
  
  Wouldn't FreeBSD be considered a BSD distro? Like OpenBSD or NetBSD? Pardon me if that's inaccurate, I've never really used any BSD (unless OS X counts).
3. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 09:31 · Score: 0
  
  Except for Debian FreeBSD (http://www.debian.org/ports/kfreebsd-gnu/), OpenBSD (http://www.openbsd.org/), NetBSD (http://www.netbsd.org/), ....
4. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 09:33 · Score: 0
  
  Don't forget Darwin....
5. Re:FreeBSD has it figured out by The_Dougster · 2004-12-20 09:36 · Score: 3, Insightful
  
  What about Debian GNU/kFreeBSD? Isn't that the Debian distro of FreeBSD? Just because FreeBSD is still relatively obscure doesn't mean that its not going to end up in the same boat as Linux. Give it a couple more years.
  
  --
  Clickety Click ...
6. Re:FreeBSD has it figured out by gtrubetskoy · 2004-12-20 09:42 · Score: 1
  
  Isn't that pretty much the same as saying, "That's the thing I like about Gentoo, there are no distros?"
  No it wouldn't be, because Gentoo is not ultimately responsible for Linux kernel development or the GNU tools. In FreeBSD, the same entity is responsible for (and owns the copyright to) both kernel and userland, whereas in Linux, kernel, userland and packaging and distribution of either is controlled by different entities.
7. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 09:45 · Score: 0
  
  What about Debian GNU/kFreeBSD? Isn't that the Debian distro of FreeBSD?
  It's not a distribution officially supported by the FreeBSD Foundation.
8. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 09:48 · Score: 0
  
  That's not really accurate -- Free, Open and NetBSD are different kernels, not just different distributions of the same core. And OS X (despite the insistence of Slashbots that it's somehow a rebadged FreeBSD) has a completely different kernel that goes back to the original Berkeley BSD.
9. Re:FreeBSD has it figured out by FooBarWidget · 2004-12-20 10:08 · Score: 1
  
  Doesn't FreeBSD use large parts of the GNU toolchain?
10. Re:FreeBSD has it figured out by Jeff+DeMaagd · 2004-12-20 10:11 · Score: 1
  
  I'm not getting how that is any different than Linux, where no distribution is officially supported by any other.
11. Re:FreeBSD has it figured out by FooBarWidget · 2004-12-20 10:14 · Score: 1
  
  And Slackware is not a distribution officially supported by Red Hat.
12. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 10:18 · Score: 0
  
  I'm not getting how that is any different than Linux, where no distribution is officially supported by any other.
  It's different in that the FreeBSD Foundation officially maintains and distributes a "distribution" (if you will) called FreeBSD (and no other). FreeBSD includes the kernel, _as well as_ all the commands (like ls, grep, mount, etc). Think of Linus Torvalds maintaining not just the kernel, but a complete Linux system - that'd be the FreeBSD model.
13. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 10:21 · Score: 0
  
  Doesn't FreeBSD use large parts of the GNU toolchain?
  AFAIK it does not use any of the GNU tools except that the recommended compiler is gcc (but it's not linked against glibc either).
14. Re:FreeBSD has it figured out by runderwo · 2004-12-20 10:37 · Score: 1
  
  IMHO, this is one great advantage that the FreeBSD project has - there are no "distros".
  Uh, ok. Slackware Linux has the same advantage - there are no "distros" of Slackware Linux. Or are you implying that FreeBSD is not a distribution of 4.4BSD like OpenBSD and NetBSD? How about Dragonfly BSD, doesn't that count as a distro of FreeBSD?
  
  --
  LRC, the best-read libertarian site on the web
15. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 10:41 · Score: 0
  
  Mod parent up, please!
16. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 10:48 · Score: 0
  
  I still dont see the diference. Aren't Gentoo/RedHat/Fedora/SuSe using different kernels with their own subset patches ? Free/Open/Net share a lot of parts of their kernels too, from the user point of view they are accutaly all the same.
17. Re:FreeBSD has it figured out by hunterx11 · 2004-12-20 11:02 · Score: 1
  
  XNU, the OS X kernel, is actually based more on Mach.
  
  --
  English is easier said than done.
18. Re:FreeBSD has it figured out by Pseudonym · 2004-12-20 11:02 · Score: 1
  
  IMHO, this is one great advantage that the FreeBSD project has - there are no "distros".
  
  Excellent! That means it's obvious who to sue.
  
  Yours sincerely,
  SCO Attack Lawyer Drone #23
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
19. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 11:06 · Score: 0
  
  So Debian GNU/Linux and Debian GNU/kFreeBSD are two different operating systems because they don't have the same kernel where as Debian GNU/Linux and Gentoo Linux are two distributions of the same operating system as they use the same kernel. :)
  
  I think the term "distribution" assiociated with Linux is more related to what people says than for "technical" reasons. Yes, you have your "distributor" that packages the software for you. But you have also that for the BSD and, to some extent, with Apple's Mac OS X (since Apple distributes Apache, gcc, etc. with OS X though lot less flexible for components that gets installed/upgraded).
  
  Because people using FreeBSD, OpenBSD and NetBSD say when asked about what is their OS: FreeBSD etc. rather than a BSD distribution. People call these OSes. Where as users of OSes with a Linux kernel tends to say, "I am using Linux" rather than "I am using Gentoo".
  
  Usually, I prefer to say "Gentoo" is the OS rather than Linux because then everythings come "clear" to an outsider.
  
  Why software installed differently on Debian and Gentoo? Answer: Because they are different OSes. :)
20. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-20 11:20 · Score: 0
  
  What about Mac OS X?
  
  It uses the Mach kernel and a BSD userland and the GNU tools (gcc and make). At every releases, Apple takes the latest BSD utilities and GNU compilers. Put everything together.
  
  So Mac OS X is a Mach distro?
  
  (There are actually at least two OSes that could be called Gentoo distros. The original one known as Gentoo Linux and VidaLinux which is based on a Gentoo system.)
21. Re:FreeBSD has it figured out by Chandon+Seldon · 2004-12-20 12:02 · Score: 2, Interesting
  
  I'd write this as "BSD forks need to maintain their own kernel", which sounds more like a disadvantage, but I don't think it's really relevent.
  
  Let's talk about "Desktop Distros of Unix" for a second. We have the following major players:
  
  Solaris, FreeBSD, OpenBSD, NetBSD, Debian GNU/Linux, Slackware Linux, RedHat/Fedora Linux, Mac OS X, (many others)
  
  Then there's non-unix desktop systems:
  Windows
  
  Now, for some odd reason Windows has the majority of desktop market share even though almost every other system out there is Unix based and mostly-compatible.
  
  Here's the trick: Everything (meaningful) other than Windows that might be on the desktop is Unix. If we can make the Unixes compatible enough, then application developers can target two platforms and get everyone. Targetting 2 platforms for 90% and 9% is fine. Targetting 7 platforms for 90% 4% 2.5% 1% 0.7% 0.5% and 0.3% isn't the plan.
  
  Moving towards two (or three) different target platforms for desktop applications is worthwhile, and (like it or not) FreeBSD is the same platform as Linux and will be helped by any LSB efforts (and should contribute to and comply with them if possible).
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
22. Re:FreeBSD has it figured out by Chandon+Seldon · 2004-12-20 12:06 · Score: 1
  
  To make my point a bit clearer, there's a bunch of different application-but-not-driver compatible "Windows Distributions".
  
  Saying (FreeBSD, Debian GNU/Linux) are a group the same as (Windows XP, Windows 98) are a group is meaningful:
  FreeBSD and Debian can run the same binaries but need different drivers - the same as Windows XP vs. 98.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
23. Re:FreeBSD has it figured out by Billly+Gates · 2004-12-20 13:36 · Score: 1
  
  FreeBSD puts older versions of libraries api's and shell tools under the /compat directories.
  
  I think Solaris does this too but I am not too sure. Correct me if I am wrong.
  
  I tried compiling and running older software like gldoom with no luck under FreeBSD. But after using the sh from /compat/version X it worked fine withot a sweat.
  
  Windows includes older Dlls and the OS links to the proper ones when it detects its an older program. Linux should do something similiar.
  
  --
  http://saveie6.com/
24. Re:FreeBSD has it figured out by Tuross · 2004-12-20 15:15 · Score: 1
  
  Windows includes older Dlls and the OS links to the proper ones when it detects its an older program. Linux should do something similiar.
  
  Where do you think M$ Windows stole this idea from?
  
  Library sonames dictate what library to link against. When you break the ABI, you change the soname (aka increment the version number) and older apps will happily stay linked against the older libraries and still work.
  
  With open source software you can even recompile against the new libraries, solving the case where the executable format changes (eg, aout to ELF)
  --
  Matt
  
  Read Slashdot
  
  ???
  
  Profit
25. Re:FreeBSD has it figured out by Billly+Gates · 2004-12-21 00:34 · Score: 1
  
  I am talking about corporate software which is binary only and the fact that joe six pack does not want to recompile programs or frankly needs too.
  
  Oracle hates Linux besides RedHat Enterprise edition for that reason. They want it like a traditional unix of binary only code on cd-rom.
  
  My guess is redhat may just do this in the future to enable older software to run on Redhat Advanced Server or Enterpisde edition to keep corporate software makers happy.
  
  --
  http://saveie6.com/
26. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-21 00:47 · Score: 0
  
  Of course Linus maintains his own complete Linux system. He needs one to get work done. And of what consequence is that?
  
  All of the projects mentioned have one thing in common, the GNU toolchain. That fact isn't something you have to like, but it remains true anyway. So we could just see them all as different vectors for the GNU toolchain (or perhaps for Perl, if they all ship Perl). But I'm guessing that view makes your blood boil for some reason...
  
  Any arbitrary group can invent some spurious criteria on which they should be judged the One True Way as you've attempted here. The trouble is that it doesn't tell us anything except that you desperately want to be special.
  
  The FreeBSD Foundation make a whole bunch of more or less source compatible operating systems for different architectures, some of which are "official" in some way. So what? Red Hat makes a whole bunch of more or less source compatible operating systems for different architectures which are also "official" but this time in the sense that they bring in millions of dollars of revenue. Claiming that FreeBSD is better because it's intentionally more incompatible with every other system is bizarre.
  
  Do you know how many people have gone off to fork the Linux kernel (as the BSDs did their entire systems) with the genuine open-hearted intention of making an entirely new independent OS with no "distributions" ? Countless. Why didn't the users follow them? Because "We're incompatible. Look how much stuff doesn't work!" is not a selling point, not to suits, not to engineers, and not even to the people who really want to run NetBSD on their wristwatches.
27. Re:FreeBSD has it figured out by grahammm · 2004-12-21 01:54 · Score: 1
  
  And you also use symbol versioning within the library, so that libxyz.so.2 version 2.3.4 might contain foo()@2.0.0, foo()@2.2.1 and foo()@2.3.4 so that applications which are built against older libxyz versions will still run with the latest libxyz.so library. Yes, I know that this is not perfect, such as when an application has been linked with a static library which uses an older version of a versioned symbol (as the symbol version information is lost)
28. Re:FreeBSD has it figured out by Anonymous Coward · 2004-12-21 03:17 · Score: 0
  
  Because people using FreeBSD, OpenBSD and NetBSD say when asked about what is their OS: FreeBSD etc. rather than a BSD distribution.
  FreeBSD, OpenBSD and NetBSD have very little in common amongst themselves as well as the original BSD. By this token, Linux should also be called a BSD distribution, since it probably borrows as much from BSD as any other *BSD.
Do I use urpmi, APT-GET or YaST to get the doc? by filesiteguy · 2004-12-20 09:24 · Score: 2, Interesting

The problem I see here is that there is a group trying to put together a "standard" for writing to "Linux". However, what is Linux? Is it the Kernel that Linus keeps? Is it the CLI that runs many server apps? Is it the GUI that I run at home?

I think, until a Steve Jobs or Bill Gates comes out with a killer apps with a corresponding toolkit that takes over the market, we'll be stuck in the same boat.

--
The Kai's Semi-Updated Website Thingy
1. Re:Do I use urpmi, APT-GET or YaST to get the doc? by Chandon+Seldon · 2004-12-20 12:46 · Score: 1
  
  You're seeing a problem that doesn't really exist. "Linux" in this context is a unix-like operating system. Period.
  
  If you're writing a non-desktop app, writing to a unix like operationg system is pretty well covered. Everyone who cares knows the story - it's the same story it's been for a while.
  
  Unix desktops are a little bit less well understood, but they're still pretty simple. There are various different development toolkits and stuff, but it doesn't really matter. It'll take you a couple hours to figure this stuff out as a developer, but that's not a big problem and it's all transparent to the user anyway.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
Not really. by Doc+Ruby · 2004-12-20 09:24 · Score: 1

Java solves the problem of cross-platform apps at the granularity of CPU/OS-API. The JVM doesn't solve problems of different Linux distros, because they all share the same OS API. If you're running the same binary across different CPU architectures, even the same distro won't run x86 binaries on PowerPC. And if you're recompiling from source for different CPU architectures, Java doesn't do anything at runtime that gcc doesn't do at build time. Java is a solution to a more fragmented platform, like "web servers", than we have with Linux.

--
--
make install -not war
TrollMod by Doc+Ruby · 2004-12-20 09:27 · Score: 0, Offtopic

Moderation +1
70% Funny
30% Offtopic

How the hell is a joke about "extract from book" in a book review thread "Offtopic"?

--
--
make install -not war
What we need--installation/uninstallation API by bonch · 2004-12-20 09:33 · Score: 0, Insightful

I am firmly convinced that Linux on the desktop will not break out of its niche until a binary installation/uninstallation API is developed that allows normal software developers like Adobe and Macromedia to write installers for their software. All you'd have to do is pop in a CD, autoplay would start, the thing would install, stick items into the "start menu" of the desktop environment, and provide an uninstall icon.

The API should remain sane so that you could install something from four years ago and still have it work. I can still run Windows 3.1 and 95 applications on my XP laptop. Try running a Linux binary from two years ago.

To really go all the way, there needs to be a unified framework, probably based on something like Mono, facilitating a desktop foundation and hopefully replacing X.org (Y-Windows looks promising if it would ever take off). That way, GNOME and KDE could just be seperate shells on top of the same desktop, and they would happily run each other's apps.

I know what you're thinking--GNOME can already run my KDE apps and vice versa! No, what's happening is all those massive KDE libraries get loaded into memory when you run that KDE app. You have to install two entire huge desktop environments just to run all the apps you need. It's ridiculous. If there was a standardized library and GUI framework, this could have been avoided. But the obsession with "choice" when these projects were began has splintered the effort.

First things first--give me a binary installation/uninstallation API. A real API like the non-amateur desktops have, not some package manager built out of shell scripts. I'd also request a kernel driver API that unties them from the kernel--recompiling an entire kernel to support a new scanner I just bought is ridiculous. I should just be able to go online and download a special binary driver, or, better yet--using the binary installation/uninstallation API, just pop in a CD in my desktop environment and have it do it for me.

One can dream...
1. Re:What we need--installation/uninstallation API by Kjella · 2004-12-20 09:51 · Score: 1
  
  Well, the real issue with an installation API is that 99% of linux packages actually relies on some other package. For the last 1%, I don't think it should be that hard to make a simple API translater, where you'd put basic strings like "Program name", "Category" , small icon, large icon etc. etc. and translate it into distro-specific values.
  
  But of those 1%, about 0% of the community-based programs are like that. The 1% is almost purely commercial and/or closed source apps. So why should anyone bother? For anything the volunteers do, they mostly need to integrate with the dependency system. And that can't be trivially merged.
  
  Kjella
  
  --
  Live today, because you never know what tomorrow brings
2. Re:What we need--installation/uninstallation API by bonch · 2004-12-20 09:55 · Score: 0
  
  The 1% is almost purely commercial and/or closed source apps.
  
  Those would be companies like Adobe. Presumably, they would provide their own libraries or compile them in directly.
  
  Windows XP does it by letting apps provide DLLs if they want to, and if a DLL conflicts with one already installed on the system, versioning is used so the apps only use the DLL that belongs to them. Surely there is something we could develop for Linux. I've love to use a version of Dreamweaver MX under a Gnome "shell" on top of the unified desktop.
3. Re:What we need--installation/uninstallation API by Xabraxas · 2004-12-20 10:16 · Score: 3, Interesting
  
  Try running a Linux binary from two years ago.
  While this is true there are programs that ran on 98 that don't run on XP. If they don't make a newer version of the program you are SOL. With OSS you just recompile, which is relatively painless for small applications. Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
  That way, GNOME and KDE could just be seperate shells on top of the same desktop, and they would happily run each other's apps.
  That seems pointless to me. Why wouldn't you just make one shell with all the options of GNOME and KDE? It seems like after you got everything to work as one DE with different shells, you would only be one small step away from merging them completely into one.
  I do think GNOME and KDE should integrate as much as they can to keep things compatible and consistent BUT it's good to have two seperate environments, especially since they seem to aim at different crowds. Also, competition is a good thing.
  I'd also request a kernel driver API that unties them from the kernel--recompiling an entire kernel to support a new scanner I just bought is ridiculous. I should just be able to go online and download a special binary driver
  I'm confused by this. You don't need to recompile your kernel to include a new driver. You can build modules without rebuilding the entire kernel. Also I build the madwifi-driver, which is partially proprietary and outside of the kernel, without having to recompile the kernel.
  
  --
  Time makes more converts than reason
4. Re:What we need--installation/uninstallation API by sloanster · 2004-12-20 10:16 · Score: 2, Informative
  
  The API should remain sane so that you could install something from four years ago and still have it work. I can still run Windows 3.1 and 95 applications on my XP laptop. Try running a Linux binary from two years ago.
  
  You're FUDDing about the linux binary API, as I can install the quake 3 arena from 1999 (which I originally ran on redhat 5.2) on my suse 9.2 and it runs perfectly.
  
  As to your windows backwards compatibility, you lose points for dishonesty. I know of quite a few w95/w98 apps that simply crash and burn on 2k/xp - and you claim all windows 3.1 apps run fine on xp?
  
  I call bullshit.
5. Re:What we need--installation/uninstallation API by Chandon+Seldon · 2004-12-20 11:00 · Score: 1
  
  Right now you can install and uninstall binary software on Linux (pretty much any Linux) with no significant problems if that software has been packaged with the Loki Installer.
  
  Somewhere around here I have Loki's Myth II for Linux CD from some time last century, and I'd bet that if I tried to install that now it would work fine, and if it didn't work it would be because I don't have the 5 year old C library compatibility package installed. Note that I'm not the least bit worried about what distro I'm running - even though I'm not running Red Hat, or even an RPM based distro.
  
  RealPlayer 10 is another example of packaged binary Linux software that Just Works(tm).
  
  In conclusion, as long as the software was packaged for the current version of libc, it should work fine, libc has only changed twice since I started using Linux back with Kernel 2.0, and most if not all major distros have compatibility packages to solve even that issue.
  
  If you want to complain about the Libc issue, try running the following programs under Windows XP SP 2:
  Warcraft I
  Star Wars: Dark Forces
  Adobe Live Motion 1
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
6. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-20 11:01 · Score: 0
  
  Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
  
  Do you think Adobe's gonna let you recompile an old version of Photoshop?
7. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-20 11:04 · Score: 0
  
  You're FUDDing about the linux binary API, as I can install the quake 3 arena from 1999 (which I originally ran on redhat 5.2) on my suse 9.2 and it runs perfectly.
  
  Try an old version of Gimp and get back to me. I'm thinking in terms of the release cycle of a company like Macromedia. I can still run Photoshop 5 just fine on Windows, with no recompile. There's no "FUDDing" going on. It's well known that APIs do change between major versions. Have you never had to recompile an app after a new libc?
  
  As to your windows backwards compatibility, you lose points for dishonesty. I know of quite a few w95/w98 apps that simply crash and burn on 2k/xp - and you claim all windows 3.1 apps run fine on xp?
  
  I never claimed "all" apps run fine. But a ton do. Just because you know of a "few" pretty much proves that it's only a few. Yeah, if you run Norton Antivirus 98, you're going to have problems. I find it interesting you don't actually name any of these mysterious apps. XP even provided a compatibility mode for older applications.
8. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-20 11:10 · Score: 0
  
  Warcraft I
  
  It's a DOS application, not a Windows app.
  
  Star Wars: Dark Forces
  
  It's a DOS application, not a Windows app.
  
  Adobe Live Motion 1
  
  Ah, a Windows app. This app has already been made to work under SP2.
  
  Try running a Gimp 1.0 RPM and get back to me.
9. Re:What we need--installation/uninstallation API by be-fan · 2004-12-20 12:40 · Score: 1
  
  That's really not an even comparison. Binary versions of the GIMP aren't designed to run on any distro but the one it was compiled for. Quake 3, like Flash or Photoshop on Windows, are designed to run on a variety of OS versions. Linux could easily have Windows-like binary compatibility. Apps, like Windows apps, would have to be distributed with all their dependencies. But given that 99% of Linux software is open source, why deal with the bloat that comes along with such a model, when you can simply download packages targetted for your distribution?
  
  --
  A deep unwavering belief is a sure sign you're missing something...
10. Re:What we need--installation/uninstallation API by Chandon+Seldon · 2004-12-20 12:53 · Score: 1
  
  It's a DOS application, not a Windows app.
  
  They're both major games that were released targetting computers with Windows on them. Expecting these to work on the current version of Windows is *exactly* as appropriate as expecting software from the same period for Linux to run on a current version of Linux - and with Linux you can get that stuff to run usually just by installing a compatibility package.
  
  If Live Motion 1 works on XP SP2 it's through some sort of downloadable fix/hotpatch - equivilent in annoyance to installing an "old libc compatibility package".
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
11. Re:What we need--installation/uninstallation API by xouumalperxe · 2004-12-20 13:14 · Score: 1
  
  I was under the impression that the linux kernel having all the drivers tied in was actually a conscious option, based on the idea that they wouldn't have to keep support for obsolete APIs, thus preventing some of the flaky windows drivers we get. Plus, you don't actually HAVE to recompile the kernel. Just compile it once with EVERYTHING as modules. Then modprobe for what you want :) (or perhaps there is some intrinsic limitation to this that I'm not aware of?)
12. Re:What we need--installation/uninstallation API by Billly+Gates · 2004-12-20 13:34 · Score: 1
  
  Give it a shot.
  
  I guarantee you money it wont work.
  
  I gave up trying to run quak3.
  
  Libc changes, api changes, script changes, binary incompatiblities persist. I can run old Windows apps but one program compiled even for the same Linux distro like redhat wont work in later versions.
  
  Its lightyears behind Windows, Solaris, and MacOSX>
  
  --
  http://saveie6.com/
13. Re:What we need--installation/uninstallation API by xouumalperxe · 2004-12-20 13:59 · Score: 1
  
  XP even provided a compatibility mode for older applications. Which was so generous of them. And efficient as well. I'd say under 20% of all apps/games I've tried to run under compatibility ever ran.
14. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-20 14:18 · Score: 0
  
  A significant number of a Windows app's dependencies ship on the Windows CD.
15. Re:What we need--installation/uninstallation API by grumbel · 2004-12-20 15:26 · Score: 1
  
  ### Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
  
  Yes, there is always a way to get it work somehow, however that is often WAY bejoint that what a normal user can do. Compiling something like a older version of Gnome or so is a hell of a task, since all its dependencies have moved on two and you have to do some good digging in the historie books and what you need and where you can still get it. Doesn't sound usefull? Well, thats exactly what I would have liked todo a few years ago when Gnome2 came out and the distro switched to that, wanted to get my Gnome1.4 back, however there was no way getting that back without a heapload of manual work. When LSB would have been more widespread back then it wouldn't have been a problem in the first place, since I just could have /opt/lsb-gnome-1.4 and a /opt/lsb-gnome-2.0 installed in parallel without much problem, however that wasn't available back then and still isn't, but at least the direction in which LSB goes is correct.
16. Re:What we need--installation/uninstallation API by Xabraxas · 2004-12-20 15:53 · Score: 1
  
  Yes, there is always a way to get it work somehow, however that is often WAY bejoint that what a normal user can do.
  True, but if there is a demand someone will surely modify the source and package it up for you. At least this is possible.
  
  --
  Time makes more converts than reason
17. Re:What we need--installation/uninstallation API by Jay+Carlson · 2004-12-20 16:58 · Score: 1
  
  Try running a Linux binary from two years ago.
  
  I run Debian stable, you insensitive clod!
18. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-20 19:19 · Score: 0
  
  You can build modules without rebuilding the entire kernel.
  
  Yes, sometimes, yes. But this is far far too difficult for average user to do.
  
  Not to mention getting it installed. I just installed Epson scanner into FC2 and it was huge pain. The reason is 99% because Linux USB (hotplug) "just sucks".
  
  Not to mention that Mr. Torvalds insist on non-binary drivers (insane).
19. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-20 22:20 · Score: 0
  
  I want to be able to go to a manufacturer's website, run their installer, and suddenly have my driver installed thanks to a unified API.
  I'm sorry, but I've do this all the time. Today it was a Yukon Gigabit card on a 2.4.21 kernel (newer kernels support it natively). I was able to go to their site, run their installer, and suddenly have my driver installed. What's your problem?
20. Re:What we need--installation/uninstallation API by tuffy · 2004-12-21 01:49 · Score: 1
  
  Give it a shot.
  I guarantee you money it wont work.
  I gave up trying to run quak3.
  
  Quake3 works just fine, right now, on Fedora 3 for x86-64. As does Return to Castle Wolfenstein based on the same engine. I played both of them yesterday. The only thing one needs to do is use the "setarch" program to trick the installer script into thinking the architecture is i386 so it won't get angry.
  Both games come with their own C libraries and are, for all intents and purposes, statically compiled. That being the case, there's no reason why they won't run for years and years to come.
  
  --
  Ita erat quando hic adveni.
21. Re:What we need--installation/uninstallation API by Anonymous Coward · 2004-12-21 14:30 · Score: 0
  
  I want to be able to go to a manufacturer's website, run their installer, and suddenly have my driver installed thanks to a unified API.
  
  I prefer to go to a manufacturer's website and simply download the driver to the "Extensions" folder, and suddenly have my driver installed thanks to the Mac. I don't like installers. It might install something I don't want installed. Dynamic links are nice when space is tight, but these days I'm not too worried about disk space, so I tend to stick with static. On a Windows machine I look for programs that don't require installation a la Mozilla.
22. Re:What we need--installation/uninstallation API by Xabraxas · 2004-12-22 13:04 · Score: 1
  
  Yes, sometimes, yes. But this is far far too difficult for average user to do.
  make modules modules_install
  Now was that really that hard?
  Not to mention getting it installed. I just installed Epson scanner into FC2 and it was huge pain. The reason is 99% because Linux USB (hotplug) "just sucks".
  Are you using udev? It's been a breeze for me. My usb key shows up as a consisten device node now.
  Not to mention that Mr. Torvalds insist on non-binary drivers (insane).
  You might want to take a look at the GPL.
  
  --
  Time makes more converts than reason
Oh reeeally.. by Anonymous Coward · 2004-12-20 09:37 · Score: 3, Interesting

Writing an application to work reliably under all variations is not a slam-dunk.

So it turns out that Microsoft's mutant penguin ad compaign was right all along?

For the past few years, I've been screaming about the negative effects of having so many different standards to choose from on Linux - this is why I personally use FreeBSD and OSX (well, okay, and Windows for games).

But the biggest problem (which also exists on FreeBSD), is QT. The shitty licence has caused so much damage by keeping cross-platform and commercial development off KDE (one of the most popular window managers). I know there's GTK, but I can't help think that Linux might have reached critical mass and become mainstream popular without it - GTK might not be perfect, but it is a STANDARD.

Monkey man Steve Balmer might have looked silly when he yelled it on stage, but he was right: "Developers, developers, developers." The Linux community should be bending over backwards to attract new developers into their flock, by making their passage into the fold as easy and as hassle-free as possible.

Chicken and the egg: applications for Linux, users for Linux. The Linux community can't force people to use Linux for the sake of using Linux, but they can bring applications to the platform - if they're worth using, users will follow.
1. Re:Oh reeeally.. by sboss · 2004-12-20 09:49 · Score: 1
  
  This was one of the more intelligent posts I have seen on SlashDot in a while. Thank you.
  
  Scott
  
  --
  Scott
  janitor
  sdn website family
  email: scott at sboss dot net
2. Re:Oh reeeally.. by Anonymous Coward · 2004-12-20 10:44 · Score: 0
  
  This was one of the more intelligent posts I have seen on SlashDot in a while. Thank you.
  MOD GP DOWN!!! ;)
3. Re:Oh reeeally.. by Chandon+Seldon · 2004-12-20 12:38 · Score: 1
  
  Developing for Linux isn't bad. Depending on how you look at it, it's as easy/easier than developing for Windows.
  
  The development environment is standard with some distros and easily installed for others. There are cross platform GUI toolkits that work excellently and have good documentation (wxWindows and GTK).
  
  The only real problem I see here is that for an experianced Windows programmer it's hard to quickly see which development tools are "real". My easy suggestion would be: If in doubt, target Gnome. Another good plan is wxWindows.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
4. Re:Oh reeeally.. by TheCoroner · 2004-12-20 13:28 · Score: 1
  
  Actually as of QT 2.2 it is GPL. See http://developer.kde.org/documentation/books/kde-2 .0-development/ch19lev1sec4.html
5. Re:Oh reeeally.. by Taladar · 2004-12-20 21:12 · Score: 1
  
  If in doubt don't ever target Gnome or KDE directly. You will lose the other half. It is much better to target GTK than to target Gnome.
  
  --
  Linux is not Windows
6. Re:Oh reeeally.. by Chandon+Seldon · 2004-12-21 00:46 · Score: 1
  
  I haven't really seen a desktop Linux system that doesn't have both the Gnome and KDE libraries installed - and given that there's no reason why a KDE app doesn't run fine on Gnome and the reverse.
  
  --
  -- The act of censorship is always worse than whatever is being censored. Always.
7. Re:Oh reeeally.. by Anonymous Coward · 2004-12-21 04:00 · Score: 0
  
  And, uh, have you never had an application that runs on say, Windows 95, but not XP? Or perhaps Windows 98, but not NT? I've seen just as much, if not MORE incompatible apps between versions of windows than I have on Linux distros. Hell, I have boatloads of games that work only on Window 95, some on Win95 and Win98, some on Win98 only, etc., etc., etc. I think a Mutant Windows Butterfly campaign is in order...:-)
  
  Hell, that's the whole idea, by M$ et al., force upgrades...Does this sound at all familiar: "I'm sorry, you'll have to upgrade to Windows xx to run that new version of that app you've been using for years..." or the opposite ploy: "I'm sorry, you'll have to upgrade to version xx of App xx to run that on Windows XP...".
LSB , there can be only one by Anonymous Coward · 2004-12-20 09:38 · Score: 0

Basically LSB is a set of rules that some group came up with to try to make "the one" distro. LSB takes away the differences and uniqueness of distros and makes them all the same. I don't see this ever working nor good for Linux. Why don't they just call it Redhat Standards Base, as if all distros followed LSB they would all be Redhat. Who wants that?
1. Re:LSB , there can be only one by The_Dougster · 2004-12-20 14:21 · Score: 1
  
  No that's definately not the idea behind LSB. I attended a Debian conference a couple years ago where they were talking about it, and to be LSB compliant, a system just has to meet certain baseline criteria and provide some utilities. Essentially, it has to be able to install and uninstall a LSB rpm format package. How this is accomplished is up to the distro to implement. I think Debian has an LSB package which installs some libs and stuff here and there and makes sure you have rpm installed. LSB packages will never supercede debs and Debian doesn't plan on leaving dpkg and apt for the main package management; however, if you install the LSB compatibility metapackage then you have the ability to also use these type of packages. If you ever want to see high end apps like CAD and drafting programs available for Linux, then something like LSB is needed to ensure that the vendor can provide one binary for all compliant Linux systems and it will just work. Thats all LSB is supposed to be.
  
  --
  Clickety Click ...
Don't hardcode paths by Anonymous Coward · 2004-12-20 09:39 · Score: 0

Don't assume your config file is /etc/thisapp.conf, don't assume your data is in /var/spool/thisapp.
Make it all configurable.
1. Re:Don't hardcode paths by MightyMartian · 2004-12-20 09:59 · Score: 1, Insightful
  
  > Don't assume your config file is /etc/thisapp.conf, don't
  > assume your data is in /var/spool/thisapp.
  > Make it all configurable.
  
  I don't know why anyone would put system-wide configuration data anywhere else but in /etc. I mean, I've been working around *nix for going on fourteen years now, and that was always supposed to be the place.
  
  The only real solution to this is to make options for loading critical config data from environment, but that also seems so kludgy when compared with a proper file.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
2. Re:Don't hardcode paths by Anonymous Coward · 2004-12-20 10:16 · Score: 0
  
  What about /usr/local/etc?
  That's a standard too.
3. Re:Don't hardcode paths by barawn · 2004-12-20 10:23 · Score: 2, Insightful
  
  I don't know why anyone would put system-wide configuration data anywhere else but in /etc. I mean, I've been working around *nix for going on fourteen years now, and that was always supposed to be the place.
  
  Yah, but that's not what he's alluding to. What about /etc/thisapp/thisapp.conf instead of /etc/thisapp.conf (which pollutes /etc rather quickly)?
  
  Hence, make it all configurable. Then you don't have to worry.
4. Re:Don't hardcode paths by grumbel · 2004-12-20 15:16 · Score: 1
  
  ### I don't know why anyone would put system-wide configuration data anywhere else but in /etc. I mean,
  
  Because you might want to have two different versions or two different instances of the same programm and don't want them to share the same config file. Everytime that happens you basically have two choices a) throw the binary away and recompile everything from source and b) use a hex-editor and fix the path to the config and the rest, both of course work, however neither of one that I would consider a 'good solution'.
5. Re:Don't hardcode paths by grumbel · 2004-12-20 15:19 · Score: 1
  
  The throuble is, where do you want to configure it? If you have no /etc/thisapp.conf you are already in deep throuble. The throuble is really that Linux or Unix in general doesn't provide much of a standard way to configure a binary, stucking stuff into /etc/ and crossing the fingers that you don't run into a version conflict with another version of the same software isn't exactly a clean solution.
  
  So far there isn't even a standard way to locate the data that the binary needs, so most app still hardcode that. /proc/self/exe might help here, since that tells you at least the location of your binary, however that is something that I found more or less by luck, not really sure if thats save to use for that purpose.
6. Re:Don't hardcode paths by Anonymous Coward · 2004-12-20 21:02 · Score: 0
  
  Doesn't that rather pollute /etc directories rather than files, now? A net benefit of bugger all, as far as I can tell.
  
  Use thisapp directories where you need more than one file to config. May be better to use /etc/thisapp.config to say where the other files should be found..?
7. Re:Don't hardcode paths by Taladar · 2004-12-20 21:23 · Score: 1
  
  Or you could just use the commandline options for another config file path (usually -c)
  
  --
  Linux is not Windows
8. Re:Don't hardcode paths by Anonymous Coward · 2004-12-21 01:35 · Score: 0
  
  Something ought to be said here about the utter stupidity of /etc being named "etc".
  
  I mean, what kind of a name is that? "Et cetera". Who in their right mind (e.g. not Unix-savvy ;-) ) would think that there was anything important in a directory named 'etc'?
  
  Personally.. I'd like to see LSB endorse more rational directory names. Three-letter names don't give any noticable advantage anymore. Rename "tmp" "Temporary" or "Temporary Files" even. "etc" should be "System Settings" or something, "dev" "devices" and so on.
  
  Backwards compatibility? How about symlinks?
9. Re:Don't hardcode paths by Taladar · 2004-12-21 01:50 · Score: 1
  
  And what does Windows provide?
  
  The Registry? A bloated filesystem-like addon with lots and lots of keys of which nobody knows the purpose AND suffering from the same problems you describe (problems with two parallel versions of the same app and no clue where the config info for any given app is located if you are not the author).
  
  Perhaps you should propose a solution for this (without a global unique-name-giving authority)
  
  --
  Linux is not Windows
10. Re:Don't hardcode paths by grumbel · 2004-12-21 06:54 · Score: 1
  
  Yep, leads however to several uglynesses. Since command-line options are pretty dynamic, one needs to write them down somewhere, which in turn leads than to Wrapper scripts, which then require renaming of the real binary (foo -> foo.real), which in turn makes 'ps aux', 'gdb', 'killall' and a bunch of other things more difficult to use, since you always have to lookup the real name of the binary first. Overall probally the best solution today, however still not really optimal.
  
  What I would like would be EA (extended records) on the binary file itself which carry the necesarry start-up config filename, the access to the records could go via the /proc/self/exe Symlinks and if those EAs are relative they might even survive basic moving around in the filesystem. However EAs are as far as I know still not available on all major filesystems or only with patches, so it wouldn't work much good today.
11. Re:Don't hardcode paths by grumbel · 2004-12-21 06:59 · Score: 1
  
  ### And what does Windows provide?
  
  Windows doesn't spread an installed application all over the filesystem but keeps them in their local directory. That said, the registry still contains a whole bunch of redundant information which makes moving applications difficult. However moving basic application in Windows around is pretty doable. Last not least, this in not only about moving them, but installing them in a different location in the first place. Say installing a RPM/DEB in the users homedir, on Windows that is no problem, since basically all applications can be installed wherever you like, under Linux its basically impossible with a binary (hex-editor tricks asside).
12. Re:Don't hardcode paths by Anonymous Coward · 2004-12-21 12:42 · Score: 0
  
  Guys, ever hear of a little thing called a command line parameter, or an environment variable? These are good enough to boot strap you to the main configuration file. Even if you think they're "ugly", there's nothing stopping you from creating a hardcoded default configuration file location; the point is that you shouldn't make it impossible to change without recompiling.
15% of the server market - mainstream to me. by khasim · 2004-12-20 09:39 · Score: 1

Linux has approximately 15% of the server market in 2003. And it just keeps growing. That sounds pretty mainstream to me.

http://asia.cnet.com/news/systems/0,39037054,39207 175,00.htm
look how these apps are built by Anonymous Coward · 2004-12-20 09:49 · Score: 0

OpenOffice, or Mozilla, just unpack and install, works on all Linux distros, although distros do rebuild em for their specific distro you can still get the packages from the distributer of the app, thats how i get mozilla & firefox & thunderbird, and OpenOffice, RealPlayer/HelixPlayer too is looking much better than before...

MPlayer is very nice now and with the essential codec pack plays anything i want...
1. Re:look how these apps are built by MightyMartian · 2004-12-20 10:06 · Score: 1
  
  > OpenOffice, or Mozilla, just unpack and install, works on all Linux distros,
  > although distros do rebuild em for their specific distro you can still get
  > the packages from the distributer of the app, thats how i get mozilla &
  > firefox & thunderbird, and OpenOffice, RealPlayer/HelixPlayer
  > too is looking much better than before...
  
  I haven't looked at the code of these projects, but I'm assuming there's probably a lot of redundancy, shipping their own versions of libraries so as to eliminate any major problems. That's certainly one way to do it, though it probably adds considerable bloat to an install, and if there is carried over to a wide array of software, it could mean Linux becomes pretty bloated.
  
  Looking at the Micro$oft way, with lots of memory and lots of HD space, bad and redundant coding ain't a problem. However, I work with rather trim and streamlined Linux-based routers (the kind of stuff that fits on 128mb flash cards), mail servers and proxies, and I certainly don't want each daemon to be running its own set of dependencies. I admit, in my environment, I build a lot of the binaries, and use Slackware because I find it closest to the bone (so to speak).
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
2. Re:look how these apps are built by Lispy · 2004-12-20 10:39 · Score: 1
  
  It's not only bloat, it's also a security risk. You THINK you updated that imagelib with all those backdoors, in all programs that use it, I mean every single one of it?
Online version w/ GNU Free Documentation License by AtomicJake · 2004-12-20 09:58 · Score: 5, Informative

"Building Applications with the Linux Standard Base" has been (apparently) also published under the GNU Free Documentation License. Here is the Online version.
Radio Edit... by Duncan3 · 2004-12-20 09:59 · Score: 2, Insightful

Writing an application to work reliably under all variations is not a slam-dunk.

s/a slam-dunk/possible/

Solution: Python, Perl, ANSI C, etc. i.e. don't code "for Linux" at all, just code. Of all the ports I've done, Linux is always the biggest pain in the arse, due to the joyous work of glibc, and of course Redhat's need to do everything their own way.

--
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
1. Re:Radio Edit... by runderwo · 2004-12-20 10:33 · Score: 1
  
  Linux is always the biggest pain in the arse, due to the joyous work of glibc
  That's a non sequitur. Why does glibc's high quality mean it's a big pain in the ass? Or were you being sarcastic, in which case you ought to be backing up your criticism?
  and of course Redhat's need to do everything their own way
  I think you're unfairly blaming Red Hat's poor release policy on glibc.
  
  --
  LRC, the best-read libertarian site on the web
2. Re:Radio Edit... by anomalous+cohort · 2004-12-20 10:53 · Score: 1
  
  don't code "for Linux" at all
  Agreed. How many modern MS-Windows app developers are targeting the GDI? With "time to market" being so important, app developers need to consume as high up the protocol stack as possible. The same is true for linux app developers. Scanning the LSB spec, I expected recommendations for Qt or SWT; maybe glib as the lowest level API. Instead, I found that LSB has recommendations for libc, libGL, libX11, and libXt. These are way too low level for serious, modern app development.
  
  If you are maintaining an old app, then you might be able to, over time, change your bindings to conform with LSB. Modern app development needs to consume much more modern frameworks in order to be viable.
3. Re:Radio Edit... by Duncan3 · 2004-12-20 11:49 · Score: 1
  
  No, glibc was just one of dozens of libraries I could have used as an example. Not to mention the 39 flavors of installers/packaging systems out there, etc.
  
  --
  - Adam L. Beberg - The Cosm Project - http://www.mithral.com/
I'm sorry for the LSB guys by ewe2 · 2004-12-20 10:11 · Score: 1

because as good as their intentions are, it's never really going to happen.

If we pretend for one moment that Linux is all about the desktop market, the LSB is only going to have relevance to the top two or four distributions, period. The server market is more restrictive, only two distributions, most likely sharing the desktop market. Forget the embedded market totally.

NOTHING else will register, and there's no reason why it ever should.

--
insecurity asks the wrong question irritation gives the wrong answer
1. Re:I'm sorry for the LSB guys by runderwo · 2004-12-20 10:46 · Score: 1
  
  Actually, you're pretty close. LSB is a vendor consortium, so it's only going to be relevant to the commercial distributions. For example, Debian, the largest nonprofit distribution, has no representation in the LSB. The LSB will just solidify the fissure between commercial and noncommercial distributions if it is widely adopted.
  
  --
  LRC, the best-read libertarian site on the web
2. Re:I'm sorry for the LSB guys by Anonymous Coward · 2004-12-20 11:16 · Score: 0
  
  LSB is here, and it works pretty well. For a couple of months I was running (for arcane reasons) what amounted to a mostly Fedora 3 system with a Mandrake 10.1 Linux 2.6 kernel, and a Mandrake 10.1 gcc/g++ tool chain, and XFree86 4.3 from Red Hat 9.
  Also throw in a few odds and ends from FC1, FC2, Firefox, Adobe, and Dag. It all worked fine together with nary a hiccup. I think I had to fix a couple minor issues with a handy dandy symbolic link. As Martha Stewart would say, "Standards - it's a good thing."
Re:Online version w/ GNU Free Documentation Licens by Anonymous Coward · 2004-12-20 10:25 · Score: 0

If I had a Slashdot account(1) I'd mod this up.

(1) Every conceivable username has already been taken, and I refuse to use something like b0b_luv_a0lz_d00d2004.
LSB is useless by n1ywb · 2004-12-20 10:41 · Score: 2, Informative

http://www.gentoo.org/news/en/gwn/20030401-newslet ter.xml
Portage 2.1 to adopt RPM format for LSB compliance
In what will likely prove to be a controversial decision, Portage 2.1 will adopt the RPM format for all packages moving forward. The use of ebuilds will be deprecated in favor of the defacto RPM standard. The primary driver for this decision was to ensure compliance with the Linux Standard Base specification, which mandates RPM support for package management.
The developers have been hard at work to make this migration as easy as possible. Already a proof-of-concept ebuild2rpm script is in place and being tested by a pilot group of developers. Unfortunately, because of the architectural differences between the two formats, some features will not be supported once Gentoo moves to RPM. USE variables are one such feature; sandbox security is another. However, the added benefit brought about by full LSB compliance should far outweigh the loss of these two minor features.
Additionally, because of LSB's required library support, the xfree86 package will move to become part of the base Gentoo Linux system, rather than an optional addition. Users interested in learning more about the Linux Standard Base should read the LSB FAQ or the full LSB 1.3 specification.
Note: This is an April Fool's joke.

The differences between Linux distros are what make Linux a vibrant community and drive innovation. I hope the LSB project fails miserably to remove those differences.

--
-73, de n1ywb
www.n1ywb.com
1. Re:LSB is useless by grumbel · 2004-12-20 11:44 · Score: 1
  
  Even so this is a aprils joke, LSB does NOT force you to use RPM for you distro, your distro can still use whatever you like and be it Linux-from-scratch, all that LSB requires that your distro provides some way to install LSB-conforming rpms in addition to what your distro already provdides. On Debian that means using alien to install the RPMs, nothing more.
2. Re:LSB is useless by Tuross · 2004-12-20 15:31 · Score: 1
  
  False.
  
  Doing this atrocity will break your system at some stage. RPM's notoriously pathetic attempt at package dependencies means that should I install on my Debian system rpm foo from a vendor who think's they're doing the right thing by following the LSB, said rpm will depend on other rpms, all of which I will have to install because Redhat follow different names to everyone else. Said RPM's could overwrite any file on my system, as rpm must be run as root. Any files, including the correct libraries for all the other applications on the system.
  
  As we all know Redhat apply patches out the arse to make their libraries incompatible with all the other distributions, the system is left in a state where two package managers assume they have control of the system and are installing incompatible things willy-nilly, overwriting other stuff.
  
  This does not sound like it solves the problem the LSB is at heart trying to address, and it's why I have constantly, and will continue to constantly, protest against the hijacking of the LSB by Redhat to enforce their standards on everyone else. If I wanted to run Redhat Linux, its easy enough - all I have to do is pay $3000 or so for a license (price taken from my local retailer) but I actually prefer to have some time free in the day to do something with my computer other than solve package dependency issues; so I run a distribution that doesn't have those problems at all and lets me spend my time doing real work.
  
  Making RPM the "standard package tool" entices vendors to use Redhat Linux as their base, along with its incompatible file locations and other problems; so even if all the overwriting problems were solved, parts of the applications will be calling other bits on the system that don't exist (like chkconfig). I've seen it. This is a huge mistake we must avoid at all costs.
  
  The LSB committee is stacked with Redhat employees or partners. The only way to avoid this problem is to make a proper open standard for Linux that isn't biased towards one minor distribution.
  --
  Matt
  
  Read Slashdot
  
  ???
  
  Profit
3. Re:LSB is useless by grumbel · 2004-12-20 15:46 · Score: 1
  
  LSB rpms depend by their very nature NOT on other stuff, LSB rpms will depend in most cases on just pure LSB, thats what its used for in the firs place and if they will depend on something else it will just be other LSB rpms.
  
  ### Said RPM's could overwrite any file on my system
  
  No, because they go to /opt/ and nowhere else.
  
  ### Making RPM the "standard package tool" entices vendors to use Redhat Linux as their base
  
  You haven't yet understand the purpose of LSB, have you? LSB is for stuff OUTSITE your distribution, its not meant to replace it. It won't mess with your distri, it won't require your distri to switch to RPM, nada, all it requires it that your distro provides some way to install lsb-rpms, be it alien, rpm2cpio or whatever is completly up to your distro.
Why did I switch to Linux? by Anonymous Coward · 2004-12-20 10:44 · Score: 0

Instead of having a proprietary OS I can now have an open source OS and run all my apps on a proprietary interpreter?
1. Re:Why did I switch to Linux? by niteice · 2004-12-20 12:24 · Score: 1
  
  That is so fucking insightful.
  
  --
  ROMANES EUNT DOMUS
I like this part by Anonymous Coward · 2004-12-20 11:11 · Score: 0

Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.) The individual function organization isn't that important, but the different data structure padding is very important.

the C compiler.

It's kind of funny that the gcc has become such a standard in the Linux world, that now it's just called "the compiler".
LSB by Anonymous Coward · 2004-12-20 11:37 · Score: 0

When people are going to realize there is no such thing as one Linux. Each distribution is pretty much a different operating system. Somehow if two operating system have the same kernel(quite frankly even that is false becase RH kernel is different from Suse or Official Linus' kernel) people think they are the same. They are not. They are similar but not the same. Accept it and get over it.

Particulary becase of the fact that Linux is open source there is always going to be "non standard" Linux based OSes.
Bad argument by Anonymous Coward · 2004-12-20 12:27 · Score: 1, Interesting

Your argument isn't valid. If the cross-platform capability was what was hindering the C++ code optimization, then the same argument should apply to their C compiler. gcc generates very good optimized C code. The reason the optimizer is bad is because of the development history of g++. They evolved the compiler to support more and more of the standard (which is a good thing). In the process, however, more and more available optimizations were lost (which is a bad thing). It's that the available manpower is being spent on getting the C++ compiler standards compliant instead of making it generate fast code. I have no doubt that when the standards compliance is done that the optimizations will kick ass.

Oh, and I am the grandparent poster. I actually use g++ despite the bad code generation because it is the only compiler that actually compiles some of my C++ code correctly (although when the intel compiler does compile it, I use that -- yay test cases). Besides, it's still faster than my equivalent java code. I didn't mean to offend any gcc fans. It's just still fairly young in its development.
Standardized Standards by SouthOfHeaven · 2004-12-20 12:38 · Score: 1

After reading dumb comment after dumb comment, i do wonder if linux has a bright future. But i can always hope that when linux will be one big standard windows distro that some bright chap will have forked a good non standardized rebel version that wont succome to all the problems that arise with Standardizing things. Also it seems to me that microsoft has driven advancement for quite a while now with their resource demanding software. And i still see people bitching about Java not being as fast as binaries, why not skip the whole Compilation process and have dynamically compiled source that is compiled at runtime that way you take the worries for dependancies from the developers hands and put it in the hands of the compiler. As a developer i will install the necesary tools to cary out a certain functino of my software, but then i have to worry that it might not work on machines that dont have this or hardware that is less then that etc. Why the hell not just distribute the source code and have the compiler decide that on the spot ? I need this library, then go get it from its location online and run the damn application. Yes its slow but that can be a good thing.
1. Re:Standardized Standards by Taladar · 2004-12-20 21:21 · Score: 1
  
  What you are describing are script languages. They already work today but they do not work for propietary shit because they are afraid someone would steal their source code if they gave it to the users.
  
  --
  Linux is not Windows
Functino by Anonymous Coward · 2004-12-20 13:01 · Score: 0

Functino: The smallest unit of code which can be perceived to perform a useful action.
fine untill by oliverthered · 2004-12-20 13:55 · Score: 1

Your running kernel version 1 and the drivers in kernel version 1.2 and version 1.2 has some API changes that the driver uses.

Kernel 1.2 also has a very new VM that causes no amount of grief (as do the new changes in the API) so it's not an option to just download the driver and compile.

You could probably hack the driver to work, but then it would could be buggy and it would be hard to benefit from other bug fixes etc...

The drivers and the kernel need to be seperated for the good of Linux, what happens in a few years when we've got twice the number of drivers to maintain and how can you expect a comercial(one that makes money!) opertion to try and hit such a moving target.

--
thank God the internet isn't a human right.
1. Re:fine untill by Taladar · 2004-12-20 20:27 · Score: 1
  
  What you want is a totally fixed driver API. That way we had...let me think about it...zero development in the kernel and we had to keep old bugs because by fixing them we would break compatibility.
  
  Sounds familiar?
  
  --
  Linux is not Windows
2. Re:fine untill by oliverthered · 2004-12-21 06:42 · Score: 1
  
  No, I want a versioned API that's a lot less fine grained than the current situation.
  I would expect a 'stable' kernel to have a 'stable' API and an unstable kernel to have an API that changed every release.
  
  The Kernel should be forked (at about version x.y.3) and unstable development should be done in the fork (with back-ports) and bug fixes should be done on the root.
  
  This is how 'most' companies I've worked for release there software, they don't deliberately put unstable work into a stable branch.
  
  --
  thank God the internet isn't a human right.
3. Re:fine untill by oliverthered · 2004-12-21 06:46 · Score: 1
  
  Umm.. sound like, Sun (I've got a sun driver development manual), Microsoft (they should drop a lot of the backwards compatibility between versions though!), IBM, COBOL, C, C++, Perl, Python, HTTP, XHTML, XML, XSLT, any English dictionary, My car, the design of my house, how they make space rockets.
  
  Yeh, that stable API causes major problemsfor people.
  
  --
  thank God the internet isn't a human right.
Porque un español lo sabe. by Anonymous Coward · 2004-12-20 14:50 · Score: 0

La arquitectura interna del microprocesador PowerPC es ENORMEMENTE MUY MARRANA.

Los mejores microprocesadores de propósito general son : "Pentium-M" de Centrino, "x86_64" de Opteron y el limpio "Alpha 21364".

Nunca compraré un PowerPC ni un PowerPC64.

no me entiende? Utiliza un traductor.
1. Re:Porque un español lo sabe. by Doc+Ruby · 2004-12-20 15:05 · Score: 1
  
  Le entiendo. Quién cuida si usted no puede mecanografar la palabra "slow" en su SW de la traducción? Quién cuida lo que usted piensa sobre arquitecturas del microprocesador? Especialmente quando usted es incorrecto?
  
  --
  --
  make install -not war
STFU bonch by Anonymous Coward · 2004-12-20 16:13 · Score: 0
Ironic. by upsidedown_duck · 2004-12-20 16:24 · Score: 1

Actually, each distro has its own little additions and, consequently, quirks.

GNU's not UNIX. I get a bit of a laugh out of that.

--
-- "Makes Little Debbie look like a pile of puke!" - Moe Szyslak
Shitty license? by Craig+Ringer · 2004-12-20 18:23 · Score: 2, Insightful

Qt is licensed under the GPL, with the option of a commercial license for a fee.

It's not LGPL, sure. That means that commerical developers must buy a license from TrollTech or make the source to their application availible under the GPL. Not ideal for developers, but TrollTech are not a charity, and in my view they're rather generous to permit Qt to be used under the GPL (yes, it's just good business, but still...).

I'd like Qt under the LGPL - or heck, the BSD license - too, but I don't see a viable way to keep Trolltech in business. I can't see any reason why they would release it under such a license, and think it'd be pretty dumb to ask them to. Additionally, TrollTech do the vast majority of the development on Qt, and I'd like it to continue improving so I can have more introspection and meta-object goodness in C++.

Commercial developers have two perfectly good options - use Gtk, or buy a Qt license. I don't see that as a big deal. Remember that the "competition" is hardly in the business of offering cross platform GUI toolkits.
agree completely by Anonymous Coward · 2004-12-20 18:35 · Score: 0

LWN already had a great article on this:
http://lwn.net/Articles/96347/
Re:LSB is useless (and evil) by Tuross · 2004-12-20 20:44 · Score: 0, Troll

LSB rpms depend by their very nature NOT on other stuff ... forcing administrators to hold multiple disparate copies of the same libraries, and have to keep track of the security of each individual copy. Or perhaps every lsb app is simply statically linked?

No, because they go to /opt/ and nowhere else.

The LSB standard doesn't guarantee this. It only suggests, and recommends that there be documentation of other modifications made. It does not prevent modification. (Chapter 5)

You haven't yet understand the purpose of LSB, have you?

Yes I have. LSB is a way for Redhat to impose vendor lock-in and attempt to hijack the Linux market. Too many distributions were popping up using dpkg instead of rpm because it was better, and they had to do something to stop their eroding marketshare. So they form a standards committee with HP, Sun, and other Microsoft friends, and try to brainwash the Linux community into thinking this is a great idea because standards are good, right? They make their filesystem layout the "standard", their package management tool the "standard", etc and then make everyone feel guilty for not following the "standard".

I have no guilt. Redhat are a pawn of Microsoft, being used to drive Linux into the ground with technically inferior "standards" and user interfaces that are just like M$ Windows but not quite good enough so desktop users don't feel compelled to switch. They could have used their old monopoly to further enhance Linux, instead they appear to have used it to buy up kernel developers so they can't speak publically against the company line, and to prevent good things getting into the kernel as long as possible (eg, reiserfs, devfs, ...)

Their idea of a "community" seems to be "people who will do marketing for us for free!" as they have a proven track record of ignoring horrific bugs in their packages (both code/patch and packaging) that had been fixed by third-party rpms distributed via their own "community" mailing lists long before release of the next distribution version. Quality is second to profit. Wait, no, third to maintaining reputation.

I don't trust their business practices, their commitment to the real open source community nor their ability to create unbiased standards for that community, hence I won't use their distributions, nor advocate their standards, and urge the community to do likewise.
--
Matt
1. Read Slashdot
2. ???
3. Profit
What Holds Linux Back .... by was_ms_now_linux · 2004-12-21 06:07 · Score: 1

...is lack of coherent marketing. Competitors are very careful to frame any discussion with technical details and stresing that there are many different versions. The key to selling Linux to people who make decisions is to take a step back and focus on the high-level. Explain just how cheap it is and just how rock-solid and secure it is. Don't let the MS advocate in the room bait you into a debate about the finer technical points. I've got a bunch of stuff at www.softwareobjectz.com that may help to frame the discussion better. www.softwareobjectz.com

--
http://www.softwareobjectz.com