Unless you are smoking crack while you're designing programs, you won't use registry as a database backend to your application.
So application developers should roll-their-own instead of using the system-provided functionality ?
Registry should contain configuration data, which is read during application startup and the few milliseconds of additional overhead from parsing plain text should not matter at all.
How about on-the-fly configuration changes ?
In the human point of view, parsing the plain text files is much more efficient operation than parsing some massive binary file through some obscure interface.
Indeed. Typically, however, you miss the point - the user *shouldn't* be trying to parse "some massive binary file" any more than they should be directly editing text files. At least the former system discourages it.
As experience shows the root user owning global configuration in/etc and user owning its own configuration in/home/$user is sufficient.
Yeah, and those silly GUIs will never catch on, either.
Is there really a need for different permissions on every line of configuration? This smells like bad application design, nothing more.
I imagine your alternative for fine-grained administrative access is thousands of text files, each with unique permissions, included from some great big master configuration file somewhere ?
Wow! Simply -- WOW! Well, i wouldn't replace the text configuration files with anything, but we seem to come from different universes.
Indeed, I'm interested in improving the systems I have to work with every day. Hand-editing fragile, inconsistent, often poorly documented text files - or primitive automations thereof with tools like sed, awk, perl and others - *sucks* as a way of managing system configuration. It's fragile, error prone and requires specific, esoteric knowledge.
How about storing the "evil" text configuration files (IE the whole/etc directory) in CVS or in some other full-blown revision control system? Try this with some obscure binary format.
You build the revision system into the system for accessing and modifying the "obscure binary data".
I have to wonder, if text files are so good, why do we have databases ?
You don't get fine-grained permissions with a single registry file (well there are two under windows: system and user).
Try to think outside the unix box for a change. Registry ACLs are implemented within the Registry database itself.
Registry is a compressed file that is stored uncompressed in memory, and you need to recompress the whole file each time you are ending a windows session (however there are maybe periodic saves).
Given you don't even know what registry ACLs are, I'll take your critique with a grain of salt. The registry is just a database and operates like any other database.
I suppose the GP thinks about packages management. [...] (Un)InstallShield doesn't allow the latter.
Neither does a package management system if an app doesn't tell the package about everything it does.
However, a large majority of windows applications are ill-designed (including MS ones) and requires admin privileges, sometimes writing config files in "program files" instead of the user's directory.
The number of these programs is consistenly dropping - and it _isn't_ a Windows problem, it's an application problem.
Note also that applications writing to the wrong place does *not* require full-blown admin privileges to remedy, merely an appropriate modification of the specific file, directory and/or registry key.
It seems you haven't a lot of Un*x experience.
On the contrary, I have a great deal of Unix experience. It is, after all, part of my career.
Why would anyone need per-line access control ?
Complex environments with requirements for multiple levels of administrative privilege and responsibility.
Config fileS are in different files, each one with its own rights.
What do you do if you want to assign the ability to configure different aspects of an application whose configuration is contained within a single monolithic text file ?
The standard hack around this in the unix world is to start breaking those config files up into sub-files, typically stored in a single blah.d directory, thus adding to the complexity and inconsistency already typical to unix configuration management - this is assuming the configuration data structure even allows this.
Note that I don't think they're doing it : AFAIK you have read/write access to your whole own registry, and read acces to the whole system registry.
Default permissions != possible permissions. Registry ACLs can be as fine grained as filesystem ACLs.
I think the GP meant the reverse. That is, with windows registry, only the program has a clue about what its keys are meaning, so it is often the only one to modify them.
As it should be.
With a text config file, you can put comments and the user can modify them if he wants to.
You can put comments into the Registry if you so desire. However, like most "the unix way is the only way" people, you seem to have a great deal of trouble thinking outside the unix box.
The whole *point* is that the user/doesn't/ directly edit the Registry, but does so via a configuration tools. This allows for proper input validation, consistency checking, automation without having to use fragile, error-prone text-parsing, context-sensitive help, etc.
Direct editing of fragile, inconsistently structured configuration data, with no inherent input validation, type checking, syntax checking or consistency checking is a really bad way to manage a system.
System Restore isn't fine-grained : it's all or nothing, like the sibling AC wrote.
Which is precisely why I said it was a good idea. It would be very nice to have an automatic revisioning system built into the registry - although it would have to be configurable on a per-key basis.
I would add that with a Un*x, if you f***d up a config file, you just need to delete it.
As a side note, Windows also has a per-user "Library" directory named "Application Data".
This is true, but it's not officially meant for storing user preferences. User preferences (and similar "configuration" data) are meant to be stored in the registry.
That said, many applications do store config data here - particularly those being ported over from other OSes that do store configuration data in the filesystem (eg: iTunes, Firefox, Thunderbird).
IBM made sure you could run nearly all win32 and most 16 bit DOS and windows software, as well as OS/2 software. I fully expect Apple to do the same with their x86 Macs.
Nitpick: OS/2 only officially ran Win16 apps, although there were some later hacks to get some Win32 support.
OS/2's Windows and DOS support are also widely credited with its lack of developer support, so don't be too quick to assume OS X will go down this path (personally I'd be amazed if they do).
2nd - my wife's SE (same CPU speed as my 128KB Mac I bought in 1984) is quite a bit more sluggish than the G5 at work when working from a floppy --- perceived response is about the same from the HD).
I do hope you realise how _badly_ that reflects on the OS X Finder...
Miller column file browser (I suppose you could use http://www.winbrowser.com/ 'cept that last time i tried it it crashed, a lot)
Interesting you bring that up, because IMHO Column View _sucks_. I don't think I've ever experienced a worse way to navigate and manage files. Even the MacOS Classic Finder style, with its masses of screen clutter, clumsiness when dealing with non-trivial directory structures and poor keyboard shortcut support was better.
IME, the most efficient method for GUI file management is a directory tree+file listing (or two) and some decent keyboard shortcuts (something the Mac still lacks).
no convenient place for temporarily storing a folder one needs temporary access to
Try dropping a shortcut to the folder in the Quicklaunch bar on your Taskbar.
Of course, this is just a crutch to get around the simple fact that the Finder doesn't make moving files around - when you don't already have access to the source and destination - quick and easy, because it lacks an equivalent to "Cut" in Explorer.
the Dock affords one a single place to launch and switch applications --- why is it that in XP I click in one place to launch (the Start Menu) but use another area (the Task Bar) to switch --- in Mac OS X I click on the same icon either way.
The Dock (particularly in its default configuration) is a UI train wreck. Icons move around. Any remotely similar minimised windows are impossible to distinguish from each other. Windows can get their corners "caught" behind it making resizing annoying. Drag & drop is inconsistent with other parts of the UI. Icons representing very different things are thrown together at will.
(Expose was one of the smartest things Apple ever came up with. Not so much because of how it makes task switching so easy, but because it distracts away from how bad the Dock is at what is was supposed to do.)
The Taskbar certainly has its problems, but it's much better than the Dock.
Lots of other niceties in Mac OS X such as Services, pervasive.pdf imaging / display, memory management (there was a guy asking after loading apps from a RAM disk on an InDesign mailing list 'cause in Windows XP he couldn't keep large numbers of apps open for extended periods of time and wanted to be able to launch them more quickly than his RAID 0 array would allow), pervasive drag-drop &c.
Services are nice. The PDF imaging is also good. I can't speak for the specific example of MM, but getting a similar user experience in terms of responsiveness requires a much less powerful machines for Windows than OS X. Drag & drop has more than its fair share of weird and wonderful quirks in both. There I things I expect to be able to do in OS X (because I can do them in Windows) and vice versa.
(who really wishes Windows XP was well-suited enough to his working style to allow him to justify purchasing a Tablet PC)
Funny, when I sit in front of a different OS I simply modify my working style to take advantage of the way it works.
getting file sharing to work on a windows desktop is a non-trivial PITA:
Right click [any] folder -> Share.
Contrast this to an OS X desktop where sharing arbitrary folders really *is* a non-trivial PITA.
look at the process you have to go through to add an IP printer, and you'll see what I mean (for Heaven's sake, why is an IP Printer a "local" device?)
Way to change the subject (within the same sentence even).
1. There was no benefit to making the registry a non-text file, [...]
There are a lot of good reasons why the registry is better than a text file. Performance and fine-grained permissions are two.
[...] except that MS wanted to make it more difficult for end-users to poke around and understand more clearly what's going on
Yes, because a system encouraging manual configuration no input validation is such a better alternative.
Users _shouldn't_ be directly editing the registry. Ideally, users _shouldn't_ be directly editing text files in/etc, either. This is not to hide anything from them, it's so they don't break the system by making a typo.
Manual editing of text files is an incredibly bad way to configure a system by just about every measure thinkable. That there are few _better_ methods does not change this.
Applications do have to use the OS to read/write/update (so far so good), but the OS *never tracks what the application puts there*. As a result, every developer puts their copy protection in obscure keys in the registry. Even worse, and unforgiveable, are applications that leave crap behind.
Neither does any other OS I can think of - so what's your point ?
Make it impossible for an application to write to c:\windows or c:\windows\system32 or... you get the idea
They can't unless they're running as a user with sufficient privileges - just like every other multiuser OS.
Registry files should be stored locally in the directory the application was stored in, or better yet in "My Directory". The system would have its own registry stored in the system directory.
The user's registry hive is stored in their user profile. The system registry hive is stored in the system directory. Ie: it's already the way you want it.
They should be text files that can be copied by the user easily using standard tools.
How are you planning on implementing per-user, per-value ACLs on lines of text in a file ? How about making sure modifications don't end up half finished ? Are you aware parsing text is an incredibly inefficient operation ?
When a program is uninstalled, the OS would ensure all traces of the registry entry are deleted (this is easy because of #2)
But how to deal with poorly written applications that don't tell the OS everything they do ?
The only thing allowed to alter a program's registry entry is that program.
Funny, I would have thought you'd want to allow the user to manually manipulate arbitrary registry settings.
And every time its altered, a new version is kept. This would allow users to go back to old version if required.
This is about the only decent idea you've managed to come up with. Mind you, similar functionality is already available via System Restore points - but I imagine people like you automatically turn them off because you "don't like stuff going on behind your back".
A user could tell the OS to lock a registry so that nothing can alter it
Like they could now with ACLs, you mean ?
The system registry could never be altered by any application.
Regedit ? Control Panel ? How about applications that want to make system level changes for legitimate reasons ?
Requests to modify would require the root password entered by the user. Every time.
Because I'm sure the user will understand the implications of modifying arbitrary registry keys and will give nearly two full seconds' careful and considered thought before typing in their password.
3. Security. I don't have the link on me but it's been shown that OS X and other FreeBSD derivatives are the most secure operating systems on the planet. There was an article on slashdot a few months ago about this, but I'm too lazy to search for it. Windows security... heh, oxymoron.
When OS X has a 95% market share, comparing security track records is a valid proposition. Not before.
System Preferences application. This is similar to the Windows "Control Panels" folder, except it is so much better. Try getting windows to run an FTP server, or an HTTP server, or an SSH server, or...:-) All with two clicks! (Sharing -> click checkbox for the service of your choice). Easily protect yourself with a powerful firewall (even though you really don't need it, heh).
And in Windows I can turn of some of the graphics heavy effects if I need to. That they offer different configuration options doesn't make them better, it makes them different.
9. No viruses or spyware. 'nuff said.
Yet.
NO REGISTRY! I've seen many a 3.4 Ghz P4 system cripled to the equivalent of a 300 mhz Celeron because their registry (an unbelievably stupid concept) was fscked.
Yes, OS X is much better because it drags your dual 2Ghz G5 down to the level of a 500Mhz G4 running Classic.
I've been running NT for nearly a decade now. I'm still yet to see any of these registry problems that apparently plague every installation of Windows ever done.
Instead of the registry, OS X has an intelligent method of organizing users's preferences. They're all located in a... single folder.
You mean like in Windows how a user's preferences are all located in a... single registry key ?
Intelligent user organization scheme - Because OS X has real, actual unix permissions (unlike windows), [...]
NT's permissions system is vastly superior to "unix permissions".
[...] it is by default very secure on a multiuser system, with excellent user home folder organization.
Hey, just like Windows.
There's a System Library folder where system prefs are located (protected by permissions), and a Library folder in each User's home directory.
HKEY_LOCAL_MACHINE, HKEY_USERS_[UID].
This makes moving from one system to another and backing up data really easy.
I could go on... but like I said in the other post, you should just learn more.
I already know a great deal about Macs, that's why I bought one. It would appear, however, you don't know much about Windows. Don't feel bad though, most people who criticise Windows haven't got a clue what they're talking about.
That wouldn't excuse a thing, even if it were true.
Actually it does, because "acceptable behaviour" is a matter of opinion, not an absolute measure. When "everyone" behaves the same way, at least within their sphere, that makes such behaviour acceptable.
But it's not true. They have behaved shamefully, and to a worse degree than other companies. Perhaps it's only because of the power they wield, but they have behaved in a shameful manner.
Bollocks. They've done nothing worse than any other company of any size. They've gotten into more trouble for it, to be sure, but that's a different issue from their actual behaviours.
Just because there are awful corporate actions elsewhere doesn't excuse a thing Microsoft has done.
The objective is not to excuse, because personally, I don't believe they've done anything that really needs "excusing". They play their business just like most big companies - ruthlessly. If that bothers you greatly, you need to be attacking the entire corporate ethic, not just one particular manifestation of it (ie: Microsoft).
Get some manners.
People who think Microsoft is somehow different to every other company out there don't deserve manners, they deserve to be slapped.
People like the OP claiming "paying attention" is all it takes to be "anti Microsoft" are acting hypocritically, because they're either judging from different standards, or only "paying attention" to Microsoft.
Lots of people here on/. (which may or may not inclide the OP), who seem to think Microsoft is the Great Satan, the personification of evil or the poster boy for corporate misbehaviour need to get some perspective.
This deficiency is not due to insufficient design, it's due to fundamentally flawed design which cripples Windows in the server market.
I'm not a developer so I'm not in a position to argue the specifics, however, Windows is hardly "crippled" in the server market. Indeed, it's probably one of the most popular platforms out there.
What you have neglected to account for however is the cost of rebooting those machines, specifically in money, time, and frustration.
No, I haven't. If scheduled downtime for a server reboot is a major issue - in money, time, frustration or anything - your architecture is flawed. Added to that, if your machines or software are that unreliable that this happens regularly, you've got much bigger issues to worry about.
In our specific case, every time we want to update our London clients, it costs between 4 and 12 man hours, most of that for an IT guy working overtime to stand around in case he needs to manually reset a server.
Sounds like both your architecture _and_ your processes are flawed. You shouldn't need someone on-site to reset machines if they don't reboot - lights-out management tools that can do this are commonplace.
Compare this to our Linux procedure: 1) shell in, 2) update software, 3) run diagnostic.
There is no reason you can't do this with your Windows machine as well, that Windows is to blame for.
Since when has Microsoft been in the business of raising the bar on software? Since Win98, they haven't done much in the way of drastically new technical capabilities.
No-one's done anything particularly "drastic" in the last couple of decades. Singling Microsoft out is hardly rational.
However, that's irrelevant to the topic at hand. Prior to OS X, Apple's OS was 1 - 2 generations behind the competition. With OS X, it is on par. That change happened in the space of a couple of years.
The point is that just because WinFS isn't here today, doesn't mean it won't appear in 18 months and be vastly better than any of the alternatives.
OS X is a superior Desktop OS in every way that matters outside of the games shelf at Game Stop.
Its performance is still mediocre at best.
I would also imagine its hardware scalability is relatively poor (based on its overall poor performance and its much briefer time on multiprocessor hardware).
Accessing network resources is clumsy (and often unreliable)
The Dock is a UI train wreck.
Finder is awful.
Windows does filesystem-level encryption and compression better.
Then there's the indirect aspects:
Games, as you mention. Indeed, software in general.
OS X needs more expensive hardware (and hardware options are far more limited).
Linux (and the BSDs for very specific applications) is a superior server OS (this is not a corner case).
Sorry, it's not that simple.
Windows is better for fileserver to Windows clients (things like share caching, shadow copies, clustering).
Exchange
Centralised management of Windows clients (ie: Active Directory and Group Policy)
From everything I've read and heard, IIS6 and friends are superior to Apache (and friends) for web serving and site development.
For most other things, Windows is at least on par.
Now, the things Linux does better are generally because of its greater customisability to deal with corner cases, *not* general purpose use. One thing Linux does clearly do better than Windows/in general/ is storage management. LVM and Linux's software RAID are excellent - which is why we're rolling our own SAN with Linux and not Windows Storage Server.
Added to this, Linux's often $0 upfront cost has a tendency for people to think it's cheaper, even if their TCO ends up higher. Of course, by the time you're in a position to do a worthwhile TCO evaluation, you've generally got too much invested one way or the other to switch anyway.
However, as I said previously, no OS is so far enough ahead/on average/ that any of them can be considered outright superior (or inferior).
I use a Mac laptop, my work machine is Windows and I'm a Sys Admin. I daresay I'm in a fairly good position to be able to observe the strengths and weakness of the major platforms.
The problem is that the US political system is the most corrupt political system in the world. What do you expect when it is bribery set in system?
It seems you have about as much experience as the submitter ("Microsoft has unparalleled influence throughout the Federal government." WTF ? Compared to who ? The GNAA ?).
Compared to governments with actual, endemic, systemic corruption, the US government is a shining beacon of honesty - and I'm not exactly a big fan of the US at the best of times.
Microsoft astroturfing. People who scope out anti-Microsoft talk and mod down accordingly.
Of course, all you have to do to be an "astroturfer" on Slashdot is post sane, balanced, factual viewpoints than don't criticise or blame Microsoft for all the world's woes...
You forgot the 3rd option: more people whose entire lives don't revolve around hating Microsoft are reading Slashdot.
Microsoft has this philosophy of supporting features like RSS in the lowest levels of the OS, in ways no sane person would even consider, never mind implement.
I can imagine some scenarios where an RSS feed of code might make sense (e.g. an RSS feed that delivers the latest version of the installer for a program that you use, so that you can keep current automatically), but for sanity you'd want to only execute code when the user explicitly initiates the action, and put up some sort of warning.
Like those email attachments the user has to specifically launch, that warn launching them might be a bad idea (with the default set to "don't do it" ?
Microsoft has this great idea with Windows 95 that things should be "document centric"; you don't open an application to print a document, you drag the document to the printer! Magic!
I find it laughable you blame this UI paradigm on Windows when MacOS and OS/2 were doing it (and advertising it) _years_ beforehand (and the concept itself is even older). Microsoft were 5 - 10 years late to the pervasive drag & drop, sorta-object-oriented, document-centric interface, yet somehow it's their fault ?
For shame - your bias is showing.
Behind the scenes Windows will silently open the application, feed it the data, and a command telling it to print to the printer.
So does OS X. So does KDE. So does GNOME. So does every other remotely modern GUI released in the last 10 - 15 years. What's your point ?
Windows can be told instead to execute the data as code, [...]
If the app has a buffer overflow, maybe - but Windows hardly has a monopoly on buffer overflows.
Fanboys? All you have to do in order to become anti-Microsoft is pay attention.
Only if you're a biased 15 year old with a worldview about as wide as a pencil.
Microsoft behave much the same way every other company does in the computing world. The only difference is their actions have a much wider impact than most others (within the computing world).
If you want to get into a global scale and move outside of the computing world, Microsoft are practically a *saint* in comparison to the/real/ "big nasty corporations. Thousands of babies have not died because of a deceptive Microsoft marketing campaign. Wars have not been started because Microsoft wanted to make some more money.
And that's why Apple is smarter than M$...by not integrating it into the OS in a stupid and unneccessary way they can avoid some degree of exploitability.
Hate to break it to you, but IE is no more "integrated" into Windows than Safari+WebKit+WebCore is into OS X.
There is zero reason to believe a Microsoft RSS "reader" will be any more "integrated" into Windows than the OS X one is into OS X.
Last time I checked, Safari had RSS support and iTunes 4.9 had podcasting but OSX itself didn't integrate RSS & podcasting into the kernel or os space...
1. Define "OS Space".
2. What on Earth makes you think Microsoft will put an RSS reader into kernel space in Windows ?
For home use, this may not be a big deal, but in a production server environment it's a grevious flaw.
If a scheduled downtime window is an issue, then your architecture is flawed. If you don't even *have* scheduled downtime windows, then your processes are also flawed.
Your other examples sound suspiciously like "but it's not like Unix !" complaints.
Slashdot Mirror
So application developers should roll-their-own instead of using the system-provided functionality ?
Registry should contain configuration data, which is read during application startup and the few milliseconds of additional overhead from parsing plain text should not matter at all.
How about on-the-fly configuration changes ?
In the human point of view, parsing the plain text files is much more efficient operation than parsing some massive binary file through some obscure interface.
Indeed. Typically, however, you miss the point - the user *shouldn't* be trying to parse "some massive binary file" any more than they should be directly editing text files. At least the former system discourages it.
As experience shows the root user owning global configuration in /etc and user owning its own configuration in /home/$user is sufficient.
Yeah, and those silly GUIs will never catch on, either.
Is there really a need for different permissions on every line of configuration? This smells like bad application design, nothing more.
I imagine your alternative for fine-grained administrative access is thousands of text files, each with unique permissions, included from some great big master configuration file somewhere ?
Wow! Simply -- WOW! Well, i wouldn't replace the text configuration files with anything, but we seem to come from different universes.
Indeed, I'm interested in improving the systems I have to work with every day. Hand-editing fragile, inconsistent, often poorly documented text files - or primitive automations thereof with tools like sed, awk, perl and others - *sucks* as a way of managing system configuration. It's fragile, error prone and requires specific, esoteric knowledge.
How about storing the "evil" text configuration files (IE the whole /etc directory) in CVS or in some other full-blown revision control system? Try this with some obscure binary format.
You build the revision system into the system for accessing and modifying the "obscure binary data".
I have to wonder, if text files are so good, why do we have databases ?
Try to think outside the unix box for a change. Registry ACLs are implemented within the Registry database itself.
Registry is a compressed file that is stored uncompressed in memory, and you need to recompress the whole file each time you are ending a windows session (however there are maybe periodic saves).
Given you don't even know what registry ACLs are, I'll take your critique with a grain of salt. The registry is just a database and operates like any other database.
I suppose the GP thinks about packages management. [...] (Un)InstallShield doesn't allow the latter.
Neither does a package management system if an app doesn't tell the package about everything it does.
However, a large majority of windows applications are ill-designed (including MS ones) and requires admin privileges, sometimes writing config files in "program files" instead of the user's directory.
The number of these programs is consistenly dropping - and it _isn't_ a Windows problem, it's an application problem.
Note also that applications writing to the wrong place does *not* require full-blown admin privileges to remedy, merely an appropriate modification of the specific file, directory and/or registry key.
It seems you haven't a lot of Un*x experience.
On the contrary, I have a great deal of Unix experience. It is, after all, part of my career.
Why would anyone need per-line access control ?
Complex environments with requirements for multiple levels of administrative privilege and responsibility.
Config fileS are in different files, each one with its own rights.
What do you do if you want to assign the ability to configure different aspects of an application whose configuration is contained within a single monolithic text file ?
The standard hack around this in the unix world is to start breaking those config files up into sub-files, typically stored in a single blah.d directory, thus adding to the complexity and inconsistency already typical to unix configuration management - this is assuming the configuration data structure even allows this.
Note that I don't think they're doing it : AFAIK you have read/write access to your whole own registry, and read acces to the whole system registry.
Default permissions != possible permissions. Registry ACLs can be as fine grained as filesystem ACLs.
I think the GP meant the reverse. That is, with windows registry, only the program has a clue about what its keys are meaning, so it is often the only one to modify them.
As it should be.
With a text config file, you can put comments and the user can modify them if he wants to.
You can put comments into the Registry if you so desire. However, like most "the unix way is the only way" people, you seem to have a great deal of trouble thinking outside the unix box.
The whole *point* is that the user /doesn't/ directly edit the Registry, but does so via a configuration tools. This allows for proper input validation, consistency checking, automation without having to use fragile, error-prone text-parsing, context-sensitive help, etc.
Direct editing of fragile, inconsistently structured configuration data, with no inherent input validation, type checking, syntax checking or consistency checking is a really bad way to manage a system.
System Restore isn't fine-grained : it's all or nothing, like the sibling AC wrote.
Which is precisely why I said it was a good idea. It would be very nice to have an automatic revisioning system built into the registry - although it would have to be configurable on a per-key basis.
I would add that with a Un*x, if you f***d up a config file, you just need to delete it.
Try that with some system-
This is true, but it's not officially meant for storing user preferences. User preferences (and similar "configuration" data) are meant to be stored in the registry.
That said, many applications do store config data here - particularly those being ported over from other OSes that do store configuration data in the filesystem (eg: iTunes, Firefox, Thunderbird).
If you aren't looking, you won't find it.
I'd be pretty willing to bet your one of these people whose first action after installing XP is to make it look and act like Windows 95, right ?
Nitpick: OS/2 only officially ran Win16 apps, although there were some later hacks to get some Win32 support.
OS/2's Windows and DOS support are also widely credited with its lack of developer support, so don't be too quick to assume OS X will go down this path (personally I'd be amazed if they do).
How do I share an arbitrary folder anywhere on the disk ?
I do hope you realise how _badly_ that reflects on the OS X Finder...
Miller column file browser (I suppose you could use http://www.winbrowser.com/ 'cept that last time i tried it it crashed, a lot)
Interesting you bring that up, because IMHO Column View _sucks_. I don't think I've ever experienced a worse way to navigate and manage files. Even the MacOS Classic Finder style, with its masses of screen clutter, clumsiness when dealing with non-trivial directory structures and poor keyboard shortcut support was better.
IME, the most efficient method for GUI file management is a directory tree+file listing (or two) and some decent keyboard shortcuts (something the Mac still lacks).
no convenient place for temporarily storing a folder one needs temporary access to
Try dropping a shortcut to the folder in the Quicklaunch bar on your Taskbar.
Of course, this is just a crutch to get around the simple fact that the Finder doesn't make moving files around - when you don't already have access to the source and destination - quick and easy, because it lacks an equivalent to "Cut" in Explorer.
the Dock affords one a single place to launch and switch applications --- why is it that in XP I click in one place to launch (the Start Menu) but use another area (the Task Bar) to switch --- in Mac OS X I click on the same icon either way.
The Dock (particularly in its default configuration) is a UI train wreck. Icons move around. Any remotely similar minimised windows are impossible to distinguish from each other. Windows can get their corners "caught" behind it making resizing annoying. Drag & drop is inconsistent with other parts of the UI. Icons representing very different things are thrown together at will.
(Expose was one of the smartest things Apple ever came up with. Not so much because of how it makes task switching so easy, but because it distracts away from how bad the Dock is at what is was supposed to do.)
The Taskbar certainly has its problems, but it's much better than the Dock.
Lots of other niceties in Mac OS X such as Services, pervasive .pdf imaging / display, memory management (there was a guy asking after loading apps from a RAM disk on an InDesign mailing list 'cause in Windows XP he couldn't keep large numbers of apps open for extended periods of time and wanted to be able to launch them more quickly than his RAID 0 array would allow), pervasive drag-drop &c.
Services are nice. The PDF imaging is also good. I can't speak for the specific example of MM, but getting a similar user experience in terms of responsiveness requires a much less powerful machines for Windows than OS X. Drag & drop has more than its fair share of weird and wonderful quirks in both. There I things I expect to be able to do in OS X (because I can do them in Windows) and vice versa.
(who really wishes Windows XP was well-suited enough to his working style to allow him to justify purchasing a Tablet PC)
Funny, when I sit in front of a different OS I simply modify my working style to take advantage of the way it works.
Right click [any] folder -> Share.
Contrast this to an OS X desktop where sharing arbitrary folders really *is* a non-trivial PITA.
look at the process you have to go through to add an IP printer, and you'll see what I mean (for Heaven's sake, why is an IP Printer a "local" device?)
Way to change the subject (within the same sentence even).
There are a lot of good reasons why the registry is better than a text file. Performance and fine-grained permissions are two.
[...] except that MS wanted to make it more difficult for end-users to poke around and understand more clearly what's going on
Yes, because a system encouraging manual configuration no input validation is such a better alternative.
Users _shouldn't_ be directly editing the registry. Ideally, users _shouldn't_ be directly editing text files in /etc, either. This is not to hide anything from them, it's so they don't break the system by making a typo.
Manual editing of text files is an incredibly bad way to configure a system by just about every measure thinkable. That there are few _better_ methods does not change this.
Applications do have to use the OS to read/write/update (so far so good), but the OS *never tracks what the application puts there*. As a result, every developer puts their copy protection in obscure keys in the registry. Even worse, and unforgiveable, are applications that leave crap behind.
Neither does any other OS I can think of - so what's your point ?
Make it impossible for an application to write to c:\windows or c:\windows\system32 or... you get the idea
They can't unless they're running as a user with sufficient privileges - just like every other multiuser OS.
Registry files should be stored locally in the directory the application was stored in, or better yet in "My Directory". The system would have its own registry stored in the system directory.
The user's registry hive is stored in their user profile. The system registry hive is stored in the system directory. Ie: it's already the way you want it.
They should be text files that can be copied by the user easily using standard tools.
How are you planning on implementing per-user, per-value ACLs on lines of text in a file ? How about making sure modifications don't end up half finished ? Are you aware parsing text is an incredibly inefficient operation ?
When a program is uninstalled, the OS would ensure all traces of the registry entry are deleted (this is easy because of #2)
But how to deal with poorly written applications that don't tell the OS everything they do ?
The only thing allowed to alter a program's registry entry is that program.
Funny, I would have thought you'd want to allow the user to manually manipulate arbitrary registry settings.
And every time its altered, a new version is kept. This would allow users to go back to old version if required.
This is about the only decent idea you've managed to come up with. Mind you, similar functionality is already available via System Restore points - but I imagine people like you automatically turn them off because you "don't like stuff going on behind your back".
A user could tell the OS to lock a registry so that nothing can alter it
Like they could now with ACLs, you mean ?
The system registry could never be altered by any application.
Regedit ? Control Panel ? How about applications that want to make system level changes for legitimate reasons ?
Requests to modify would require the root password entered by the user. Every time.
Because I'm sure the user will understand the implications of modifying arbitrary registry keys and will give nearly two full seconds' careful and considered thought before typing in their password.
When OS X has a 95% market share, comparing security track records is a valid proposition. Not before.
System Preferences application. This is similar to the Windows "Control Panels" folder, except it is so much better. Try getting windows to run an FTP server, or an HTTP server, or an SSH server, or... :-) All with two clicks! (Sharing -> click checkbox for the service of your choice). Easily protect yourself with a powerful firewall (even though you really don't need it, heh).
And in Windows I can turn of some of the graphics heavy effects if I need to. That they offer different configuration options doesn't make them better, it makes them different. 9. No viruses or spyware. 'nuff said.
Yet.
NO REGISTRY! I've seen many a 3.4 Ghz P4 system cripled to the equivalent of a 300 mhz Celeron because their registry (an unbelievably stupid concept) was fscked.
Yes, OS X is much better because it drags your dual 2Ghz G5 down to the level of a 500Mhz G4 running Classic.
I've been running NT for nearly a decade now. I'm still yet to see any of these registry problems that apparently plague every installation of Windows ever done.
Instead of the registry, OS X has an intelligent method of organizing users's preferences. They're all located in a... single folder.
You mean like in Windows how a user's preferences are all located in a... single registry key ?
Intelligent user organization scheme - Because OS X has real, actual unix permissions (unlike windows), [...]
NT's permissions system is vastly superior to "unix permissions".
[...] it is by default very secure on a multiuser system, with excellent user home folder organization.
Hey, just like Windows.
There's a System Library folder where system prefs are located (protected by permissions), and a Library folder in each User's home directory.
HKEY_LOCAL_MACHINE, HKEY_USERS_[UID].
This makes moving from one system to another and backing up data really easy.
I could go on... but like I said in the other post, you should just learn more.
I already know a great deal about Macs, that's why I bought one. It would appear, however, you don't know much about Windows. Don't feel bad though, most people who criticise Windows haven't got a clue what they're talking about.
Actually it does, because "acceptable behaviour" is a matter of opinion, not an absolute measure. When "everyone" behaves the same way, at least within their sphere, that makes such behaviour acceptable.
But it's not true. They have behaved shamefully, and to a worse degree than other companies. Perhaps it's only because of the power they wield, but they have behaved in a shameful manner.
Bollocks. They've done nothing worse than any other company of any size. They've gotten into more trouble for it, to be sure, but that's a different issue from their actual behaviours.
Just because there are awful corporate actions elsewhere doesn't excuse a thing Microsoft has done.
The objective is not to excuse, because personally, I don't believe they've done anything that really needs "excusing". They play their business just like most big companies - ruthlessly. If that bothers you greatly, you need to be attacking the entire corporate ethic, not just one particular manifestation of it (ie: Microsoft).
Get some manners.
People who think Microsoft is somehow different to every other company out there don't deserve manners, they deserve to be slapped.
People like the OP claiming "paying attention" is all it takes to be "anti Microsoft" are acting hypocritically, because they're either judging from different standards, or only "paying attention" to Microsoft.
Lots of people here on /. (which may or may not inclide the OP), who seem to think Microsoft is the Great Satan, the personification of evil or the poster boy for corporate misbehaviour need to get some perspective.
I think you've finally identified the real problem here. Your issues aren't caused by Windows, they're caused by shitty software.
You certainly haven't described anything yet that is *inherent* to Windows, merely symptoms of poor software, poor processes and flawed architecture.
FTP is a fucked up protocol to start with. If NAT causes its demise, I know I personally will be nothing but smiles.
I'm not a developer so I'm not in a position to argue the specifics, however, Windows is hardly "crippled" in the server market. Indeed, it's probably one of the most popular platforms out there.
What you have neglected to account for however is the cost of rebooting those machines, specifically in money, time, and frustration.
No, I haven't. If scheduled downtime for a server reboot is a major issue - in money, time, frustration or anything - your architecture is flawed. Added to that, if your machines or software are that unreliable that this happens regularly, you've got much bigger issues to worry about.
In our specific case, every time we want to update our London clients, it costs between 4 and 12 man hours, most of that for an IT guy working overtime to stand around in case he needs to manually reset a server.
Sounds like both your architecture _and_ your processes are flawed. You shouldn't need someone on-site to reset machines if they don't reboot - lights-out management tools that can do this are commonplace.
Compare this to our Linux procedure: 1) shell in, 2) update software, 3) run diagnostic.
There is no reason you can't do this with your Windows machine as well, that Windows is to blame for.
No-one's done anything particularly "drastic" in the last couple of decades. Singling Microsoft out is hardly rational.
However, that's irrelevant to the topic at hand. Prior to OS X, Apple's OS was 1 - 2 generations behind the competition. With OS X, it is on par. That change happened in the space of a couple of years.
The point is that just because WinFS isn't here today, doesn't mean it won't appear in 18 months and be vastly better than any of the alternatives.
OS X is a superior Desktop OS in every way that matters outside of the games shelf at Game Stop.
Its performance is still mediocre at best.
I would also imagine its hardware scalability is relatively poor (based on its overall poor performance and its much briefer time on multiprocessor hardware).
Accessing network resources is clumsy (and often unreliable)
The Dock is a UI train wreck.
Finder is awful.
Windows does filesystem-level encryption and compression better.
Then there's the indirect aspects:
Games, as you mention. Indeed, software in general.
OS X needs more expensive hardware (and hardware options are far more limited).
Linux (and the BSDs for very specific applications) is a superior server OS (this is not a corner case).
Sorry, it's not that simple.
Windows is better for fileserver to Windows clients (things like share caching, shadow copies, clustering).
Exchange
Centralised management of Windows clients (ie: Active Directory and Group Policy)
From everything I've read and heard, IIS6 and friends are superior to Apache (and friends) for web serving and site development.
For most other things, Windows is at least on par.
Now, the things Linux does better are generally because of its greater customisability to deal with corner cases, *not* general purpose use. One thing Linux does clearly do better than Windows /in general/ is storage management. LVM and Linux's software RAID are excellent - which is why we're rolling our own SAN with Linux and not Windows Storage Server.
Added to this, Linux's often $0 upfront cost has a tendency for people to think it's cheaper, even if their TCO ends up higher. Of course, by the time you're in a position to do a worthwhile TCO evaluation, you've generally got too much invested one way or the other to switch anyway.
However, as I said previously, no OS is so far enough ahead /on average/ that any of them can be considered outright superior (or inferior).
I use a Mac laptop, my work machine is Windows and I'm a Sys Admin. I daresay I'm in a fairly good position to be able to observe the strengths and weakness of the major platforms.
It seems you have about as much experience as the submitter ("Microsoft has unparalleled influence throughout the Federal government." WTF ? Compared to who ? The GNAA ?).
Compared to governments with actual, endemic, systemic corruption, the US government is a shining beacon of honesty - and I'm not exactly a big fan of the US at the best of times.
Of course, all you have to do to be an "astroturfer" on Slashdot is post sane, balanced, factual viewpoints than don't criticise or blame Microsoft for all the world's woes...
You forgot the 3rd option: more people whose entire lives don't revolve around hating Microsoft are reading Slashdot.
For example ?
Like those email attachments the user has to specifically launch, that warn launching them might be a bad idea (with the default set to "don't do it" ?
I find it laughable you blame this UI paradigm on Windows when MacOS and OS/2 were doing it (and advertising it) _years_ beforehand (and the concept itself is even older). Microsoft were 5 - 10 years late to the pervasive drag & drop, sorta-object-oriented, document-centric interface, yet somehow it's their fault ?
For shame - your bias is showing.
Behind the scenes Windows will silently open the application, feed it the data, and a command telling it to print to the printer.
So does OS X. So does KDE. So does GNOME. So does every other remotely modern GUI released in the last 10 - 15 years. What's your point ?
Windows can be told instead to execute the data as code, [...]
If the app has a buffer overflow, maybe - but Windows hardly has a monopoly on buffer overflows.
Only if you're a biased 15 year old with a worldview about as wide as a pencil.
Microsoft behave much the same way every other company does in the computing world. The only difference is their actions have a much wider impact than most others (within the computing world).
If you want to get into a global scale and move outside of the computing world, Microsoft are practically a *saint* in comparison to the /real/ "big nasty corporations. Thousands of babies have not died because of a deceptive Microsoft marketing campaign. Wars have not been started because Microsoft wanted to make some more money.
Get some fucking perspective.
Hate to break it to you, but IE is no more "integrated" into Windows than Safari+WebKit+WebCore is into OS X.
There is zero reason to believe a Microsoft RSS "reader" will be any more "integrated" into Windows than the OS X one is into OS X.
1. Define "OS Space".
2. What on Earth makes you think Microsoft will put an RSS reader into kernel space in Windows ?
The number of times a system is exploited is not not a valid measure of its security.
People don't steal cars because there are lots of them.
Which cars are more likely to get stolen - the ones 95% of the population own or the ones 5% of the population own ?
If a scheduled downtime window is an issue, then your architecture is flawed. If you don't even *have* scheduled downtime windows, then your processes are also flawed.
Your other examples sound suspiciously like "but it's not like Unix !" complaints.