Slashdot Mirror
OSS Unix: Dividing & Conquering Itself
(Score.5, Interestin writes "Security guru Marcus Ranum has some interesting thoughts about how a continuing lack of consistency among Unix systems (and particularly Linux) is hurting Linux (and remaining commercial Unix vendors like Sun) and helping Microsoft. Admittedly this has been said before, but no-one else quite manages to phrase things the way Marcus can."
This is why more people need to get involved in projects like the Linux Standard Base. If more distros would quit trying to do their own thing and work together, Linux might be able to really take off. Autopackage will help people with installation hell between distros. And hopefully, freedesktop.org's new set of UI standards will help KDE and Gnome people get along a little better too....but then again, we are talking about human beings here.
"A truly wise man realizes he knows nothing."
He did breifly; but the fact is Apple hasn't tried to play by the "UNIX Standard" per say; all of their applications run totally on different levels from the normal POSIX apps. Have you looked at how their GUI apps actually work? The application is a folder, filled with all the support files. Their configuration files for applications are stored in a different location than the main UNIX /etc directory; and /etc is hidden from the end user.
While OS X is UNIX, to anyone who uses Apple's programming APIs (Cocoa or Carbon, as well as Quartz) Mac OS X isn't UNIX in anyway to them.
www.atacomm.com - The Leader in VoIP Product Distributi
Windows filename extensions are overrated and stupid VMS like legacy crapolla. I do agree that short meaningless file names are stupid UNIX legacy crapolla and that using '.' to hide files is silly however. An attribute bit would do the same thing. We are not in the 70s anymore and computers have a lot of hardware resources at their disposal now.
Regarding registry vs many small flat text files, I prefer the many small flat text files. The only problem is that there is no consistent way to organize them. You have '/etc' and '~/.*' but that is definitively not good enough.
standardize your damn directory structures and startup scripts. Or at least come up with some sort of virtual linking scheme to provide one consistant view. "Well, *BSD puts it here, but on Linux it would be there and SYS 5 doesn't have one..."
You have managed to complain about characteristics (in bold above) that make each flavor unique; you should have grumbled about device naming conventions, too, and gone for the trifecta. You may as well complain about the variations in fruit: "well, the banana has a peel that must be removed prior to consumption, while grapes come in bunches, and don't get me started on pomegranates, etc."
The BSDs are generally do things in a similar manner. This is largely historical; it is the BSD Way(tm).
One really shouldn't just say "SYS 5". Not only is the nomenclature wrong - it should be SVR* - one should indicate which revision is under discussion, e.g. SVR3 or SVR4.
News flash: Linux is very much like SVR4. You can do some things (e.g. ps) in BSD style if you like but most practical purposes Linux is ~SVR4.
Solaris >=2 is SVR4-based, as is HP-UX. AIX (IIRC) is SVR3, but AIX administration is (or at least was) its own form of pain so the historical influence is basically a footnote.
I want to drag this out as long as possible. Bring me my protractor.
In short, the directory structures are being taken care of.
- David A. Wheeler (see my Secure Programming HOWTO)
Photoshop was coded to the MacIntosh user interface, not X-windows, and functions on OSX as a side-effect of the excellent backwards-compatibility that Apple slavishly built into their kernel-swap.
No, it functions because of Carbon, the procedural API of OS X. Carbon does share similarities with the old Mac toolbox.
Perhaps this is what he was saying, but the way he says it implies OS X happily runs old OS 9 binaries due to some "slavishly" added binary compatibility cruft. It doesn't--the apps need a recompile and some code tweaking to become "Carbonized," and suddenly they're OS X apps through and through.
XML doesn't give you anything that isn't already available in a text file.
Why aren't text files the best way to configure a system?
My daughter has a large number of educational CD games (JumpStart and the like). Most of them work OK but have to be run as root. However, some kids games still won't work. Just last week I bought her a Disney game that was written for Win95/98 and will not work under W2K or XP. Apparently they have dozens of games affected in this way. The Disney site has a patch that is supposed to fix this, but I still couldn't get the game to work on her WinXP installation. At least it provided me an opportunity to emphasize that things work better with the Penguin System (Debian).
Which, interestingly enough, is *EXACTLY* what the GConf framework so many people around here complain about is supposed to be. Well, except more sensible.
It's basically a front end to all the config files you'd have laying around anyway, and a standardized XML layout for them. The "registry-like" GConf app people complain about (which really isn't that bad if you use it) is simply one front end application for an entire framework.
It also has the huge plus of generally using rather name variable names and being completely human readable. I can usually find a setting, if it exists, fairly easily by working my way down the hierarchy.
I'd rather download a binary driver than the kernel sources to get one to compile for my kernel version, as if that should matter. Especially considering that I'm on dialup here.
Interesting - I found many benefits from using a source-based distro over dialup.
Suppose a security bug is discovered in firefox. The bug was fixed by adding two lines of code. The patch is as a result about 100 bytes long.
For a binary distro you end up downloading a new 7MB binary package. For something like gentoo you just download a 100 byte patch - you already downloaded the rest of the source the last time you installed it.
In theory you could use binary diffs - but nobody seems to do so...
Microsoft/Intel was careful to guarantee them a consistent software experience across a broad selection of hardware.
It's a broad selection in brand name only. Whether it's Dell, HP, Alienware or a garage clone, it's still the same basic innards under the hood.
Linux and the BSDs run identically across a list of platforms ranging from microcontrollers to mainframes. Marcus has been around the block enough times to remember that Sun made the transition from 68K to SPARC with a brief stop in i386 land with with the old BSD-based SunOS. They did it again going from SPARC to x86 with the SVR4-based Solaris. Apple gets props for having nicely made the transition from 68K to PPC with MacOS and should probably get a couple of points for its rumored internal port of OS X to x86.
When Microsoft can release a fully-functioning version of one of its current products that runs on another platform and looks, smells and tastes like the same product on Intel, I'll agree with Marcus. Let's try hard not to remember NT on Alpha.
Perhaps none of what anyone's predicted will be Microsoft's undoing will actually be it. Maybe it will be some huge non-x86-compatible advance in harware so compelling that nobody can resist it. The race will be on to see who can have a working OS on that hardware, and I'd put my money on it being one of the Unixes.
Linux was started(?) sometime in the summer of 1991. (http://www.li.org/linuxhistory.php)
Windows 3.0 came out in in 1990, with Windows 3.1 in 1991. Both were a major success, mainly because Windows 1.0 and 2.0 sucked sooooo badly, just about anything would've been an improvement. One of the features was running in x86 protected mode.
Windows NT work was started in 1988 and released sometime in 1993 (http://www.microsoft.com/presspass/features/1998/ winntfs.asp). NT was a massive improvement over anything MS had done. and did cover the memory protection, pre-emptive multitasking issue completely. Configuration changes without reboots have always been partially supported, the main buggers were network settings and certain system level settings that *did* require a reboot. However I *really* doubt that the linux available in 1992-1993 was very slick with these things either.
Meanwhile WIndows 95 was well underway by 1992, and also addressed/fixed the memory protection, pre-emptive multitasking issue. Admittedly, no where near as well as NT did, due to it's braindead DOS underpinnings, but it was still leaps above Win3.x.
All of this happened while linux was nothing but a bare little kernel, with admittedly pretty small goals. I can't see how any influence would've been even noticed until at least 1998. Loads of other OSes had things like memory protection, pre-emptive multitasking, configuration changes without reboots well before linux.
My prediction: If Linux in business applications get useful enough, then we will see that various "flavors" mean nothing -- businesses will have one or a few guys making the "desktop load" and that is the image everyone will be using. Forget about "flavor" problems -- each business will make their own anyway -- as if we don't already do that with Windows to begin with?
Very good, erroneus! Somebody get him/her a banana!
Cisco has (hold onto your hat) CISCO LINUX!!
You can use a different distro if you like, but to get 'official' tech support you have to use the Cisco internel distribution. Cisco has everything set up to work in Cisco, and you can kickstart it to load across the network. It comes up knowing where all the resources are in the company.
You have seen the future, erroneus, as this will be the pattern for large companies in the future. There are just to many competitive advantages for this paradigm to be ignored, not least of which is to modify the file system a little to foil virii.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba