Weekly Edition
Return to the Press page
| |||||||||||
Can Linux Standard Base keep penguin from mutating? (NewsForge)
NewsForge wonders
if the LSB is enough to keep Linux from fragmenting. "Ted Tso, a
member of the Free Standards Group board of directors, explained that a
single, standardized Linux OS may not be feasible and pointed to unfruitful
instances from the past with Unix. Efforts to standardize source-level
programming interfaces -- such as Postable Operating System Interface
(POSIX) and the Single Unix Specification (SUS) -- as well as attempts to
develop a standard reference implementation to unify the operating system
utilized by multiple companies, such as the Open Software Foundation's
OSF/1 operating system, have not worked, according to Tso."
(Log in to post comments)
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 12, 2004 17:50 UTC (Mon) by verzonnen (guest, #9406) [Link] The standard linux will be the one that is the easiest to install, update and absolutely free. Just have a look at Fedora to see how popular it is.Personaly I am p...d off with how all the different distributions change things, yesterday I found that Fedora/redhat does not show all the processes with the "ps" command. However companies/managers will continue to purchase their distribution so they can point the finger elsewhere when there is a problem. And as long as there is money involved Redhat, Mandrake, Suse, etc will have this (preceived) need to distinguish their distribution from the next one.
Kernel process list changes? Posted Jul 13, 2004 8:23 UTC (Tue) by xoddam (subscriber, #2322) [Link] Not writing as a Fedora user, but:Linux 2.6 uses a very different threading model from older kernels. Fedora has recently upgraded its standard kernel and the related utilities such as ps. It's possible that your ps list is now showing the POSIXLY_CORRECT one process per address space, rather than one process per thread. (or perhaps I'm talking rubbish)
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 13, 2004 13:01 UTC (Tue) by juzza (guest, #23020) [Link] Try the -m switch (show all threads): ps auxm
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 13, 2004 17:01 UTC (Tue) by verzonnen (guest, #9406) [Link] I am very annoyed (to say the least) that the command is very different on fedora from what I expected (and am used to) maybe it's the same on all 2.6 systems, but I can't compare.. Now if a programmer or company thinks (or know) that they can write a better ps command, please do so, just give it a different name.Below is from the man page EXAMPLES Maybe I am just getting old, set im my ways and grumpy... But the point I was trying to make is that as long as there are comercial interest involved, the desire to be different will be greater than the desire to conform. Secondly I do think that GNU should not be organized in some artificial way, let it continue to be free and do things because they are the right way to do it. I know it does sound contradictory, but I do expect that by allowing creative freedom we will end up with far better software, even though it does seem very messy at times.
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 14, 2004 17:45 UTC (Wed) by edgewood (subscriber, #1123) [Link] 'ps' is behaving correctly in both cases (new and old threading models). If you run 'ps ax' on a system that uses the old threading model, it shows you all of the threads, because each thread has a separate process ID. The new threading model doesn't do that: threads that belong to the same process have the same process ID. So if you run a 'ps ax' there and look for a multithreaded app, you'll only see one line, since there is only one process ID. If you want to see the threads, 'ps axH' will show them, but note that they all have the same process ID.This is not something Fedora specific, nor is it due to something that was changed in 'ps': it is doing the exact same thing it always did, displaying process table entries. The only thing that has changed is whether or not threads have their own process table entries.
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 15, 2004 8:53 UTC (Thu) by ekj (subscriber, #1524) [Link] Andd ps does exactly what the manpage says it should do, and what it's always been doing.The only confusion relates to what exactly a "process" is in the context of multithreaded applications. Is it one process as long as it's got one shared PID ? As long as it's got a shared memory-space ? As long as it's got one thread of execution ? ps says it's a process if it's got a pid and a entry in the process-table, which means that with newer kernels, different threads still count as a single process.
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 12, 2004 18:40 UTC (Mon) by brouhaha (subscriber, #1698) [Link] Efforts to standardize source-level programming interfaces [...] have not worked, according to Tso.Perhaps they haven't worked as well as their developers intended, but it's also possible that the Unix world would have become even more fragmented without those efforts.
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 12, 2004 19:11 UTC (Mon) by mmarq (guest, #2332) [Link] IMO it has been one of the things that has prevented Linux OS to fragment beyond recovery...Do to the very distributed nature of Linux development, it is almost a miracle that the Linux kernel is not heavly fragmented... the multiple source are there, but it seems that the official "benevolent dictated" one seems to have a "major" importance... the other restrinning mechanism is LSB. In the end it depends on the "will" of the developers to cooperate instead of competing, to keep Linux unfragmented. Even so, IMO, Linux needs more partneships like CELF, more focused with everybody hardware to really take the IT world by storm (the big mistake of Unix was to forget the needs of domestic and SOHO markets... Microsoft has clearly showned that, making of the common PC and the crap Windows the best selled systems among SME).
Kernel and GNU (esp. glibc) Posted Jul 12, 2004 20:04 UTC (Mon) by AnswerGuy (subscriber, #1256) [Link] The unifying standards of Linux so far are that it has one mainstream kernel (maintained by Linus and crew) and one set of base utilities and C libraries (provided by the FSF GNU project).Mainstream versions of Linux share these and most of the differences are relatively superficial. Yes, those superficial differences are a hinderance towards administration and for ISVs (who want to have standard ways to install their applications and services regardless of underlying distribution). I emphasize "mainstream" here since there will always be embedded, turn-key, cluster, and other specialty distributions (CELF and the carrier grade efforts, for example). For my purposes here I'm defining mainstream as: those distributions onto which people would want to install "off-the-shelf" (as it COTS -- commercial off the shelf) software. We need a standardized way for an installer application to invoke package management functions (perhaps a front-end to RPM) and a standard way to represent abstract dependencies (which resolve to distribution dependent package names/versions). We need for all mainstream Linux distributions to support 'chkconfig' and 'service' commands. We need a standard way for new applications and other resources (fonts, printer drivers, etc) to register themselves with the system (to appear on appropriate window manager menus, etc). This last item is trickier than it sounds since we don't want such menu appearances to be all or nothing; administrators need to be able to manage which applications appear on which menus (perhaps by reference to system group memberships) and individual users still need to be able to control their environments (possibly still subject to constraints imposed by the admin --- for kiosk like environments). I think it can and (to some degree) will be done. JimD
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 12, 2004 21:32 UTC (Mon) by josh_stern (guest, #4868) [Link] It seems like there is room for both commercial and non-commercialtesting services that would help ISVs to automatically submit binaries of different application builds and test them for compatibility with base installs of different distributions of Linux. LSB will help, but it will be hard to completely insure that what is tested by LSB matches exactly what is needed for binary compatibility with a particular application.
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 12, 2004 22:18 UTC (Mon) by iabervon (subscriber, #722) [Link] I think there were two reasons that UNIX fragmented: the vendors wanted to differentiate themselves, and the relation between variants was due to standards committees.The issue is that, if a vendor wants to support something that other vendors don't care about at the time, the standards committees don't get involved, and the next vendor to want to do it is likely to do it differently. On the other hand, a lot of a Linux system is under the GPL, which means that a vendor's changes are likely available to upstream projects, and also to the next vendor; the standards are dictated largely by the available code and the desires of each distribution to get its code into the upstream projects, such that it doesn't have to port to new upstream versions. As Linux distributions are depending on work from upstream projects, they have a powerful incentive to minimize their differences from the upstream, and therefore their differences from each other.
Can Linux Standard Base keep penguin from mutating? (NewsForge) Posted Jul 13, 2004 18:48 UTC (Tue) by hamjudo (guest, #363) [Link] We want the penguin to mutate, because if it stops changing, it will die. Every change creates a fork. As the changes are merged, the forks go away.The GPL is the key to managing the mutations. The GPL actively facilitates merging, instead of trying to limit forking. The traditional commercial UNIX licenses made forking very hard. It wasn't practical to get a commercial UNIX license without investing some lawyer time and a bunch of money. The commercial UNIX licenses were usually incompatible. For example, Sun OS code couldn't be freely copied into System V, and system V code couldn't freely be copied into Sun OS, so the two code bases mutated in random incompatible ways, for example sum(1). It tooks months of negotiations for the managers and lawyers at Sun and AT&T to authorize a code merge. Then years of effort before most Sun customers actually preferred the merged product, Solaris 2.*, over SunOS. Since there isn't an artificial license barrier, GPL projects are forking and merging all the time. When a technical issues leads to a long term fork, for example the port of Linux 2.0.* to machines without MMUs, it stays a technical issue. With a suitable technical fix, the code is merged back in. Even ignoring the cost of the managers, lawyers and accountants required for the commercial merge, the GPL code merge was still much smaller. In the Sun/AT&T merge they had to cope with all of the random changes, even the ones not as painfully visible as the incompatible sum commands.
POSIX success Posted Jul 13, 2004 6:25 UTC (Tue) by eru (subscriber, #2753) [Link] Efforts to standardize source-level programming interfaces -- such as Postable Operating System Interface (POSIX) and the Single Unix Specification (SUS) -- [...] have not worked, according to Tso."An odd claim. While portability is not yet perfect, today it is very much easier to write sources that work over a large number of diverse unix-type systems, than it was about 15 years ago, because all of them at least attempt to follow those specifications. For example, a large program I have been maintaining for about that long has "system dependency" header file that has a maze of #ifdef cases for circa-1990 unixes and their compilers, but today I can simply set the defines corresponding to "assume POSIX and ANSI C" to get it to work on any modern POSIX system.
POSIX success Posted Jul 13, 2004 12:24 UTC (Tue) by hingo (subscriber, #14792) [Link] Yes, I think this is a misunderstanding on the part of the journalist, or maybe simply ambiguously written. What I think Ted Ts'o is saying, and which would make sense, is that a source-level standard did not help ISVs, which would have needed binary compatibility and compatible filesystem layouts etc... In other words, the source-level standards did exactly what they were supposed to do, but were not the right way to combat Unix fragmentation.
POSIX success Posted Jul 17, 2004 11:40 UTC (Sat) by addw (subscriber, #1771) [Link] Getting a program to compile is not the problem; the differences lie is little bits of system admin: how is something installed so that it always starts in run levels 3 & 5; how do you find the attributes of the printers; exactly where are binaries installed; what packaging mechanism is used ?
|
|||||||||||