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?
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.
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