You'll always hear guys praising UNIX, maybe even with no sufficient experience that qualifies them to do so (I met some of these guys). Though, I have nothing against what's said about UNIX being more secure, reliable, professional... I even have no enough experience to judge that!

Guys I mensioned above keep saying that MS Windows is crappy, unstable, not well-planned... again, with no good experience to say so.

What we should admit is that both have their pros & cons:

for example, UNIX is made before Database concepts evolved, and SQL came out years after UNIX. (correct me if I'm wrong)
So, most of the settings in UNIX (if not all) are simply stored in text files & you should know their formats to become a good Administrator! I don't know what does this have to do with POWER?! Remember that the 1st lecture in any Database course speaks about the advantages of Databases over using formatted text to store records.

On the other hand, Microsoft came out with registry instead (which I consider as a badly designed Database system though!)

A major advantage of MS Windows is that its elements are easy to learn, use, & "spell"! I don't know why names of everything in UNIX have to look like Passwords!! I wonder how UNIX programmers cope with functions having all letters lower case, no Hungarian notation for variables... ?! Is this for the sake of professionalism? Do I have to get an RPM & do a long procedure just to install something?! ...

Another good thing Bill Gates made years back, is the concept of file "extension" (name & extension). I don't know if other OS invented it before MS, but definitely not Unix.

On the Unix +ve side, you can create many user accounts (& generally automate Administration) using simple scripts. And it must be true that Unix-based systems are more secure & reliable than Windows (I don't know why this has to be a rule applicable to any Unix-based OS, & to any version in Windows? I mean what's magical in Unix's inner structure & what can't be cured in Windows' structure?)

I also would like to know how far did Win2003 succeed in reducing gap between Windows & Unix (regarding stability & security).

So, do we need a new, powerful OS that learns from errors of its precedents? Or a successful new OS has to be a child in the Unix family?

For example, I have an idea about something like a SQL OS:

Isn't a great part in a modern OS, specially concerning multi-user environments, evolving around "tables"? Examples are users, groups, network resources, file system ... Can't we instead of scripts or wizards, use SQL to add users, search for files, resources, ...? As a +ve side effect, SQL is a well known language, so not a big deal to adapt to this new OS.

These are just some thoughts that I couldn't hold inside no longer :)
Posted on 2005-01-11 10:32:24 by John Kiro
Well, it might sound like a nice idea, but an OS is not a database. There may be an OS that is "database-like", but it would be highly specialized.

I think you may be deriving the idea from some of Microsoft's philosophies. You used the registry as an example. You could also use Active Directory as an example. Microsoft has been trying to pin down a sort of "object-oriented" database model for their systems for quite a while. Now they are trying to do it with their .Net Assembly systems to make the OS "object-oriented". They have also been trying to merge their applications into that objective core of the OS. It sounds nice, but all I've seen is bloat and waste. Works great for the VB programmers out there. :)

What you may not have seen is that Microsoft has been slowly incorporating Unix-like features in their operating systems for the last two decades. In fact, Longhorn is supposed to move some degree closer to the Linux modular-type kernel to reduce reboots.

If all you are working on is databases, then a database type OS is probably a good idea. Oracle CEO Ellison has been spouting this for quite a while.

My preferred OS design is going to give me the flexibility to do many things on my computer. I can play games or use databases. I don't want the bloat of a database type OS to play my games on. And if I only wanted to play games, I'd probably go with a game type OS similar to what's available on gaming consoles.

Right now, I have the flexibility to do whatever I want.
Posted on 2005-01-11 15:09:11 by Kdr Kane
Unix:
the idea that everything must be built from "simple components". Has the pros that you can do very powerful things from the commandline with the use of pipes, but the disadvantage that it takes quite some time to master this. Represents devices in the filesystem, which allows you to do some "funky" and useful things, but typically lacks nice tools and config as known from windows.

The text-file-config stuff from the *u*x world is a mess. There isn't really any standard for config format or type of names used, so you'll have to learn a lot of different file formats. Furthermore, where things are stored differs from unix to unix, and even a lot between the various linux distributions. Of course there are some graphics (and textmode UI) based config tools, but... well, nothing of windows standard, really.

The "everything must be short names" of unix is also quite crappy. I guess they focus more on being able to write code fast, than being able to read the code later on ;). On the other hand, the ALLCAPITALLETTERSLOTOFHUNGARIANNOTATION types in windows.h isn't my cup of tea either - both are pretty outdates. I like the Win32 API function names, though. I also think the win32 api is a bit messy, partly because of the win16 backwards support, partly because different parts of the API are written by different divisions in Microsoft - it's not coherent, and especially the shell routines are awful.

File extensions are indeed nice. Yes, you can identify filetypes by their headers, and you could have an OS use metadata (like Mac OS), but I do think file extensions are a really good thing. It's easy to get a listing, move files around, etc.

It's true that unices are usually pretty stable. But come on, how much does it take to run a textmode webserver with only simple hardware support? ;). It's worth noticing that there are win2k servers with multiple years of uptime as well, so it really depends on your hardware, competent sysadmins, and a good firewall. On the security side, NT has a *lot* more flexibility in it's user+group system, because of ACLs.

Windows NT is probably one of the best-planned kernels around. It was designed by some very skilled people with some very good technical background. The NT model is far superior to the unix model, the driver model allows for higher performance, et cetera et cetera et cetera. Read "inside windows 2000" or "inside windows XP" and this will become very appearant.

The problem with windows is the rest of the OS. The shell designers must be smoking some particularly nasty crack, to come up with all those bugs and security holes. Same goes for a lot of usermode code.

Btw, the registry isn't that bad. It's the usage of the registry that's bad. The registry itself is relatively fault-tolerant, and it's very fast to look up keys and values (binary searches and such).

I think the ideal would be somewhat along ripping out the Win2003 kernel and drivers, and writing the shell and usermode apps from scratch :)
Posted on 2005-01-11 18:16:26 by f0dder
> Btw, the registry isn't that bad

The best thing with the registry is that you can export the whole stuff to a text file and use your favorite editor for changes to make.

The registry is a miss-concept. the unix config files are a mess to some degree, but I really prefer config data in the file system.
Posted on 2005-01-12 13:55:46 by japheth

The registry is a miss-concept. the unix config files are a mess to some degree, but I really prefer config data in the file system.

Why? The registry is nice and centralized, and faster than using plain text files (not that speed matters much for config, but still :))
Posted on 2005-01-12 15:13:45 by f0dder
why misconcept?

some things which may come to mind:

- not as transparent as text files
- not accessible by dos programs.
- regedit's edit capabilities are pretty limited
- needs to be backuped on system startup, thus increasing boot time

the only advantage compared to individual config files is the centralization issue. But will the end user notice this as an advantage?
Posted on 2005-01-12 16:11:24 by japheth

not accessible by dos programs.

Is this an issue in 2005? ;)


regedit's edit capabilities are pretty limited

Limited how? It's true that manual editing of a lot of a lot of registry keys could be somewhat tedious, but of course you could always do the editing in a .reg file and import it ;)


needs to be backuped on system startup, thus increasing boot time

I don't feel any noticable speed issues on boot, and XP boots as least as fast as linux on my box (and that's XP to full GUI, vs. linux to console). Not to mention that I don't reboot my box often, usually only when powering it on (I shut down when sleeping).


the only advantage compared to individual config files is the centralization issue. But will the end user notice this as an advantage?

Perhaps the average user won't notice this, but admins and power users certainly do. And then there's the benefits of much finer-grained access control, automatic support for per-user settings (because of HKEY_CURRENT_USER), and really fast lookup of data (because of the search algorithms).

The only thing I dislike about the registry is that some applications mis-use it, and that some things should have been placed differently... ie, don't have filetype associations and CLSIDs et cetera in one big key.

There are a few types of applications where I prefer separate config files, but for most stuff, I am very happy the registry was invented...
Posted on 2005-01-12 16:57:59 by f0dder
I will like to continue reading comments about centralization/decentralization for what is best centralization for admins and power users? how do you define a "power user"?

Also for Japhet how do you define "transparent as text files"?


Im not a expert of registry, even know much how is constructed and havent used it.

But I will like to know opinions about:

"benefits of much finer-grained control", my question is for what is not posible with config files?

"automatic support per-user settings", is not posible with config files?

Question: How the3 applications mis-use it? and what things should be put diferently?


for what is used registry? for what are used config files? and the porpuose of them?

I supose that some way if you "join" config files you have what the registry is?? or if you extract some things of the registry you obtain config files???


If you have the time or whant to answer doit ;).

By the way, this will turn the topic in a thing more related to config files and registry, you can open another thread if is necesary?
Posted on 2005-01-12 21:14:49 by rea
Centralization means you only have to look one place for configuration items. Of course you have to look at multiple places in the registry, but I do find this handier than GREP'ing config files (espically because they can be in a multitude of different locations).

I'm a power-user - I'd say all programmers are. Some non-programmers are, too. I'm not going to try to come up with a definition, but people using the task manager, installing a "command prompt here" context menu item for folders, etc...

Fine-grained controls means that you can, with NT ACLs, define access control per registry key, value, etc. Very powerful stuff.

As for automatic per-user settings with text files... that would require extra code in the application, and would end up being done ad-hoc with various different methods in different apps. One solution often used is storing .config files in the user home folder - this means even *MORE* places to look for config items, while the windows registry has HKEY_USERS (HKEY_CURRENT_USER maps to a subkey under HKEY_USERS).

I guess it could be an idea to split off the registry-vs-config files into a separate thread (and put a link to it here).
Posted on 2005-01-12 21:26:59 by f0dder
> Is this an issue in 2005?

Yes, it is. At least for non-GUI apps. And I can well remember the times when the registry was "corrupted", win9x refused to start and I was really missing a dos tool to view the registry and see what's wrong

> As for automatic per-user settings with text files

Now that's surely trivial to implement.

> but of course you could always do the editing in a .reg file and import

:grin:

> Perhaps the average user won't notice this, but admins and power users certainly do.

Obviously I'm no power user. Too bad.

> Also for Japhet how do you define "transparent as text files"?

Simply that it is much harder to "hide" something in text files than in the registry. Any usually you can easily tell which config file belongs to what app, but for the registry this isn't always true, to say the least.
Posted on 2005-01-12 23:20:57 by japheth

Yes, it is. At least for non-GUI apps. And I can well remember the times when the registry was "corrupted", win9x refused to start and I was really missing a dos tool to view the registry and see what's wrong

Ah, Win9x - I'm not taking broken OS'es with really bad filesystems into account here. But yes, registry corruption can happen easily on 9x, and that *is* bad. Never happened to me on NT though, even with driver BSODs.


> As for automatic per-user settings with text files
Now that's surely trivial to implement.

Indeed, but it has to be done for every application. It's trivial on unix, use something like "~/.appname", but that is once again decentralized.


> Perhaps the average user won't notice this, but admins and power users certainly do.
Obviously I'm no power user. Too bad.

I'm pretty sure you are, you just have different taste than me ;).

Of course there's some merit in decentralized config - it's very easy for a user to back up all his stuff by just backing up his home directory or whatever. But then again, it's not like it's very had to back up a registry branch, so... *shrug*



Simply that it is much harder to "hide" something in text files than in the registry. Any usually you can easily tell which config file belongs to what app, but for the registry this isn't always true, to say the least.

That's a problem with mis-use of the registry indeed. It would have been nice with some restriction on where applications can put their stuff. Most apps are well-behaved, though...
Posted on 2005-01-12 23:30:30 by f0dder
I think a centralised config would be a good idea, but not a registry. Maybe just a centralised place to throw your textfiles. I think the problem with unix is that there is so many coders and no one to organise them. :wink:
Posted on 2005-01-13 06:07:44 by roticv
If you disregard the proprietary Unixes, then you can go with Linux distributions that comply with the Linux Standard Base.

LSB compliant applications and Linux distributions set the standards for locations of config files and such.

It doesn't sound like some of you are aware that ACL filesystems are available in Linux and provide the same or better functionality than that provided by Microsoft. Of course, the subject was about Unix, not Linux.

The problem with Windows is that programmers have been writing applications primarily for Win9x users versus NT-type Windows. Thus, the programmers always assume - or - even require that the user have administrative rights in order to run the application.

This is not true for Unix/Linux. Maintenance and administrative tasks must be run with root privileges, however normal work is always assumed to be done without elevated rights.

You want a test? Just make a new account on your Windows XP machine with "User" rights only, no administrative rights. Browse the internet anywhere you want. You will not get any Spyware or Adware invading your machine under such an account. Feel free to peruse your email once again without worrying about infection.
Posted on 2005-01-14 00:20:30 by Kdr Kane