Data files may be coarse, but few Linux configuration files are so large that this a problem. Same for security.
If there's more than one line, there's a risk.
Transactional? Hmm. ..
You seem to have a misunderstanding of what "transactional" means.
Do you believe that system administrators are so mistake prone that they can't be trusted to edit text files?
Yes. More accurately, there is no justification for putting system administrators in the position where they should have to be "trusted" with something so error prone when a perfectly good computer exists that could be doing the job for them with orders of magnititude more speed and accuracy.
Typos and other mistakes are very common. One of the primary functions of computers is to relieve humans of simple repetitive and/or error-prone tasks like, say, checking data for validity and correctness. Who do you think is more likely to make a mistake checking a configuration file for validity and correctness; a human, or a programmatic validator with a lookup table of every possible directive and their legal values ?
Or do you allow ordinary users to edit system files?
Not all "Administrators" require equivalent levels of access. This is before even getting into audit trails.
What justification do you have for your claim that changes should be made via a centralized, standardized interface?
The same justifications for centralising and standardising *any* common system activity. Do you advocate every application should have its own name resolution, authentication and C library implementations, or do you think having the system provide them in a centralised and standardised way is preferable ?
I also feel compelled to point out that a "centralised, standardised interface" doesn't need to be some sort of "Control Panel" tool - since that's probably what you're thinking - it need be nothing more than an API over which developers can layer their own graphical and/or commandline configuration tools.
Isn't this just more of the "One True Way" mantra from Microsoft?
Why do you believe that the concept of editing text files for configuration is "broken" in the first place?
* They're not centralised or standardised (even if all the textfiles are in the same place (which they often aren't anyway), different tools are often used to access and/or modify their contents)
* Data access is very coarse (you have to read or write the entire file, even if only a single line is being read or modified).
* Security is similarly very coarse (you can't lock down the contents of a text file any more finely than the entire file itself).
* Multiple users cannot change the same file at the same time.
* No sanity checking of data whatsoever.
* Inconsistency abounds - filenames, locations, format, data, purpose.
* Inherently non-transactional changes.
(This is not to say the Windows Registry is a panacea, because it's certainly not - but as a _concept_ it's far superior to textfiles).
Error-prone humans should not be directly modifying system data unless absolutely necessary. Changes should be made via a centralised, standardised interface that (at the very least) performs basic sanity checking of data, restricts access to data according to system security and is transactional.
That plain text files make recovery from fuckups simpler does not excuse the initial problem that they allow (if not encourage) the fuckups to be so easily made in the first place.
(If you feel the urge to compare editing textfiles in unix to using regedit in Windows, please do not bother replying. You have completely missed the point.)
The OS I have in mind would leave yours alone and give me the UI I want, and give others the UI they want. I don't see the conflict. X is X is X, whether you run Gnome, KDE, FVWM2, Open Look, AfterStep or Motif. That's the beauty of it.
The problem is 95% of people haven't the knowledge, experience, skill or interest in building their own UI.
Your system would work really well for the tiny minority of people who are able to design a UI around their workflow and really badly for the vast majority of people who either can't, or aren't interested in doing so.
Most of the time it's more efficient in the long run to simply learn how a certain interface works than spend time trying to redesign it to your tastes. Firstly, because it's highly likely the developer has made at least some attempt to optimise the interface for the most common tasks and secondly because that knowledge becomes reusable.
I've been thinking my way along a thought trail that started with Nicholas Petreley's back-page rant in February's Linux Journal (the first LJ in my life). In it he lambastes the Open Source community for recently falling into a slavish imitation of Windows: Linux got to where it is today by being both better and different from Windows, not by trying to be a cut-rate knock-off.
Linux got to where it is today by being a cut-rate knock-off of *unix*, not Windows. While Linux has massacred commercial unix marketshare, it's had little (if any) impact on Windows marketshare.
HOWEVER, it is important to remember that people do not think alike. What is consistant for one may not be for another. The "correct" UI is one where the applications describe what they'd like the UI to contain, with a skinning engine turning this description into something the user can actually use.
The word you're after here is "intuitive", not "consistent".
"Consistent" is being able to find an "Exit" entry under every "File" menu.
"Intuitive" is whether or not you think "Exit" should be under "File" in the first place (which is what you appear to be talking about).
Good for them - the idea of having everything in one binary file that can be fucked up incredibly easily is a total sack of shite.
So is the idea of users configuring software by directly editing arbitrary text files.
Difference is, "fixing" the Registry's distaster recovery problem is as simple as backing it into some human-readable format like XML as well as a compiled DB. "Fixing" the broken concept of editing text files for configuration is nearly impossible.
I have nothing against cream-skimming the best features of Windows for use in Linux. But creating a registry for Linux is not cream-skimming. It's pond-scum-skimming. What happened to the days when people were appalled at the idea that you'd have to edit a registry in order to make this or that feature work the way you wanted? I don't care if the registry is binary or XML. It's a maintenance nightmare.
Right, because directly editing text files, with no input validation, little capabilities for fine-grained changes or permissions, no facilities for making changes atomic and fuck all consistency in formatting, presentation and execution, is *such* a better way to do it...
Direct editing of arbitrary text files is such an incredibly bad way to configure software, it's amazing it was even dreamed up in the first place, let alone come to be considered "better".
And I still can't do lots of things (like full use of a USB thumb drive) using a non-priviliged account (not to mention that the default install on my Microsoft-partnered laptop came with the user accounts having full admin priviliges)
What can't you do with a USB thumbdrive as a regular user ?
Within hours, a member of the SomethingAwful forums had hacked together a patch to the gdi32.dll with a few dozen NOP instructions to render the SetAbortProc call useless. Obviously with just a hex editor and no access to the Windows source code.
And how many applications did this "fix" break ?
Out in the real world, fixing security holes is a touch more complicated.
Actually they reflect reality and are the result of customer requests.
In managed environments, patches are almost never applied ad-hoc, as they are released. They are collected together then tested and rolled out on a schedule, usually monthly.
Nobody's talking about master races or anything like that, but there's still a morally offensive (to some, at least) supposition there: Not all men are created equal.
It's important to note that the concepts "All men are created equal" and "All men shall be treated equally" are *not* synonymous. Just because some individuals may or may not have better inherent abilities at some tasks is *not* justification for denying equal opportunities.
Similarly, it would not be justification for excusing certain behaviour (eg: a predisposition towards violence used as an "excuse" for assault). It works both ways.
Any task requiring something physical I agree with you, anything that is solely mental, I disagree.
Why ? The brain is just another organ and, hence, just another aspect of physical makeup. There's no reason to think the same physical attributes that make some people stronger, faster, fitter, etc are any different when applied to the brain and its mental capabilities.
This is before even getting to medical conditions that affect brain development.
Firstly, because that list is artificially inflated ("Win32, WinNT, WinXP" are all the same thing - Win32).
Secondly, because the unix side is just as bad, if you compare apples to apples (ie: throw X and associated libs into the mix - how many widget libraries can you name ?).
Thirdly, because binary compatibility on Windows is very well maintained. It's not uncommon for those twenty year old DOS and Win16 binaries to run unmodified on Windows XP or 2003 (and probably Vista). Woe betide most with a twenty year old non-trivial unix app and no source code. Heck, with something like Linux you're lucky if binaries work between one major relase and the next, let alone 10 - 20 years worth of them.
I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP,.NET, Vista... versus POSIX. Yeah, he's right, it sounds pretty ridiculous when you put it that way.
Particularly since the "Win32, WinNT, WinXP" part of it are all the same thing, so the real progression is:
Unix is far easier to use. It's quicker to work when you have a consistant interface; Unix has rules. On Windows the whole design is haphazard; poor design in my opinion.
Part of our "adoption problem" is that people come along and are like "hey, why isn't this like my operating system? my friends would use it if it was" [...]
This was, I should point out, in response to This comment, which is obviously and clearly referring to UI and its relevance to users and had *nothing* to do with developers.
I was talking about the ability to use (from a programming POV) for an operating system... You mentioned UI.
Actually, no, you mention UI and say next to nothing that's at all relevent to programming, except:
People who write for Unix by definition don't like the way Windows does things.
[...] the 30 years Unix has been in development that someone has considered that and thought it was a bad idea.
In fact, it's pretty clear from your comment replying - and relevant - to "adoption" that you're talking about "user-friendliness" regarding *using* Linux, not *writing* for it.
I was responding to someone who thought that Linux had "a long way to go before it becomes "widely adopted".
Yes, and both that person and you are making comments regarding its UI.
I haven't heard this in particular as a general critism, but removing much of the CLI functionality and forcing the user to use a WM isn't abstraction from an OS POV.
Firstly, no functionality was "removed" from the CLI. Secondly, you don't have to "use the WM" if you don't want to - nothing stops you firing up a cmd (or even bash, with cygwin) session full-screen and using that.
(Why anyone would *want* to is something to wonder about, but there's nothing stopping them.)
I'm clearly talking about abstraction in the context of hardware-from-software.
Which is what the drives in the Windows UI give you.
The "different method" you speak of isn't a different method of abstraction, it's really very little abstraction what so ever.
Nope, it's just different - it's the same abstraction OS X uses (in Aqua). Physical drives (well, stricly speaking, partitions) are represented by logical containers.
And as much as you want to pretend that mounting drives under directories is the same as a true hierarchical filesystem, it's not the same. It's not even close. There is a massive design principle chasm which you have not grasped. That functionality in Windows is a hack. It's not that same.
It offers identical functionality. Mounting physical drives (/partitions) under directories is *exactly* the abstraction unix uses (and has both its pros and cons).
Indeed, if you consider the Desktop as being equivalent to/, Windows (and OS X) has the the exact same "hierarchical" system that unix does.
How is "the unix way" "more abstracted" ?
Bringing this up as an argument is bullshit. While NT was originally designed like this, the reality is that as soon as they dropped the Alpha port, much of this design was ignored.
That's a very bold claim. You do of course have some evidence to support it ?
Windows 9x supported 1 processor (x86) IIRC.
Windows 9x is completely irrelevant to this discussion, which is about Windows NT.
Windows NT has supported 5, although not all at once, and currently supports only 2 (x86 and amd64).
Plus Itanium and PPC. Both of which are, I feel compelled to point out, *substantially* different to x86 from an architectural perspective.
Or, to put it another way, NT remains quite portable, as it was designed to be, and your claims to the contrary
Well, it's not really a very good comparison because Apple is primarily a hardware company, or complete solutions if you will. Yes, if they were trying to sell OS X it would be a bad idea. If you are trying to sell Mac boxes, I think it's a good idea.
It's not selling Macs per se, it'd convincing developers they should write native code when your platform can emulate another just as well. That's one of the things that killed OS/2 - no native apps.
If you want you rate an Operating System by its UI, you really arethinking about this all wrong.
I made no statements about the suitability of an OS for a task, I was replying to *your* comments about UI and "ease of use".
That said, at this point in time, "UI" is probably one of the most important factors in deciding which OS to use in most scenarios.
I not sure if you know (it seems like you don't) but FreeBSD, GNU, Solaris and MacOSX are Unixes.
Wow. I really had no idea.
The GUI part of Unixes is not linked to a particular kernel.
Nor is that relevant.
You're correct in identifing that Windows is not a Unix.
Imagine that.
MacOS is a Unix, so by your (poor) logic, Unix is ahead in the UI.
MacOS is indeed a unix, however, its primary UI - that 99% of people will be using - is not at all unix-like. Of course, if you were actually interested in a rational discussion and not cheap point-scoring attempts with asinine and pedantic comments, you wouldn't have bothered bringing that up. The vast, vast bulk of people don't use OS X because it's unix, they use OS X because it's a Mac. The closest they ever get to the "unix" part is reading Apple's advertising material.
(Not to mention, OS X is about as much like a typical unix as Windows with Cygwin installed is).
By my logic, the GUI is not linked to the OS, and thus whether or not the UI is good is irrelevant.
UI and GUI are not interchangeable terms. When I was talking about the unix UI, I was referring the the various unix commandlines and the abstractions presented to end users. I figured someone who was attempting to display at least a passing acquaintance with unix would understand that. However, for all your posturing about trying to seperate "OS" from "GUI", you have completely ignored that "GUI" and "UI" are also two different things.
For someone who started off making comments about UI, you seem to be avoiding actually talking about anything UI-related.
The unix commandline, from a UI perspective, is a train wreck. It's difficult to learn, documentation is sparse and requires substantial amounts of pre-existing knowledge to interpret correctly. Commands are inconsistent and unintuitive in both naming and usage. Feedback and mechanisms for protecting the user from making mistakes are essentially nonexistant. "The rules", as you put it, are numerous, inconsistent, unintuitive and often in conflict. In short, until you've got a very good idea of what you're doing, the unix commandline is a frustrating, hostile and dangerous place to be.
Unix works by abstraction; you abstract as much as possible so that it is independant of the hardware. This is one of the main design philosopies of Unix. Windows (and pretty much every operating system) is different; it doesn't abstract much [...]
What I find particularly hilarious about your comment is that one of the things Windows is typically criticised for by the unix crowd is that it's *too* abstracted and doesn't let them get "down and dirty" enough.
[...] (hence you have a "C" drive instead of having the hard drives mounted into an abstracted filesystem.
Hate to break it to you, champ, but that '"C" drive' *is* an abstraction. A different method, to be sure, but an abstraction none the less. (Not to mention Windows has been able to mount drives under directories for 5+ years now, if that's your preference.)
The point of Unix is not to be directly linked to any specific hardware (this is why porting Unixes is a relatively small job), but Windows is.
False. Windows is extremely portable and was specifically designed from day 1 to be easily implemented on multiple platforms. Indeed, Windows is almost certainly more portable than the typical unix (certainly its design is, at any rate).
Unix is different in that it abstracts.
No, it's not. All OSes abstract. That's the whole point of
So much verbiage. Your abridged version can be cut down even more:
I know stuff, so you should read this.
Windows is t3h sux0rs !
Linux is perfect and has never had a single problem, EVAR !
(Basically, what parts of the "article" aren't outright false, are just the standard anti-Microsoft FUD. Not that the original "Why Vista Won't Suck" was a shining example of the writing, but it was award-winning material compared to this tripe.)
Unix is far easier to use. It's quicker to work when you have a consistant interface; Unix has rules. On Windows the whole design is haphazard; poor design in my opinion.
You seem to have that arse-about-face.
Unix is like the English language - the exception *is* the rule - finding consistent UI just about anywhere is quite rare. Windows isn't quite up there with MacOS (which has slipped a bit with OS X) but it's streets ahead of unix in almost every aspect of UI consistency.
People who write for Unix by definition don't like the way Windows does things.
Really ? So how did anything get written for Unix before Windows was released ?
You remind me of one of my favourite quotes:
"FreeBSD is for people who love unix, Linux is for people who hate Windows".
No, he doesn't, because the criticism that any employee can slip any code into the shipping product is based on the assumption that the only person(/people) who knew about the Excel easter egg was the person (or persons) who wrote it. This assumption is, at best, questionable.
This is also ignoring the foolishness of taking that questionable assumption about the development practices at Microsft nearly 10 years ago and adding another assumption that nothing has changed since then. The dearth of easter eggs in Microsoft products since about 2000 (in the face of their relative frequency beforehand) are enough to make that second assumption, at best, highly unlikely.
I'm NOT saying that OSS is differant, but I would expect that in MS there could be an employee mad at the people above him for a number of reasons, where in open source development, alot of the time, development isn't a job process with commercial-software-pressure.
The problem is no causal link has been drawn between an easter egg in a ten year old version of Excel and disgruntled employees managing to get a backdoor into current and future products (or even past ones for that matter). Every criticism here is based on assumptions that are - at best - questionable.
Your definition of "efficiency" may not match everyone else's.
Now, if you're running a site with 5,000 transitory, "workhorse" style employees (like, say, a call centre) then your rules may be reasonable. But they suck for any sort of "real work" vis -a vis email communucations and do nothing but create bigger, more expensive problems down the track.
The user doesn't know what's good for them and has a tendency towards selfishness rather than social responsibility.
No, the user has a job to do. It is *your* responsibility to provide them with the tools that let them do their job in a productive manner. If your users are trying to treat email as a document repository, they're not doing it to annoy you, they're doing it because you haven't given them a better way of doing it [0].
To put it plainly, the data on their hard drives is disposable. They are notified of that. There is no way in hell that we are going to guarantee their data on their hard drives or attempt to get them to back up their own data (remember, they don't "get" this stuff and they WILL screw up or completely ignore the concept of backing up their data).
So you give them a measly 10M of centralised, backed-up email storage, then tell them they effectively can't even back up old mail for reference on their machines, because it might be lost. I shudder to think of the amount of potentially important business information that your policies have destroyed.
Our users may not be happy, but that's not what we're here for.
Yes, it is. The sole purpose of a company's IT department is to keep its users happy by providing them with the tools and resources they require to best do their job. There is no other business-related justification for its existence.
Care to give me a reasoned rebuttal?
Fundamentally, an IT department is supposed to be providing services to the rest of the business[1] so that it can maximise its productivity. It is *NOT* supposed to be dictating policty to the rest of the business. For most companies, the IT department is nothing but a financial liability - it generates no revenue of its own and costs a lot to run. It should be the IT department that is run according to the business requirements of the company, not vice versa.
This is not to say there is never any reason for draconian, minimalist, centralised resource management - schools being an excellent example of an appropriate environment to impose your rules - but for the typical business, they do far more harm than good because they prevent people from being productive.
I suspect, based on your comments, that you're coming from a background like a school, university or "grunt farm" (eg: call centre) type environment, with a relatively high user turnover rate and little justifiable need for referencing communucations more than a few weeks old.
[0] And it's critical to remember there that the definition of "better" is 100% in the hands of the user.
[1] There are lots and lots of IT departments who feel IT is the end, not the means. They are wrong. These are not companies you want to work for, unless you're lucky enough to be in the IT department and not subject to its rules.
Sorry, perhaps I should go read those links again.
I doubt it would make any difference. Actually, I'd be amazed if you even read them once.
I missed the part where Microsoft said they were going to do anything more than create an illusion of improved security.
Porbably because you're not prepared to believe anything else.
I missed the part where Microsoft haven't had a single easter egg since the flight simulator one.
There were a few, but I doubt you'd find any in products newer than 5 years old.
I missed the part where Microsoft didn't have an unpatched, widely exploited flaw for two weeks that let anyone embed runnable code in image files.
You've got a very, very weird idea of what "widely exploited" is. I suppose you think bird flu is currently at the global pandemic stage, as well ?
And I missed the part where Vista codebase was rewritten from scratch and so well audited that it didn't share the same flaw.
I must have missed the part where anything you've said has anything to do with your original point of "secret" code making it past managers[0] and into shipping products in recently released software.
Sorry, I guess I should pay more attention.
It's probably quite hard to see anything clearly past that massive chip on your shoulder.
[0] Actually I really don't think you've even got a point here. I've little doubt that managerial staff - certainly above the level of the developers at any rate - not only knew about the easter eggs, but approved their inclusion.
Unreadable blocks shouldn't get discovered for the first time during a rebuild. The drive's SMART surface scan or the controller's periodic surface scan is supposed to find them first.
This tends to be one of those situations where what "should happen" and what "does happen" do not intersect.
If you're using drives without block relocation and a controller that doesn't do a periodic surface scan and block device level relocation, you're in for a world of hurt.
SATA does not handle these functions as well as SCSI in the real world. Unfortunate, but true.
Slashdot Mirror
If there's more than one line, there's a risk.
Transactional? Hmm. . .
You seem to have a misunderstanding of what "transactional" means.
Do you believe that system administrators are so mistake prone that they can't be trusted to edit text files?
Yes. More accurately, there is no justification for putting system administrators in the position where they should have to be "trusted" with something so error prone when a perfectly good computer exists that could be doing the job for them with orders of magnititude more speed and accuracy.
Typos and other mistakes are very common. One of the primary functions of computers is to relieve humans of simple repetitive and/or error-prone tasks like, say, checking data for validity and correctness. Who do you think is more likely to make a mistake checking a configuration file for validity and correctness; a human, or a programmatic validator with a lookup table of every possible directive and their legal values ?
Or do you allow ordinary users to edit system files?
Not all "Administrators" require equivalent levels of access. This is before even getting into audit trails.
What justification do you have for your claim that changes should be made via a centralized, standardized interface?
The same justifications for centralising and standardising *any* common system activity. Do you advocate every application should have its own name resolution, authentication and C library implementations, or do you think having the system provide them in a centralised and standardised way is preferable ?
I also feel compelled to point out that a "centralised, standardised interface" doesn't need to be some sort of "Control Panel" tool - since that's probably what you're thinking - it need be nothing more than an API over which developers can layer their own graphical and/or commandline configuration tools.
Isn't this just more of the "One True Way" mantra from Microsoft?
No, it's good engineering and design.
* They're not centralised or standardised (even if all the textfiles are in the same place (which they often aren't anyway), different tools are often used to access and/or modify their contents)
* Data access is very coarse (you have to read or write the entire file, even if only a single line is being read or modified).
* Security is similarly very coarse (you can't lock down the contents of a text file any more finely than the entire file itself).
* Multiple users cannot change the same file at the same time.
* No sanity checking of data whatsoever.
* Inconsistency abounds - filenames, locations, format, data, purpose.
* Inherently non-transactional changes.
(This is not to say the Windows Registry is a panacea, because it's certainly not - but as a _concept_ it's far superior to textfiles).
Error-prone humans should not be directly modifying system data unless absolutely necessary. Changes should be made via a centralised, standardised interface that (at the very least) performs basic sanity checking of data, restricts access to data according to system security and is transactional.
That plain text files make recovery from fuckups simpler does not excuse the initial problem that they allow (if not encourage) the fuckups to be so easily made in the first place.
(If you feel the urge to compare editing textfiles in unix to using regedit in Windows, please do not bother replying. You have completely missed the point.)
The problem is 95% of people haven't the knowledge, experience, skill or interest in building their own UI.
Your system would work really well for the tiny minority of people who are able to design a UI around their workflow and really badly for the vast majority of people who either can't, or aren't interested in doing so.
Most of the time it's more efficient in the long run to simply learn how a certain interface works than spend time trying to redesign it to your tastes. Firstly, because it's highly likely the developer has made at least some attempt to optimise the interface for the most common tasks and secondly because that knowledge becomes reusable.
Linux got to where it is today by being a cut-rate knock-off of *unix*, not Windows. While Linux has massacred commercial unix marketshare, it's had little (if any) impact on Windows marketshare.
The word you're after here is "intuitive", not "consistent".
"Consistent" is being able to find an "Exit" entry under every "File" menu.
"Intuitive" is whether or not you think "Exit" should be under "File" in the first place (which is what you appear to be talking about).
So is the idea of users configuring software by directly editing arbitrary text files.
Difference is, "fixing" the Registry's distaster recovery problem is as simple as backing it into some human-readable format like XML as well as a compiled DB. "Fixing" the broken concept of editing text files for configuration is nearly impossible.
Right, because directly editing text files, with no input validation, little capabilities for fine-grained changes or permissions, no facilities for making changes atomic and fuck all consistency in formatting, presentation and execution, is *such* a better way to do it...
Direct editing of arbitrary text files is such an incredibly bad way to configure software, it's amazing it was even dreamed up in the first place, let alone come to be considered "better".
What can't you do with a USB thumbdrive as a regular user ?
And how many applications did this "fix" break ?
Out in the real world, fixing security holes is a touch more complicated.
You are probably thinking of NT's internal API, which third party developers are not supposed to use.
Actually they reflect reality and are the result of customer requests.
In managed environments, patches are almost never applied ad-hoc, as they are released. They are collected together then tested and rolled out on a schedule, usually monthly.
It's important to note that the concepts "All men are created equal" and "All men shall be treated equally" are *not* synonymous. Just because some individuals may or may not have better inherent abilities at some tasks is *not* justification for denying equal opportunities.
Similarly, it would not be justification for excusing certain behaviour (eg: a predisposition towards violence used as an "excuse" for assault). It works both ways.
Why ? The brain is just another organ and, hence, just another aspect of physical makeup. There's no reason to think the same physical attributes that make some people stronger, faster, fitter, etc are any different when applied to the brain and its mental capabilities.
This is before even getting to medical conditions that affect brain development.
Not really.
Firstly, because that list is artificially inflated ("Win32, WinNT, WinXP" are all the same thing - Win32).
Secondly, because the unix side is just as bad, if you compare apples to apples (ie: throw X and associated libs into the mix - how many widget libraries can you name ?).
Thirdly, because binary compatibility on Windows is very well maintained. It's not uncommon for those twenty year old DOS and Win16 binaries to run unmodified on Windows XP or 2003 (and probably Vista). Woe betide most with a twenty year old non-trivial unix app and no source code. Heck, with something like Linux you're lucky if binaries work between one major relase and the next, let alone 10 - 20 years worth of them.
Particularly since the "Win32, WinNT, WinXP" part of it are all the same thing, so the real progression is:
DOS, Win16, OS/2, Win32, .NET.
This was, I should point out, in response to This comment, which is obviously and clearly referring to UI and its relevance to users and had *nothing* to do with developers.
I was talking about the ability to use (from a programming POV) for an operating system... You mentioned UI.
Actually, no, you mention UI and say next to nothing that's at all relevent to programming, except:
In fact, it's pretty clear from your comment replying - and relevant - to "adoption" that you're talking about "user-friendliness" regarding *using* Linux, not *writing* for it.
I was responding to someone who thought that Linux had "a long way to go before it becomes "widely adopted".
Yes, and both that person and you are making comments regarding its UI.
I haven't heard this in particular as a general critism, but removing much of the CLI functionality and forcing the user to use a WM isn't abstraction from an OS POV.
Firstly, no functionality was "removed" from the CLI. Secondly, you don't have to "use the WM" if you don't want to - nothing stops you firing up a cmd (or even bash, with cygwin) session full-screen and using that.
(Why anyone would *want* to is something to wonder about, but there's nothing stopping them.)
I'm clearly talking about abstraction in the context of hardware-from-software.
Which is what the drives in the Windows UI give you.
The "different method" you speak of isn't a different method of abstraction, it's really very little abstraction what so ever.
Nope, it's just different - it's the same abstraction OS X uses (in Aqua). Physical drives (well, stricly speaking, partitions) are represented by logical containers.
And as much as you want to pretend that mounting drives under directories is the same as a true hierarchical filesystem, it's not the same. It's not even close. There is a massive design principle chasm which you have not grasped. That functionality in Windows is a hack. It's not that same.
It offers identical functionality. Mounting physical drives (/partitions) under directories is *exactly* the abstraction unix uses (and has both its pros and cons).
Indeed, if you consider the Desktop as being equivalent to /, Windows (and OS X) has the the exact same "hierarchical" system that unix does.
How is "the unix way" "more abstracted" ?
Bringing this up as an argument is bullshit. While NT was originally designed like this, the reality is that as soon as they dropped the Alpha port, much of this design was ignored.
That's a very bold claim. You do of course have some evidence to support it ?
Windows 9x supported 1 processor (x86) IIRC.
Windows 9x is completely irrelevant to this discussion, which is about Windows NT.
Windows NT has supported 5, although not all at once, and currently supports only 2 (x86 and amd64).
Plus Itanium and PPC. Both of which are, I feel compelled to point out, *substantially* different to x86 from an architectural perspective.
Or, to put it another way, NT remains quite portable, as it was designed to be, and your claims to the contrary
Eh ? Usermode drivers are hardly something common to unixes. Quite the opposite, in fact.
It's not selling Macs per se, it'd convincing developers they should write native code when your platform can emulate another just as well. That's one of the things that killed OS/2 - no native apps.
I made no statements about the suitability of an OS for a task, I was replying to *your* comments about UI and "ease of use".
That said, at this point in time, "UI" is probably one of the most important factors in deciding which OS to use in most scenarios.
I not sure if you know (it seems like you don't) but FreeBSD, GNU, Solaris and MacOSX are Unixes.
Wow. I really had no idea.
The GUI part of Unixes is not linked to a particular kernel.
Nor is that relevant.
You're correct in identifing that Windows is not a Unix.
Imagine that.
MacOS is a Unix, so by your (poor) logic, Unix is ahead in the UI.
MacOS is indeed a unix, however, its primary UI - that 99% of people will be using - is not at all unix-like. Of course, if you were actually interested in a rational discussion and not cheap point-scoring attempts with asinine and pedantic comments, you wouldn't have bothered bringing that up. The vast, vast bulk of people don't use OS X because it's unix, they use OS X because it's a Mac. The closest they ever get to the "unix" part is reading Apple's advertising material.
(Not to mention, OS X is about as much like a typical unix as Windows with Cygwin installed is).
By my logic, the GUI is not linked to the OS, and thus whether or not the UI is good is irrelevant.
UI and GUI are not interchangeable terms. When I was talking about the unix UI, I was referring the the various unix commandlines and the abstractions presented to end users. I figured someone who was attempting to display at least a passing acquaintance with unix would understand that. However, for all your posturing about trying to seperate "OS" from "GUI", you have completely ignored that "GUI" and "UI" are also two different things.
For someone who started off making comments about UI, you seem to be avoiding actually talking about anything UI-related.
The unix commandline, from a UI perspective, is a train wreck. It's difficult to learn, documentation is sparse and requires substantial amounts of pre-existing knowledge to interpret correctly. Commands are inconsistent and unintuitive in both naming and usage. Feedback and mechanisms for protecting the user from making mistakes are essentially nonexistant. "The rules", as you put it, are numerous, inconsistent, unintuitive and often in conflict. In short, until you've got a very good idea of what you're doing, the unix commandline is a frustrating, hostile and dangerous place to be.
Unix works by abstraction; you abstract as much as possible so that it is independant of the hardware. This is one of the main design philosopies of Unix. Windows (and pretty much every operating system) is different; it doesn't abstract much [...]
What I find particularly hilarious about your comment is that one of the things Windows is typically criticised for by the unix crowd is that it's *too* abstracted and doesn't let them get "down and dirty" enough.
[...] (hence you have a "C" drive instead of having the hard drives mounted into an abstracted filesystem.
Hate to break it to you, champ, but that '"C" drive' *is* an abstraction. A different method, to be sure, but an abstraction none the less. (Not to mention Windows has been able to mount drives under directories for 5+ years now, if that's your preference.)
The point of Unix is not to be directly linked to any specific hardware (this is why porting Unixes is a relatively small job), but Windows is.
False. Windows is extremely portable and was specifically designed from day 1 to be easily implemented on multiple platforms. Indeed, Windows is almost certainly more portable than the typical unix (certainly its design is, at any rate).
Unix is different in that it abstracts.
No, it's not. All OSes abstract. That's the whole point of
I know stuff, so you should read this.
Windows is t3h sux0rs !
Linux is perfect and has never had a single problem, EVAR !
(Basically, what parts of the "article" aren't outright false, are just the standard anti-Microsoft FUD. Not that the original "Why Vista Won't Suck" was a shining example of the writing, but it was award-winning material compared to this tripe.)
You seem to have that arse-about-face.
Unix is like the English language - the exception *is* the rule - finding consistent UI just about anywhere is quite rare. Windows isn't quite up there with MacOS (which has slipped a bit with OS X) but it's streets ahead of unix in almost every aspect of UI consistency.
People who write for Unix by definition don't like the way Windows does things.
Really ? So how did anything get written for Unix before Windows was released ?
You remind me of one of my favourite quotes:
"FreeBSD is for people who love unix, Linux is for people who hate Windows".
No, he doesn't, because the criticism that any employee can slip any code into the shipping product is based on the assumption that the only person(/people) who knew about the Excel easter egg was the person (or persons) who wrote it. This assumption is, at best, questionable.
This is also ignoring the foolishness of taking that questionable assumption about the development practices at Microsft nearly 10 years ago and adding another assumption that nothing has changed since then. The dearth of easter eggs in Microsoft products since about 2000 (in the face of their relative frequency beforehand) are enough to make that second assumption, at best, highly unlikely.
I'm NOT saying that OSS is differant, but I would expect that in MS there could be an employee mad at the people above him for a number of reasons, where in open source development, alot of the time, development isn't a job process with commercial-software-pressure.
The problem is no causal link has been drawn between an easter egg in a ten year old version of Excel and disgruntled employees managing to get a backdoor into current and future products (or even past ones for that matter). Every criticism here is based on assumptions that are - at best - questionable.
Your definition of "efficiency" may not match everyone else's.
Now, if you're running a site with 5,000 transitory, "workhorse" style employees (like, say, a call centre) then your rules may be reasonable. But they suck for any sort of "real work" vis -a vis email communucations and do nothing but create bigger, more expensive problems down the track.
The user doesn't know what's good for them and has a tendency towards selfishness rather than social responsibility.
No, the user has a job to do. It is *your* responsibility to provide them with the tools that let them do their job in a productive manner. If your users are trying to treat email as a document repository, they're not doing it to annoy you, they're doing it because you haven't given them a better way of doing it [0].
To put it plainly, the data on their hard drives is disposable. They are notified of that. There is no way in hell that we are going to guarantee their data on their hard drives or attempt to get them to back up their own data (remember, they don't "get" this stuff and they WILL screw up or completely ignore the concept of backing up their data).
So you give them a measly 10M of centralised, backed-up email storage, then tell them they effectively can't even back up old mail for reference on their machines, because it might be lost. I shudder to think of the amount of potentially important business information that your policies have destroyed.
Our users may not be happy, but that's not what we're here for.
Yes, it is. The sole purpose of a company's IT department is to keep its users happy by providing them with the tools and resources they require to best do their job. There is no other business-related justification for its existence.
Care to give me a reasoned rebuttal?
Fundamentally, an IT department is supposed to be providing services to the rest of the business[1] so that it can maximise its productivity. It is *NOT* supposed to be dictating policty to the rest of the business. For most companies, the IT department is nothing but a financial liability - it generates no revenue of its own and costs a lot to run. It should be the IT department that is run according to the business requirements of the company, not vice versa.
This is not to say there is never any reason for draconian, minimalist, centralised resource management - schools being an excellent example of an appropriate environment to impose your rules - but for the typical business, they do far more harm than good because they prevent people from being productive.
I suspect, based on your comments, that you're coming from a background like a school, university or "grunt farm" (eg: call centre) type environment, with a relatively high user turnover rate and little justifiable need for referencing communucations more than a few weeks old.
[0] And it's critical to remember there that the definition of "better" is 100% in the hands of the user.
[1] There are lots and lots of IT departments who feel IT is the end, not the means. They are wrong. These are not companies you want to work for, unless you're lucky enough to be in the IT department and not subject to its rules.
I doubt it would make any difference. Actually, I'd be amazed if you even read them once.
I missed the part where Microsoft said they were going to do anything more than create an illusion of improved security.
Porbably because you're not prepared to believe anything else.
I missed the part where Microsoft haven't had a single easter egg since the flight simulator one.
There were a few, but I doubt you'd find any in products newer than 5 years old.
I missed the part where Microsoft didn't have an unpatched, widely exploited flaw for two weeks that let anyone embed runnable code in image files.
You've got a very, very weird idea of what "widely exploited" is. I suppose you think bird flu is currently at the global pandemic stage, as well ?
And I missed the part where Vista codebase was rewritten from scratch and so well audited that it didn't share the same flaw.
I must have missed the part where anything you've said has anything to do with your original point of "secret" code making it past managers[0] and into shipping products in recently released software.
Sorry, I guess I should pay more attention.
It's probably quite hard to see anything clearly past that massive chip on your shoulder.
[0] Actually I really don't think you've even got a point here. I've little doubt that managerial staff - certainly above the level of the developers at any rate - not only knew about the easter eggs, but approved their inclusion.
This tends to be one of those situations where what "should happen" and what "does happen" do not intersect.
If you're using drives without block relocation and a controller that doesn't do a periodic surface scan and block device level relocation, you're in for a world of hurt.
SATA does not handle these functions as well as SCSI in the real world. Unfortunate, but true.