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

Comments

It can be done... BUT

[Amphigory]

This could certainly be done, and it is a good and worthwhile undertaking. If I were designing it, I would probably design a system around Coda for file sharing, LDAP for a directory service, and CUPS for printing. In other words, most of the work has already been done. What is needed is integration. In order to work well, there needs to be a standard, well-defined way to find resources. When a new print server comes online, it should automagically be added to the directory. Likewise with file services. What is a little more ticklish is that you will probably need to develop your own security paradigm that can cross the gap between Windoze and UNIX security models. This will probably require modifications to both the filesystem and the print server software to be complete. (I guess you could do something based on ACL's pretty simply). Now here's the BUT: is there really enough market for this to justify it? Maintaining the client for Windows is going to require a tremendous amount of work, especially since there are at least 10 different variants in common use now. The advantage of Samba and friends is that they push that work onto Microsoft. Unfortunately, there are not a whole lot of open source types who want to develop for Microsoft platforms. This is the kind of thing that screams for a commercial open source approach (a la Redhat). You develop the product as an integrated whole, then make money selling it. In any case, It's probably going to need some $$'s to make it happen.

--

The way it works..

[JamesSharman]

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.

Using Linux as a NOS

[voidzero]

I strongly suggest that this site be visited.

Regret for the past is a waste of spirit

Simply, No.

[richnut]

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

Re:Simply, No.

[ethereal]

I think some of these are straw men:

Here we are in the year 2000 and our OS doesn't have a central, consistent, configuration database, for apps and system resources alike.

I admit that I had a knee-jerk reaction against a "registry" - sorry, it's a conditioned fear and pain response :) A central configuration system would be neat, but on the other hand you would break compatibility with a lot of existing Unix applications which expect /etc, /proc, and so forth. I guess you could set up this database in a different directory and only new apps would know about it. Better make it flat text, though - I don't think a binary registry will fly very far.

They are just now getting a journaling filesystem.

Does Windows NT ship with a JFS? I was under the impression that it didn't, although I'm sure to be corrected if I'm wrong. Linux isn't the first system to get a JFS, but it's not going to be the last either. And it may end up with two or three :)

The security model of all or nothing is a joke.

Sounds like someone's been reading the Microsoft Myths about Linux page :) Have you ever heard of groups?

There isn't even mandatory file locking for crying out loud.

Well, it isn't necessary for every file, so why should it be necessary? That sounds like overhead that an application should handle if it needs it.

I'll be the first person to admit that Linux has problems, but I don't think that they're necessarily the ones that you pointed out.

And Verily, Linus did spake unto the crowds...

[Spoing]

"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 of /etc/password. And think of the STUPIDITIES that a lot of UNIX vendors made with their user managment databases - it happened not once, but multiple times. All in the name of unified tools (never mind the fact that none of the standard tools worked any more), and in the name of efficiency (the "parsing ASCII wastes CPU cycles"). Do people think that .bashrc would be better in a binary format that uses special tools to edit it? I don't think so. Don't make the kernel interface files fall into that classic _stupid_ black hole. Plain-text ASCII is a goodness. Readable naming is a goodness. Yes, it takes more care, but the end result is simply _better_. The rant continues in Kernel Traffic, #64; http://kt.linuxcare.com/ke rnel-traffic/kt20000424_64.epl#1

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