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

Client Integration

[Detritus]

How are you going to do this without the cooperation of Microsoft? SMB support is integrated into Windows. I'm guessing that Windows supports Novell because of customer demand and a desire to infiltrate Novell based networks.

Re:Client Integration

[phil reed]

Windows supports Novell because:

• Novell is a registered Microsoft Developer.
• Windows is open enough that Novell can plug in the stuff it takes to support Novell networking without active cooperation from Microsoft.
• Microsoft is in enough trouble already - if they took active steps to prevent Novell from interoperating, the anti-trust sh*tstorm would be orders of magnitude worse than it is now.

Yes, Microsoft would like to take away business from Novell, so MS does *just* enough to barely operate.


...phil

Look at openldap

[maddboyy]

Unless I misunderstood the question, I think the poster may want to look at the OpenLDAP project. It's been around quite a while and offers some of the services requested. Check out www.openldap.org.

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

Re:Using Linux as a NOS

[dsplat]

It is an interesting article for its summary of the things that NOS customers are looking for. However, it seems to substitute overgeneralization for real information in the case of Linux. Here's one of the things I tripped over:

In most cases, the choice of CPU is determined by the operating system. For example, Unix implementations optimally run on RISC-based systems, whereas NetWare and NT servers are nearly always Intel based.

That would have been okay, except that it didn't go on to explain that Linux, while widely ported, is native to the i386 family and most widely used on Intel processors.

why not?

[riggwelter]

I fail to see why this could not be the case...

The way new technologies become 'standard' be that as approved by ISO or similar or de-facto is for big businesses and other large organisations to adopt them. Corporate (America|UK|Europe) is already adopting Linux at server level for web serving, mail serving... It's a short step mentally from that to a directory service.

Let's say you're responsible at a management level within a company for web content. I don't mean you're the web server admin, I mean you're where the buck stops before the CEO. You want people across the company to be able to contribute relevant information to the website, which has been running happily on Linux for the past three years. Your server admin informs you that he has no intention of giving every Tom Dick and Harry in the company shell access to the server, so what are you going to do? What you need is some method of maintaining information on people, and allowing them access to the server solely for this purpose - an opening...

Mail again is a natural opening to directory services. If people are already getting their mail from a Linux box, why not extend it to serve any information on them as may be required internally, subject to all the usual security disclaimers of course...

All that is required really is for someone to start work on it - get a team of top notch hackers on board and away you go. Consult managers from the sort of corporation who this could be targetted at to find out what they'd want/expect out of such a system as a starting point. Believe it or not you can apply commercial software development ideas to open source development :)

--

Re:Why not?

[rcw-work]

$150 is the humor value for them naming it 'msfux.exe' :>

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.

Re:Simply, No.

[jilles]

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

It is this conservatism which makes it difficult to configure linux. Because of that managing a linux platform is more expensive than necessary.

I'm in favor of moving away from shellscript based config files towards a central LDAP based config system. Mixing code and configuration as is common today is a bad thing.

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.

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. In my opinion an OS is nothing more than a kernel + application packages + configuration + user data. 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. Not too mention that the kernel's functioning depends on a legion of scripts.

Re:Simply, No.

[Manax]

The security model of all or nothing is a joke.

Users/groups is far from a joke, although it does have problems and limitations. Capabilities are coming. Some people are pushing for them to be in 2.4 (at least as experimental), but definitely in 2.6.

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.

There are plenty of groups trying to make "the perfect OS", (of course, all with different opinions of what 'perfect' means...) but Linux is derived from the concepts in UNIX, asking it to become something else means that it is no longer Linux.

And some of us think that the fundemental concepts of Unix are pretty close to perfect as is. ;)

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

Why is this a "perfect" criteria? As other /.ers point out, a "registry" leads to a single point of failure, reduces maintainability, breaks lots of standards, etc... There has been lots of talk on lkml regarding this topic, and generally people seem to like the idea of a central repository, text based, but much of it is a userspace issue, and a HUGE undertaking at that.

The reason so called "Linux Zealots" go off the handle when people bring up registries ala win32, is because it's been talked to death, and the majority of people that know this stuff think it's a bad idea.

This is not an OS that leads.

This was a choice. They weren't out to build a completely new OS, they were out to build a free Unix-like OS. I would assume that once clonable features run dry, Linux will continue on at it's present pace, developing new features along the way.

I am absolutely certain that there are plenty of new features already in development or already built that HAVE led. I don't know what they are off hand, but I'm certain that other /.ers can give examples.

Re:Simply, No.

[ethereal]

I guess I would make the counterargument that the operation of a Unix system based on small, flexible text-based tools is a strength, and you don't necessarily have to have complexity as well. Granted, the current structure of /etc, /proc, and wherever the apps decide to toss their config files is all over the place, but it doesn't have to be that way.

If you're going to retool the system from the ground up to be DB/directory oriented, wouldn't it just be simpler to update the apps to use specific directories under /config for example, mount /proc under /config, and move /etc into there as well? If you don't like all of the shell scripts, you can combine and/or replace them and put them all in /config/scripts or whatever (thus separating code and configuration). Then you can still use text files (for when your fancy DB tools don't work right or don't give you the whole story) but you would have a directory of configuration information, organized more cleanly than it is today. Of course, this would require major application retooling and might make some applications non-portable to other Unices. That's probably why such an effort hasn't occurred yet - portability and familiarity between Unix-like systems adds more useability for the administrator than any amount of clean-up which breaks that familiarity. But if a cleaner configuration style is enough of an improvement, people might switch anyway.

Re:Simply, No.

[jilles]

The windows registry uses a tree structure to store data in. The individual nodes of that tree consist of ascii indeed. However the point is that because it is a tree it is easy to find information. A textfile has no structure.

The windows registry is actually not a smart thing either. Better is to use a directory server (novel does this). By using a remote server you can have your configuration remote (netsape uses this to implement roaming profiles).

So, no, I don't have my head up my ass and I fully realize that it is going to be impossible to convince the entire unix community that their way of working with configuration info is far from optimal (to put it mildly). Using an editor to edit configuration files seems like a very primitive way of doing configuration. It requires that you know the fileformat (and as discussed before, fileformats usually don't adhere to any standard at the moment) and makes it the user's responsibility to keep the files consistent.

The reason of my rant is that I have once spent a few days figuring out how to get my deskjet working under slackware. The HOW-TO at that time was not very helpfull and it occured to me this was the most user unfriendly way of configuring a printer i had encountered so far (mind you this was 1996). Unfortunately the whole linux system is constructed in a similar way. During boot time, the kernel wrestles itself through a enourmous spagethi of initfiles. As a newby, you can easily lose an afternoon figuring out what file to edit to set a stupid environment variable.

Re:Simply, No.

[ralphclark]

Unix is Unix. If you don't like it, then feel free to write your own operating system. Just don't suppose for a minute that anyone's going to let you fuck ours up.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:Simply, No.

[Chalst]

I don't know NT, but aren't there administrators able to change
people's levels of security, add users, deleted users, etc.? Once you
have such administrator powers then effectively you have root
exploits. If not, then how are user permissions handled?

Re:I pray that Linux does not lead the way........

[technos]

Then we have FreeStandard, RedHatStandards, and SuSEStandards

Apache does a good job of following standards, as do all of the system daemons. What makes you think we wouldn't stick with one standard? Slap it in a RFC and say 'Ye shall use this' is all it takes!

Been doing it for 20 years

[drig]

If you say "Linux", then it's unlikely that you'll see much leading. "Linux" is just the kernel. But, if you say "Open Source Software" or "Free Software", you'll see that this has been the case for a long time. OSS made the Internet. Sendmail, BIND, Apache (well, I guess NCSA HTTPD at that point) all lead the way. Other OS vendors have followed this lead.

Go ahead...

[Pike]

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

standards compliance vs embrace + extend

[Blue Lang]

one of linux's strengths has always been that it more or less universally aims for standards compliance. while whiz-bang 'extra functionality' may seem like an attractive target, it is usually less valuable than a system that works well, and works well with the rest of your systems.

squeezing an extra 10% of performance out of commodity hardware seems less valuable to me than knowing that your linux box will work with whatever sort of network you need to put it into.

all IMHO, of course.

--
blue

Re:standards compliance vs embrace + extend

[Black Parrot]

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

--

Re:So you got off your butt and wrote the software

[richnut]

Maybe you'd like to help with one of the existing systems?

Like:

Libcfg
http://www.yelm.freeserve.co.uk/libcfg/

Actually I would. I'd not heard of this. Looks Cool. I'll build it tomorrow. Thanks for the pointer.

There are more. Part of the problem is that Linux software must be able to run/build on existing commercial Unix
systems so the configuration management system must also be available on commercial systems with commercial
applications, not just GPL'd applications.

If the config system is GPL'ed isn't that done already?

-Rich

Not until Linux drives client-side business apps

[Wellspring]

My feeling is that server-side network standards emerge from a need on the client side. Where do those requirements come from? End users, of course.

I don't think that Corel 8, StarOffice or even the general interface is very mature yet. It certainly isn't broadly adopted.

Should that happen, the self-help aspect of Open Source would kick in, and you would start seeing people develop apps for their needs. For instance, multi-user spreadsheets and word processors. These exist, but aren't very good right now.

But network standards don't come from the top down. They go from bottom level user requirements, up the line to the standards you need to satisfy the users. Or put another way, plumbing development follows kitchen and bathroom requirements more closely than it does pump requirements. Both have to be satisfied, but only one will give you complaints from homeowners.

Microsoft can't even follow standards...

[ptomblin]

...so why are we expecting it to follow an implementation?

Their record on confirming strictly to simple RFCs is abysmal. When they try and talk SMTP or some network standard like that, you end up with something that is almost, but not entirely, unlike what the standard requires. So every other vendor then has to add hacks and work-arounds for Microsoft's deficiencies.

Given that they can't get things like de jure standards right, what makes you think they are going to follow an innovation from the open source world well enough to make it a de facto standard?

More likely they will look at the idea and implement something quite different that does the same thing in a totally proprietary manner.

--
A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.

Re:Novell Client Integration (off topic).

[klund]

That's not to say that Microsoft isn't trying really hard to break NetWare... Remember the old good days of "DOS isn't done, until Lotus doesn't run"? It looks like Microsoft has a new manta: "Windows isn't done Until NetWare doesn't run".

One of the really cool features of the Novell NetWare Client for Windows 95 is "Automatic Client Update" (ACU). By just putting

#sys:\public\client\win95\setup.exe /acu

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

"Install could not find the class type for device id NWWSMGR"
"Install could not find the class type for device id NWNDPS"

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.

• http://support.novell.com/cgi-bin/search/tidfind er.cgi?2946390
• http://support.microsoft.com/support/kb/articles /q190/6/56.asp
• http://www.trentu.ca/csd/software/netdi.shtml
• http://www2.infoworld.com/articles/en/xml/00/03/ 13/000313enwinupgrade.xml?Template=/st orypages/printarticle.html

--

Re:Be patient, all will come with time.

[Black Parrot]

> There is a time for everything and the time for free software to call the tune is coming.

Truly, it warms my heart to sign up for a mailing list or call up a newsgroup, and see people asking again and again: "Can I run Freeciv on Windows?" "Can I run LyX on Windows?" "Can I run the Bubble Load Monitor on Windows?"

Apparently, free software is not quite so bad as its critics claim.

--

Re:The very nature...

[Black Parrot]

> That is why all the innovation comes from the closed source side.

I'm not convinced that this trend must continue into the future. OSS is now very well placed in the server world, so it should be proportionately easy to provide a standard/protocol/service on OSS platforms that is truly useful, and which the CSS platforms would need to be able to support in order to be sold.

Of course, the easy CSS solution would be to just port the OSS service to the CSS platform, but that's not such a bad thing either (at least in the context of this discussion).

--

Been working on this for over four years

[jonabbey]

I've been working on a directory services management system for over four years now. It works on Linux, BSD, Solaris, AIX, HP/UX.. a fellow here has even got the server running on OS/2. The system's GUI client works on all of the above plus Macintosh and all flavors of Win32.

It's called Ganymede, and it is a metadirectory system, which is to say that it is an object database with a sophisticated permissions system that accepts changes and turns around and updates NIS, DNS, Samba, our NT PDC, our routers, Sendmail, etc.

Ganymede is designed to be a smart server, where the adopter can define their own network schema and write plug-ins that customize how various kinds of objects in the server behave and how they connect to each other. It's all written in Java, so it is quite robust and portable.

It's not designed to replace something like OpenLDAP or DNS or NIS, it's designed to provide sophisticated management for all of the above. At our lab, we have a dozen technical groups that have their own resources, but we share directory services, and Ganymede is what manages the whole show.

It has been a few months since I've made a release of Ganymede, but development hasn't stopped, by any means. Lots of performance and stability improvements on the server have been achieved, and this week I'm writing a Ganymede client that can take XML from external sources (Perl generated, etc.) and load that data into Ganymede. I expect a 1.0pre1 release will come out by the end of the month.

Re:I pray that Linux does not lead the way........

[StanSmith]

"MS either makes standards, or follows them"

I don't know that this is entirely accurate. Microsoft's policy as I see it has been to break standards, and use it's position to force acceptance of the new version.

The lastest fiasco with Kerebros is an excellent example of this, and to a lesser extent WINS as a form of DNS. There are many others.

Martin Burke
My Linux Articles

Integration Is The Issue

[Christopher B. Brown]

You can, indeed, set up all the appropriate daemons to provide all sorts of "standard" services, of which LDAP is certainly one.

The problem is that starting up the LDAP daemon does not intrinsically provide you with any useful functionality. You have to have some separate setup done to put some useful data into the LDAP database.

Thus, it's not terribly useful to have the LDAP server there unless it is usable for (say) user authentication, which would mean that you need some code that pushes data from (say) /etc/passwd into the LDAP database.

Likewise, an LPD server is devoid of functionality until there is some information pushed into /etc/printcap to configure some printers. And from there, for this to be of use to SAMBA users, some configuration has to be pushed into the SAMBA configuration to "publish" the print queues from /etc/printcap there.

There in effect need to be some "self-discovery" mechanisms that search the system for capabilities, and "publish" them as "public" network services.

The big problem with this is that it is likely to defy standardization due either to:

• Local customizations ( e.g. - where I set up some "internal" print queues that are not for public consumption) or
• Local security considerations ( e.g. - where certain user IDs shouldn't get "published" as they are private to the server.)

Re:SLP

[dicey]

This should be moderated upwards. MOre detail?
Its called Service Location Protocol and as far as I know there is an implementation for linux. I don't have the URL to hand - just do a search for it. I think it is linked of the SLP working group homepage on IETF (www.ietf.org).

Integration is the key

[mrfantasy]

I think this is a laudable goal. Coming from a NetWare shop, I've been slightly frustrated that we're *this close* to having a viable Linux client system so that we can use Linux as a base desktop OS.

The issue is making something that won't break in the enterprise environment. You need to be able to have seamless access to Novell and NT servers. Theoretically, both Novell and Microsoft are making it easy by supporting LDAP for directory information, and with some careful work with both samba and ncpfs, you could tie it all together pretty well. This is the issue--I could make it work but don't have the time to write the glue code necessary.

No matter what, for Linux to make it in the enterprise you'll need the ability to make single sign-on a reality, and have the "logon to the desktop" paradigm that the Microsoft desktop OSes support (at least with the Novell client.) To be honest, Novell is working harder at making this working than Microsoft is. Novell's already got the NDS solution on Linux--where's the Microsoft Active Directory implementation?

--Mike

Proc can be a registry

[SurfsUp]

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.

Proc is well on its way to being a registry, except one that doesn't suck. All it needs is persistant storage.
--

Question

[mosch]

I was going to e-mail but it appeared to be a spamtrap. What do you mean, exactly, by 'there is no mandatory locking'? I'm not trying to be stupid here, I'm just not sure what exactly is lacking with regards to available file locking.
----------------------------

Re:Novell Client Integration (off topic).

[ncc74656]

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

That's funny...they had a link on the page for article Q1 90656 that took me to another page from which the updated file could be downloaded. Here's a direct link for netdi.dll. No phone call needed, no $150 spent.

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.

Re:Linux is derivative, not original

[iserlohn]

What you failed to mention, most "innovations" come from academics, not corporations.

Re:I pray that Linux does not lead the way........

[jimfrost]

but Linux, a bunch of 14 year olds, leading the world makes me want to call my mommy.

Maybe you should converse with some of the people doing this work. There aren't too many "uneducated ... hackers" working on it so far as I can tell. Virtually every Linux hacker I know has formal education and works with Linux as a hobby. (And since it's a hobby they're more inclined to do it right than to ship something by June 1st, if you get my drift.)

In the end, though, who cares who wrote it so long as it gets the job done? I mean, you're assuming that the guys who put NT together were well educated, that any education they had was actually useful, and also that even if both are true they'll do a good job. That's a lot of very questionable assumptions, particularly about employees who are known to have built MFC and that brain-dead FIFO page replacement algorithm used in NT. (Ok, the latter made a certain amount of sense on the VAX. But couldn't they have done something better now that they have page reference bits?)

Now, bunches of NT people are sitting there thinking that I'm one of those Linux loonies, and there's certainly some bias on my part towards UNIX, but I was writing articles for UNIX people about the viability of NT back when NT was considered a joke by pretty much everyone in the business. NT is a damn fine workstation OS, particularly in a world where the majority of software is written for Windows, and I still use and recommend it in a lot of situations. Back in 1994 I figured that it'd decimate the UNIX workstation market -- and it did.

So NT isn't poison to me, but I have serious reservations about it as a server, most particularly because its stability isn't so hot, but also because I haven't been all that fond of how much I've had to spend to get extra software to do things that UNIX has done out of the box for years.

Yea, yea, I hear you saying "Win2K fixes the stability problem." So Microsoft claims, and maybe it's even true, but given what it's doing its hardware requirements are a little out of hand and the cost ... well, I think Microsoft is taking a lot of people for a ride. For a lot of server functions you can buy the OS and hardware for less than Win2K alone.

Then again, I'm educated enough to realize that I have a choice in the matter, and perhaps that's the real threat of Linux. It's not the 14 year olds, it's the guys who are smart enough to be comfortable with not using Windows. There are a lot of those guys, both old-timers and recent graduates, in IT shops and software development houses. Those are the guys who made Linux grow so much in the server space last year.

Maybe Linux really is made largely by 14 year olds and I've just not run into them. So what if it is? It's cheap, it's stable, and it has a hell of a lot of functionality. It's not always the best choice for the job, but you're stupid not to at least consider it.

Similarly, sometimes you have to bend over backwards to get Linux to do the job. This is particularly the case for a lot of specialized applications. So look around you and see what works best for what you have to do.

I suspect that for a lot of people that'll be a mix of OSs. It certainly is for me.

jim frost

Re:SLP

[talks_to_birds]

See:

http://www.srvloc.org/index.html

and

http://playground.sun.com/srvloc/slp_white_paper.h tml

for the SLP home page, and an informative white paper.

t_t_b
--

Linux is not all of opensource

[bhurt]

And if you look beyond linux, most networking protocols start life as open source. Consider SMTP, HTTP, TCP/IP, POP, IMAP, DNS, etc.

Leadership: Not neccesarily a good thing.

[jfrisby]

First off, leadership does not neccesarily mean establishing new proprietary ways of communicating with clients. Linux could become a leader in clustering and high-availability solutions. It could become a leader in web application development/deployment platforms/tools.

There are many ways Linux could innovate and jump ahead of the pack. But that's not neccesarily a good thing.

Right now, Open Source has to play catch up because there are serious areas which it is deficient in. It is tempting to postpone development in those areas, or to begin cool new development in other areas but that isn't what we need.

Let other companies take the risks and fight the big battles. I'm more than content to have Linux take the winning protocol/standard/whatever and implement it better than the commercial OS that championed it.

But I don't object to anyone doing what Open Source is about: Scratching an itch. If someone needs a revolutionary new way of sharing data between clients, or a revolutionary new web application platform, be my guest! Innovate to your heart's content. Do it because you need it, but don't do it just because you want to be ahead of Microsoft.

-JF

Plan 9 2.0 is coming

[porttikivi]

Did you know that Plan 9 2.0 is coming soon from Bell Labs, and the main architect Rob Pike?

Plan 9 is the next reasearch version of Unix from the real programmers. Way superior to tired, old Unix clones.

Plan is a distributed, multiprocessor system form the start. It has the most elegant threading model (processes have freedom to share resources like memory space selectively). It's distribution mechanism with procedural file systems and union directories provides language independent, persistent network objects with inheritance.

The new version is more Unix compatible than the old one, which was maybe a little too much for an average non-educated hacker to grasp.

Plan 9 has application programmer transparent cryptographic authentication and security at networked object / file access level. Any set of resources can be set up as a per process file name space to guarantee security of any binary.

Plan 9 also integrates tightly with Inferno, which is a virtual networked OS and VM which is everything Java should have been, and available for a wide range of platforms, including Windowzes and Linux.

http://www.cs.bell-labs.com/plan9/

http://plan9.bell-labs.com/cm/cs/who/rob/

http://inferno.bell-labs.com/inferno/

Samba is not a "linux community" project

[Medievalist]

The Samba team likes Linus, is all in favor of Linux, but they PRE-DATE the linux community and are compatible with many other systems. Although I cannot officially speak for them.
In fact, there was briefly a Samba for Netware downloadable from Netware.com - for people wanting to convert from NT to Novell - but it has been removed it from their site because people were using it to convert from Novell to Linux/Samba!
LDAP with a NDS back end is becoming the industry standard these days - all its competitors are in fact imitators - but there's no reason the linux community couldn't make an LDAP/mySQL bastard that would serve the same purpose without the annoying per-seat licensing costs.
Bob Hart stated (at Brainshare in Utah) that Red Hat would be very interested in funding development of open-source directory software, preferably with broad compatibility via LDAP.
Jitsu (author of Pandora's encryption logic) could probably clone NDS if sufficiently motivated/funded. Not that I speak for him or NMRC either.
--Charlie
I am the Lorax, and I speak for the trees.

Why textfiles for configurations is not an option

[Stefan]

The current situation with .dot-files scattered all around the place works somewhat well when only a single person uses a non-networked computer.

In any bigger networked system, with several servers, clients, networked printers etc you want one single unified system for configurating everything. You need to store the information in some kind of distributed database, for example with LDAP. Textfiles aren't up to the task because:

• Insufficiently flexible permissions for modifying the configuration, either because filesystem lacks acls, or whole files are not granular enough.
• Difficult to inherit/replicate configurations, for say 20 identical clients.
• Textfile configurations easily end up getting typos, inconsistent or duplicated data. A configuration database could be typed stronger and check referential integrity.
• Allows for for a flexible permissions system, let a user remove printjobs from the printer on his desk, or a teacher add user accounts for her classes on a certain server or user group.
• Administrate everything without needing to log on to a dozen computers editing files all over.
• 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.

Novell's NDS does pretty much all of this correctly, but it needs some "fixes". The free software community needs (and the rest too) something that's just that, free as in both speech and beer, and not based on proprietary standards. That way all software can gradually move over from using the good old textfiles to a new better system for the long run.

Linus's idea with plain text files as an interface for configuring the kernel is still great, it's an easy way to interface with the kernel, easier than binary files in /proc or ioctls. We just need a user-space "configd" that reads configurations from the global database and then writes that to the various /proc-files whenever the configuration database is changed, or maybe even reads /proc-files when dynamic parts of the configuration database is read.

The case for text and files for config data

[DragonHawk]

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.

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 /etc/fstab file, I can fire up emacs and fix it.

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 .dot-files scattered all around the place works somewhat well when only a single person uses a non-networked computer.

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.

... or whole files are not granular enough.

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.

... or a teacher add user accounts for her classes on a certain server or user group.

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?