Slashdot Mirror
On Leading vs. Following In The NOS World
This Anonymous Coward wishes to put this question before you all: "All of us know how well the Linux community can follow other technologies, case in point, Samba. I have to wonder when Linux will reach the point where it begins to lead the way vs. follow. A technology such as Linux Directory Services could be such a opportunity. Could Linux developers create a client/server based NOS that does not have to be bent, twisted, patched, or hacked to work with the leading OS's? Could we develop a new set of server processes which communicate with workstations through a custom built client?"
"Novell has done this, I log in with the Novell client for Windows every morning. As a result, certain network services are performed natively on both sides. If this were done, I'm sure most of us would readily use the extended abilities of a native client/server system. A system where servers are more than glorified disk controllers, able to execute remote applications as well as supply standard network services.
I would dread to think such an application would not be developed because it would not fit well into the current corporate wish-list. Let the suits follow for a change, it's their turn."
--
-- Slashdot sucks.
It's generally been a rule with technology that the first practical solution to a problem becomes the defacto standard, regardless usually of better solutions further down the road. There have been instances where standards have developed under unix and then been railroaded of by Microsoft, the reason for this is simple. The wintel architecture dominates the desktop, and to a lesser extent the corporate server market, if you put together a solution under linux you MUST get someone to write the windows/NT drivers to go with it. It's is only when you have the windows drivers that can talk to your new protocol (or the windows server and linux client) does it truly provide a solution as far as the wintel dominated corporate sector are concerned. Once you provide a solution people will use it, and once actually they start using it there is very little anyone including MS can do to change that.
Regret for the past is a waste of spirit
Linux doesn't even do a good job of fixing what's wrong with UNIX, let alone leading the way in anything. It's run by comittee and the people in the comittees like UNIX and will defend UNIX regardless of whether it's the best solution or not. Here we are in the year 2000 and our OS doesn't have a central, consistent, configuration database, for apps and system resources alike. They are just now getting a journaling filesystem. The security model of all or nothing is a joke. There isn't even mandatory file locking for crying out loud. This is not an OS that leads.
It's not that people dont want to fix this sort of thing, it's just that they'll never get the voice or support to do something like this. Go ahead. Mention the word 'registry' to a Linux zealot and see how it goes. You'll see what I mean. Anyone here remember how it went for Linus when he tried to allow some C++ inside of the kernel around 0.99pl13? It was a disaster. No one wanted to wait out development time for proper C++ code, they just wanted UNIX.
Dont get me wrong, I like Linux, and I use Linux, as I have for 7 years now. I wont stop using Linux. It just bothers me that there is no organized group of users who are actually trying to make it the perfect OS instead of the perfect UNIX.
-Rich
...but if you do, make sure to use Unicode and give it i18n functionality, so the rest of the world can translate it into their own languages. I've found that there's nothing that annoys them more than not being able to use their own character sets in an otherwise good piece of software.
-JD
> while whiz-bang 'extra functionality' may seem like an attractive target, it is usually less valuable than a system that works well
Exhibit A: VBScripting.
--
Sheesh, evil *and* a jerk. -- Jade
One of the really cool features of the Novell NetWare Client for Windows 95 is "Automatic Client Update" (ACU). By just putting
in the appropriate login script, the Novell Client version is checked at login time, and upgraded automagically if necessary.This trick is especially useful when installing new machines, because it will even upgrade from the Microsoft Client for NetWare Networks. All you have to do in install Windows 95 from CD, and after logging into a NetWare server once, you're automatically running the latest and greatest client from Novell.
However, Microsoft broke this feature in Windows 98. Trying to install Novell Client 3.x from a network drive causes the installation to fail with the errors
Copying the install files locally (or using a Novell Clients CD-ROM) works fine, but that is time consuming to do at every workstation. These errors are caused by a bug in the Windows 98 netdi.dll file. See Novell's Technical Infomation Document TID 2946390. Microsoft knows about this problem. They even have a fix for it. You need a specific version of the netdi.dll file (version 4.10.2029, size 317,840 bytes). This hotfix is referenced in Microsoft Knowledge Base article Q190656. But you can't have it. If you want it, you have to call Tech Support, and pay them $150 for an "incident". If you can convince them that all you needed was the hotfix, you might be able to get your money back, but don't count on it...There is a nice description of the problem of trying to get your money back at Trent University. Also, despite what the above Knowledge Base article says, this problem was not corrected in Windows 98 Second Edition!
Now, according to Infoworld, the next version of Windows, Windows Millennium Edition (ME), won't have any NetWare connectivity built in. Microsoft is going to remove it from the box. That will fix it! You can't use ACU to upgrade Microsoft Client for NetWare Networks, because you can't have Microsoft Client for NetWare Networks at all!
Okay, so I'm back to my conspiracy theories... Windows isn't done until NetWare doesn't run.
--
My word processor was written by Stanford Professor Donald Knuth. Who wrote yours?
"I'm against using text files because textfiles can be fucked up with typos and duplicate data. A good db like system protects you from making those errors. Using XML would be an improvement over the current situation but also a big misstake in my eyes since XML is just as unsuitable for permanent storage of data as a normal text file."
In that case, are you considering a binary file, or some kind of registry system? If so, check out the rant Linus went into over proc & devfs issues;
"Guys, remember what made UNIX successful, and Plan-9 seductive? The "everything is a file" notion is a powerful notion, and should NOT be dismissed because of some petty issues with people being too lazy to parse a full name.
The same is true of ASCII contents. Binary files for configuration data are BAD. This is true for kernel interfaces the same way it is true of interfaces outside the kernel. I tell you, you don't want the mess of having things like the Windows registry - we want to have dot-files that are ASCII, and readable with a regular editor, that you can do grep's on, and that can be manipulated easily with perl. Think ofOn a serious note, just because Linus said it doesn't make it universially correct...though he does have a point.
I remember working on an old DOS program where line endings and file endings caused us all sorts of headaches in ASCII files. Till we handled them consistantly, we often ended up with odd problems parsing text configuration files. Once that was done, the headaches went away -- not the creation of some obscure binary file format only our program could touch.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
There seem to be a lot of people out there who really dislike the idea of a text-based, human-readable (and editable) configuration database. I'm going to address some of their points here.
/etc/fstab file, I can fire up emacs and fix it.
.dot-files scattered all around the place works somewhat well when only a single person uses a non-networked computer.
...
... or whole files are not granular enough.
... or a teacher add user accounts for her classes on a certain server or user group.
First, the easy one: Text files are bad because they can get messed up by typos.
Um, right. And exactly how well does a binary file deal with typos?
You're trying to solve the wrong problem. If the I make a mistake editing my system configuration files directly, I am going to be in trouble, regardless.
The solution is to use an intelligent, front-end program which does sanity checking on the data entered. The difference is, a human-unreadable format cannot be fixed when the front-end program goes wrong. When the MS-Windows registry is corrupted, you reinstall the OS. Period. But when linuxconf screws up my
That is the biggest reason why human-readable configuration files are vital: Because computers screw up, and I want to be able to fix them when they do.
Now, let's move on to some of the other points: Text-based configuration data results in a performance penalty.
Well, I guess this is technically true. But let's think about this. Parsing the configuration file is something that generally only needs to be done once, when the program initializes (or the file is changed). Most configuration files are small enough that this is really not a significant performance hit. Computers process data, often text data. They do it very well. Let's not get all worked up about asking them to do more of the same.
Next: There is no standard format.
Now, here the detractors have something. Unix evolved rather then being designed. The result is a hodge-podge of configuration formats. I am sure a great many of us would really prefer it if things were a bit more standardized, but they're not. And here that most evil demon of systems design, backwards compatibility , rears its ugly head once again. We can't change things without breaking everything -- programs and people alike.
Unfortunately, there is no good answer to this problem, on any system. It would be easy enough to start rewriting things to use a more standardized format, but nobody does, because frankly, it isn't worth it. If it was, somebody would have done it by now. What we have works quite well, and the effort involved in changing everything is more then the effort needed to figure things out.
It is worth pointing out that simply moving to a standardized format isn't going to alleviate the need to understand what you're editing before you edit it. I've seen enough misconfigured Macs and NT boxes to know that a pretty GUI or a rigid file format doesn't make a system fool-proof.
The text-based nature of Unix's configuration database is actually a strength, here. You cannot comment the Windows registry. But I can (and do) add comments to all of my Unix configuration files. You can also use RCS, SCCS, or any other revision control system to keep track of what was changed, and why. Try doing that with NT.
Now, let me address a few points by particular people:
jilles writes: I think current linux distributions with all their environment variables, init scripts, shell scripts and ancient tools are far more complex than necessary to accomplish the flexibility and security they offer.
I disagree. One of the reasons Unix has survived so long and adapted so well is that it is built on flexible tools, and easily modified and extended for new situations. Those "ancient tools" are still in use today because they work damn well.
In my opinion an OS is nothing more than a kernel + application packages + configuration user data.
You just described the entire computer software system for most cases, so I don't know what your point is.
A good principle in software engineering is separation of concern. It is not practiced enough in linux because configuration files are applications which are partially stored as user data.
Separation of concern is a design principle that states, roughly, that components should not concern themselves with duties that are not theirs. I fail to see how storing configuration data in shell scripts violates this principle.
Not too mention that the kernel's functioning depends on a legion of scripts.
Incorrect. The kernel does not require a single script to boot a running system. Issue "linux init=/bin/sh" at a LILO prompt sometime and you'll see what I mean.
Now, overall service activity is controlled by a series of portable shell scripts because that is what shell scripts are for: Automating repetitive tasks. If they weren't controlled by scripts, you would have to write, maintain, and port a compiled program instead. Just because something is compiled doesn't mean it is better.
Stefan writes: The current situation with
Um, every hear of a networked home directory?
Insufficiently flexible permissions for modifying the configuration, either because filesystem lacks acls
A lack of filesystem ACLs is a deficiency, and one that should be fixed. And it has been, on several commercial Unixes, and is coming Real Soon Now to the free ones too, or so I'm told.
Then you use more then one file.
Difficult to inherit/replicate configurations, for say 20 identical clients.
See cp(1) for details on that.
Allows for for a flexible permissions system, let a user remove printjobs from the printer on his desk,
Um, this can be done now.
Same here. Granted, you'll need the right front-end tools, but that is a universal condition.
Administrate everything without needing to log on to a dozen computers editing files all over.
Look at rsync(1) and rdist(1), as well as network filesystems and NIS. (Granted, NIS has a number of design and implementation flaws, but they are not inherit in the design of Unix.)
Move around configurations and configured items in the tree easily. For example imagine dragging the the apache object from server A to B and voila you've moved your webserver to run on the other computer instead.
Here you should look at the mv(1) command.
IN SUMMARY
Under Unix, everything is a file. Filesystem access controls enforce security. File editors change things. File revision control tracks changes. And file management commands move things around. Why design separate interfaces for everything if you already have them there in the filesystem?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.