Windows has certainly change _more_, but that's to be expected from a platform that's only 10 - 15 years old, vs 30. The claim that Windows is *always changing* is, IMHO, greatly exaggerated.
Ignoring that Vista has *substantial* (relatively speaking) "under the hood" modifications and improvements, there's not a lot about the "fundamental architecture" of NT that _needed_ changing. It's the technical equal of - and in many cases superior to - its contemporaries.
So what is it? Is it always changing (release to release) or is it not? Seems like you want it both ways. I think a big difference is with *nix, administrative tasks tend to happen much closer to the core than in Windows which seems much more abstracted. Its this abstraction that tends to change frequently in Windows. The fact that this continues to change and depreciates old methods of accomplishing tasks is generally indicitive of a lower quality solution.
I would argue such an outcome is incompatible with the prevalence of computing in the modern world. It's an inherently slow-growth scenario.
Perhaps the technology leaders have had more impact on the modern world than you give credit. Perhaps if Microsoft wasn't around, the original IBM PC would have flopped, upstart manufacturers (ie Compaq) would have continued the trend of building an operating system/apps for the hardware and the use of computers would have grown much slower. IBM gave creditbility to the concept of a PC for business use. It could have flopped and they could have easily axed the project for several years (or longer). It is very possible that many clone startups simply would not have been launched (no business market.. just a hobbiest market) and the other key player, Apple, would have maintained their higher-end machines (ie Lisa).
Interesting you say that, because my observations (and interactions) with pretty much everyone involved with Microsoft is that they *do* pride themselves on building "superior technical solutions" - within the constraints they have to work with.
I find that last part of your comment very interesting. I do agree that Microsoft does have perhaps some of the most brilliant people in the industry working for them. What are these constraints you are referring to? The marketing side of Microsoft? The structured, business centric management style (versus the free flowing, creative style of innovative technical companies)? The constraints of building software to satisfy both short-term and long-term shareholder wealth? I tend to believe that super technical solutions and feature complete designs do not bode well for long-term shareholder wealth.
I'll also point out that for 90% of users, the UI is one of the most important aspects of an Operating System. Particularly when the underlying core is already quite solid, there really isn't anywhere else where significant improvements are noticable or justified.
Are we referring to desktop Linux or Windows?? I'll agree, the Linux core is quite solid.. perhaps a few more GUI config tools might be nice but I think largely the UI is quite impressive (Both the CLI and GUI). As far as Windows, you just said there were "*substantial* (relatively speaking) "under the hood" modifications and improvements". Wasn't it just 5 years ago that Microsoft was announcing "*substantial* "under the hood" modifications and improvements" when it released Windows XP as an upgrade from Win98SE/Me? Seems to me that this core is not quite as solid as you think it is. The fact they have had so many issues getting their new version out on time seems that it is getting long in the tooth and not capable of meeting todays computing needs.. whereas *nix after 30+ years is still meeting the needs and filling niches.
Personally, I think it would be hilarious to put one of today's average unix users (ie: Linux brats) on to a thirty year old unix system. Heck, even just sitting them down in front of an early- mid-90s commercial unix would be quite entertaining.
To believe what I wrote implied that there have not been any advancement on *nix over 30 years (or even 10 years) is stupid. There are many commands and tools that are very much in use today that would be found on either of those systems. I was more inferring that many of the core philophosies (file system permissions, file hierarchy, help systems, shells, everything is a file, logging, multi-user capability, etc..) while perhaps improved, have not have to be junked and rebuilt (as with Windows). Even with NT to Windows 2003 (10 year span, same core kernel architecture), there are very marked differences in how day-to-day administration tasks are handled. With *nix, I find knowledge builds on itself and is not necessary "obsolete" nearly as often as in Windows.
90% of the "problems" in Windows (both perceived and actual) are because of the end users (which includes developers, in this context). If the user demographic was substantially different, the OS would be as well. This applies equally to unix - if you think unix would be the same today if it were on 95% of end user PCs, you're delusional. Similarly, if you think it subsequently wouldn't be suffering from the same "problems".
Obviously, this is purely hypothetical. It could very well be if Microsoft did not exist, the market would have been divided among multiple operating systems.. Perhaps without a dominate player, it would have fostered much more competition, a higher priority to write platform agnostic code and development tools that fostered cross platform development. Perhaps because of this, computing hardware would have been more expensive and as a result, things such as thin clients and server-centric computing would have prevailed. There is no way to know. As a result, it VERY WELL COULD BE that the demographic *COULD* be substantially different. It could very well be that network centric computing could have prevailed and as a result, networks were maintained by professional system administrators and their expertise in knowing all the pros/cons of various software solutions would have played a much bigger role in corporate technology meetings resulting in glossy sales pitches from inferior software vendors being dismissed.
The bottom line is Microsoft is a marketing company. It is not a company that prides itself on building superior technical solutions. Microsoft has been very successful because it was able to market itself better than the competition and was willing to engage in business practices that other companies may have felt were unethical or illegal. Many times throughout Microsoft's history, the marketing of a product determined feature sets and release dates. Microsoft understood early on that it was not a matter of building a great product but a product that was good enough that people would buy. As a result, a lot of fundamental functions found in other systems were absent or minimally developed in Windows. Check out Vista for example -- development on a flashy new interface took presidence over fundamental archtecture that would have made Vista technically superior (but harder to sell). A technology driven company would have put preference on the technically superior solution and side-lined the flashy graphics.. Microsoft being a marketing company has done and is doing the exact opposite.
Do you really think it would be any different had some other OS become the #1 OS?
Yes.
1. Other operating systems have a user security model that works. WinXP is still very difficult to maintain regular (non-admin) users. There is a LOT of workarounds that are required to make it function correctly (I think MS engineers call these "shims") due to application developers not testing for this scenario, unlike other systems (Mac OS and *NIX demand it).
2. This model has been utilized by *nix systems for over 30 years. While security issues have been found, they have largely been eliminated and it is infrequent to find escalation issues.
3. *nix systems are inherently very modular and consistent throughout. As a result, it is much easier to roll out a patch and rollback if necessary compared to Windows. Furthermore, given this architecture and well established APIs, it is easier and quicker to test patches and release them (not to mention provide competent admins actual source code access to understand the changes made -- let it be at the distribution level, corporate or organizational level).
4. *nix has a long history of being used in untrusted, multi-user settings (servers, thin clients, terminals, universities, banks, you name it..). Windows inherently *trusts* the user.. *sarcasm on* I think Bill Gates called this "Trustworthy Computing".. just trust everyone will do the right thing *sarcasm off*..
Windows/DOS from the beginning has assumed a single, trusted user. It wasn't until NT came around that a true security model was inplace, but even that didn't take to the mainstream until XP arrived in 2001. Even with the release of XP and the possibility of enhanced security (underprivleged users), Microsoft elected to favor backwards compatibility/ease of use and defauled to Administrative level access for all users instead of enforcing underprivleged users and slapping application developers upside the head to write good code (Though in the 3rd party's defense, even Windows XP has some issues with the entire underprileged user configuration..).
5. So now we are on the verge of "Vista".. while they are claiming a better security model, it appears that much of the legacy Windows apps are not functioning properly (even inside of Vista) -- ie the multiple steps required to remove an "all users" desktop icon.
Anyways.. thats my take. Sure, any operating system *could* be run in such a way where a user can load up malicious code and undoubtedly, there will be bugs in the source code (it is written by humans after all..) --- however, given the initial focus on Unix to be utilized on untrusted networks in a multi-user environment and the fact they have had over 30 years to fine tune the code, make the code modular and it is still very prominent today (it was done right the first time) makes me think it is a valid, time tested model.
Compare this to the Microsoft model where every few years they have the "bet the company" on a new model.. its apparent to me that they simply are not building a model that is solid. Over the past 20 years, they have released what I consider 5 distinct versions of Windows (Windows 1, Windows 2, Windows 3, Windows 95, Windows NT) -- all with major fundamental changes in how they function. Windows Vista could very well be the sixth version (Atleast it *should* have been.. but with all the feature cut, it might not be..). This is compared to *nix where a lot of fundamental philosophies and tools very much date back over 30 years.
As I said, it is standardized, but it's not MS's fault.
Nah. I don't buy it... this problem doesn't exist on other systems so it HAS to be MS's fault:).. so here is the reason: Regular user level access is inherently broken on Windows.
On a unix/linux system, a user has access to their own home folder and perhaps a temporary location -- thats about it. An application can be installed without having to *run* the application with super-user access (ie via a package manager). The package manager tells you _exactly_ what files it installed on the system and where those files are located.
So at best, the application can write multiple files in the users folder. If you get paranoid about this, there are security options in most *nix systems to not allow arbitrary create/modify dates on files. After an app is run, I could do a find in the users folder and locate each and every file that the application touched or modified during its execution and determine what type of data it wrote.
To get more sophisticated, I can setup versioning (as it is text files/regular files that I am dealing with) so I can see how a particular configuration changes over time. I don't get this with the registry. To do something similar with the registry would require a full backup of the registry then some method of combing the registry, one key at a time to compare the contents with a previous version. Needless to say, with the wide variety of system services running and reading/writing to the registry, determining which program wrote which keys can be nearly impossible (perhaps compare that against regmon or similar verbose logs.. yikes!!)
So having said all that.. it gets me back to some of my original complaints --> if the registry had a method to audit certain keys (ie query the registry for keys modified by a particular app during a certain time window) and had versioning capabilities to see how keys changed over time (ie revert back a section of the registry before a certain date) and if Windows' security model actually allowed users to run as regular users instead of administrators (even Vista's UAC seems quite broken to the point of severe aggervation) then the standard organizational structure inherent to the registry might be adequate.
If registry access is controlled through an API, it would seem that these types of features would be possible to impliment. It would significantly improve the usability of the registry to the point of being perhaps a preferred method of storing this data (ie provides a method to actually CLEAN OUT the registry when you uninstall an app..:-).
Are you sure your software is developed properly? Seems like writing registry entries to HKCU/Software/YourProduct and other data/settings to the user's "Application Data" folder should work and fit within the user level security of Windows.
"Local Settings" are intended for only the local computer (ie it is _NOT_ saved when doing roaming profiles, etc) -- Ideal for cache files, etc. Needless to say, I agree a PITA to have a novice navigate to that folder to do anything.
You should be testing your software using regular user accounts.. If it works under regular user accounts/with roaming profiles/etc than it sounds like the customer's issues are meritless and the sys admin is overzealous.
Sure there is - select the key and go File->Export using regedit.exe - or write your own to do the same thing.
Well yah.. but.. umm..
However, software developers (though more likely PHB's of software companies) have instead tormented us by trying to obfuscate where things are stored.
Just out of curiosity, what's your gripe with the registry?
While in *theory* the registry is ok, I find major problems in the following areas:
1. Migrating configs from one system to another system. On a *nix based system, I can simply copy the text configs and be on my way.. With the registry, there is no standard way to export the config of a given application easily and consistently.
2. Organization - ties into #1 -- there are LOTS of programs that store/update/modify registry information in various parts of the registry. As a result, it is *VERY* difficult to track down configuration issues unless it has been previously documented (ie KB article). Outlook tops my list for aggervation with this one.
3. Lack of alternate configs.. as programs store their configs in the registry, it is not possible to point an app to a different configuration. Ie- in a *nix config, I can simply point my apps to different config files and this adjusts runtime accordingly. Pretty nice for testing as well (much easier than attempting to locate a config key, export from registry, make a change, run it.. see if it works, reimport the reg key, yada yada..).
4. Lots of data loaded un-necessarily. The registry contains a LOT of information. Configs for apps I use infrequently still are loaded and still need to be dealt with (a source of general slowdown).
5. No ability to add comments to particular settings (ie a comment line in a text config file).
6. AFAIK, no built-in versioning control (can't see how the registry has changed over time)
Having said all that.. I do like the fact the registry provides a standard interface for configuration data (versus various config file formats when dealing with text configs). Though I would like to see separate registry files for each app (ie a user config, system-wide config) so I have the ability to see *exactly* what config settings a particular app uses and modifies.
Sounds like smoke and mirrors.. Make a big fuss about UAC that everyone who is testing is focused on UAC issues and DRM just silently passes without any media attention.
1. Centralized administration.. update software on the main server and your done = much lower administrative overhead. All thin clients offer same software offering.
2. If a thin client dies, within minutes you can swap it with another thin client and be back up and running (no extended downtime, reimaging, etc..).
3. Lower power consumption
4. Lower heat output.. quieter lab (servers are in the closet), lower A/C costs
5. Centralized network-wide update.. add another server to the cluster or update the existing servers and *all* clients benefit (no need to buy an entire lab worth of computers every few years..) -- think of computer failure/replacement before the upgrade cycle -- this has the potential for added administrative overhead (ie different disk images).
6. As more money is poured into the server backend, each user does get the added benefit -- common programs are already loaded in memory (fast startup times), user gets the capability of a multi-processor system with fast disk subsystem and gobs of memory.
7. Thin clients could be configured to boot into different servers.. ie rdp sessions to Windows and Linux servers.. this offers a wider range of software and choice for the user.
Possible drawbacks.. certain apps don't work well in this scenario -- ie full screen video playback, some multimedia functions, etc.. beefing up your network infrastructure might be necessary (ie multiple gigabit links to the servers setup on switch to full 100mbps to each client) depending on the intended application.
- Limited disk/flash drive functionality -- might be necessary, might not be (though most should be utilizing email or online transfer I'd imagine..)
- If backend is not sufficiently redundant (ie server cluster), there could be the potential for single-points of failure.
- Run away processes or heavy processing from a single user could adversely impact all users on a given server. Resource allocation or monitoring is required.
You seem to be forgetting that you're able to read Slashdot (or any Internet site) because the Internet allows you to connect from your desktop machine/laptop/etc.
To take this a bit further:
Open Standard: TCP/IP - free for anyone to impliment on any system. Allows the system to interact with millions of other systems.
Closed Standard: Historical Online Serivces (AOL, Compuserve, Prodigy, etc..). Not free for anyone to impliment. Only accessible from systems which the company felt was in *their* best interest. Not cross-network compatible (ie before the Internet forced them, you couldn't send an email from your AOL account to a Prodigy account). Not available for end-user develop (what you see is what you get).
Sadly, a majority of computer users never had to deal with those closed systems and live in a "Windows" world where they don't quite understand the importance of open standards. I think the closest (for them) might be instant messaging compared to email. I can send an email to anyone -- doesn't matter what email client, operating system, etc they use. However, instant messaging requires me to be on the same network, have different IM clients (granted there are unofficial multi-client apps) and they app speak different, incompatible languages.
So basically your having to shell out $1200+ for SMS server plus $50 per system to do what *should* be a simple task.
Even with this expensive addition for simply installing software, your *STILL* having to inconvience users by having them enable VNC and sitting around while you mess around with their computer when doing non-standards software installs (versus an SSH connection allowing you to work in the background). This does not eliminate *ANY* of my original complaints about having to fix apps with filemon/regmon and the associated costs. While it is getting better it is still no where near the ease-of-use that is on the *nix side. I seriously hope it gets MUCH better.
Sure, if you have MSI installers for your applications, you can set them up via group policy to show in the "Add New Programs" dialog. That is assuming, of course, the program is bundled in an MSI installer (very hit and miss) and the program is designed to work under a limited user account (unlikely). In reality though, it is a pain-in-the-ass. Your still messing with filemon/regmon to fix an app, resetting file permissions/registry security permissions and tinkering with the app to make it work. Linux and BSD both have far and away MANY MANY more apps that "just work" in a centralized manner and include the available tools to easily package up specialty apps to use the same mechanism.
1. User needs a particular application. Depending on company policy, the user may be able to install in their own home folder. If not, they could submit a request to suppot.
2. Support authorizes request, does a remote SSH connection to the users machine, installs the software (while the user is still working) and notifies user that the software was installed.
3. Software ties into centralized package management system so suppot can keep tabs on security notifications, updates, etc and roll it (easily) into the centralized update mechanism.
The Windows way:
1. The user needs software and does not have admin rights. The chances the user can install in their home folder is close to 0%. User requires IT to install.
2. IT receives the request and approves it. Perhaps IT gets lucky and the software is packaged as an MSI that can be installed via group policy. IT adds the install files to a network share and adjusts group policy. Tells user to restart or wait until next boot to get the update. Most likely the software cannot be installed via MSI (no auto-install MSI exists) and manual installation will happen (lets face it, creating an MSI is a PITA, especially for non-standard software).
3. IT contacts the user to tell them they will access their system remotely and to log out (no concurrent users in XP). User logs out and IT logs in remotely via RDP rendering the computer inaccessible for the user.
4. IT installs the software as administrator (via remote share). IT logs out and notifies the user the software was installed.
5. A little while later, user contacts support that the software does not run properly. Apparently the software needs to be run as admin first time to initiate some files in the program files folder. Admin repeates step 2 and 3 to finalize the software install. Unfortunately, the software refuses to run via RDP. Great. Support has to either have local user login as a temporary admin to run the software or admin has to physically access the machine.
6. Admin decides to go to the machine to step through the install. Runs the software, logs in as the user account and it still is not operational. Admin then has to pull out regmon/filemon to determine the issues (as the regular user). Once done, admin has to re-acquire admin level rights (ie runas or admin shares) to make file permission changes/registry security changes.
7. After a debugging session, the software finally works as expected for the user (hopefully). Admin then writes down all the steps required in the event of a software upgrade, future install, etc..
8. Admin decides to notify software company so hopefully next version is fixed.. software company's support is not interested and state "admin access required". Blech.
9. There is no central management of the software, so admin has to manually check for updates (along with the myraid of other software). Perhaps in the spare time, the admin writes a script to assist in the installation.
While I *will* say the _ideal_ corporate installation scenario on Windows is much better (load up MSIs and set a group policy to do auto-installs), there is WAY TOO MUCH software that simply does not fit the mold. Even software that does manage to utilize this method sometimes requires elaborate step-by-step (slipstream, etc..) to make it function right (ie MS Office 2003) in this scenario.
I'd honestly be happy with the sudo equivilent. Allow specific software to run via sudo w/o password (transparent to the user). This could solve the legacy issue while forcing future software development to test against regular user accounts.
Writing to a standard is important. I can label my page XHTML 1.0 Transitional compliant and know that if a browser supports that standard, my page will show properly (or atleast very close). I can develop in Firefox and have a high degree of confidence the design will render and function properly in Konqueror, Safari, Opera and other browsers.
Beyond this, I follow accessibility guidelines so individuals with disabilities can access the content with ease (ie color blind tests, speech synthesis navigation, access keys, etc.)
Being able to study and master a standard and write compliant pages is a very enjoyable process. Knowing my design is accessible for a wide range of users (users with disabilities, pdas, cellphones, desktops, laptops, various operating systems, etc..) is very important. Knowing that future versions of browsers should not break my pages (such as the issue with IE6 pages breaking with IE7) is reassuring that there is some future-proof to the design.
Unfortuantely we live in a world where Internet Explorer still dominates. And unfortunately a nicely developed compliant page tends to break in various ways in Internet Explorer -- this absolutely SUCKS. So the use of dumbed down syntax, hacks and other workarounds are the norm to attempt to make what IE6 renders look presentable while still maintaining compliance. PITA.
This is where it gets tricky. Do I *really* want to spend time attempting to shoehorn an elegant standards compliant webpage into IE6? Does my customer want to pay? I think the answer is a reassounding "NO". Developing *for* IE6 tends to be more ideal as many browsers have had to compromise to render poorly written IE-exclusive pages properly. Generally a customer is much more forgiving if a page doesn't render quite right outside of Internet Explorer. However, I believe in open standards and will continue to develop to the W3C standards *FIRST* and shoehorn it into IE as an afterthought. Granted, after learning the myriad of hacks and tricks and limitations of IE, this process does go much quicker- however, it still ultimately really sucks. Augh.
So many switchers want a drop-in replacement. This is not the case. If the expectation is a "free Windows" then they will be sorely disappointed and not give Linux a fair shake.
As a result, a successful Linux switcher needs one of the following:
1. Reason to switch to Linux (the "killer app") 2. Reason why Windows is not viable (security risk, drm, whatever..)
There are lots of areas where using Linux makes sense. However, it *does* require some learning of new methods of accomplishing tasks. Unfortunately, so many new people to Linux attempt to run it like Windows which is generally a bad idea (I find myself doing the reverse which tends to also be a bad idea).
Exactly what problem are they having? No Vista release? Its not like their computers will stop working.. at best, the problem is viruses/spyware/etc which joe sixpack Windows users believe that *all* systems have those problems. Besides, fear of the unknown generally outweighs known deficiencies.
Kiddies remember.. Microsoft problems (how to increase profit) are different from users problems (how to lower TCO, have a secure computing environment). As a result, Microsoft solutions address Microsoft problems. If it so happens to fix a user problem, then your lucky.
Who says that? Everyone I talk to still is "I have certain niche/industry app that outputs reports and only interfaces with Microsoft Office". Perhaps my customers are 5 years behind the curve. I guess on the plus side, they were REALLY easy to get migrated over to Firefox.:)
Free help is all great.. but lets face it.. its FREE. I frequent message boards and I, along with others, help many people. People who expect IRC or a message board to be the first source for problem resolution will generally be disappointed at the results.
If people are not willing to do some reading and self study to understand a topic should *really* consider paying someone to do it for them. This might be a paid enterprise distro like Red Hat or local consultant/LUG.
The expectation that you should get top priority (ie have someone chat with you in real-time about an issue) for FREE is ridiculous.
If you want free support, be understanding of the person providing it to you. They are not getting paid:
1. Understand the platform. There are lots of books on basics of Linux. FreeBSD has the excellent Freebsd Handbook. If you don't understand the underlying platform, your in for some issues. Getting up to speed on *nix fundamentals is important.
2. RTFM. Most applications at minimum will come with some form of installation/configuration docs. Use them to install your software.
Assuming there is a issue with #2 -- do a google search for the problem. If you have an error message, use that as your search term. Many times I'll find a thread on a mailing list that provides some additional clarification/resolution details.
If the search fails, be as concise as possible about your problem and post it to a forum that addresses that issue (ie subforum or mailing list for the particular application). Tell people what you have done so far, where the issue occurred and what you attempted to do to resolve it.
If you are in a position where you cannot wait a few days for the reply, I'd strongly recommend looking for paid support.
Will you get your problem resolved for free? Maybe not, but if you show that you are personally committed to resolving the issue then your chances of having the issue resolved will increase.
It's astonshing how little technicians know about the inner workings of Windows NT, routinely recommending reinstalls for totally fixable problems after their magic utilities fail.
Thats the biggest issue I have with Windows. I can run tools to get a pretty good idea if an issue is hardware related (memtest, burn-in tools, power monitoring, hard disk diagnostic, etc..) but if it is *not* and it *is* a Windows problem, where do you honestly start?
Close to 90% of all non-hardware issues w/Windows is the result of malware. Sure running a "magic utility" *might* get it -- a few years ago, it seemed to do a pretty good job.. nowadays, it is largely useless.. run a handful of anti-spyware tools, anti-virus tools and at the end of the exercise, it might *seem* clean only to have the issue reappear soon after (either from attaching to an app or user (going to website or receiving infected email)).
The remaining 10% end up being a mix, including startup issues where there is a lack of any information on how to address the issue. Unlike Linux where it is quite verbose as to what is happening with Windows your stuck with a list of things that already happened successfully (safe mode, command line mode).. quite pointless.
Then there is the random issues that cause occasional crashes or other abnormal operating behavior. Once again, without apps that have logging or debugging facilities, tracking down the case of these issues is once again very painstaking (perhaps a regmon/filemon might work.. most of the time you feel like your searching for a needle.. is it a registry setting? is it a corrupt file? is it permissions? who knows!)
Bottom line -- troubleshooting a Windows machine is largely a guessing game. Occassionally you might get lucky and have an easy issue that can be solved within a few guesses. Most of the time, I'm left scratching my head. It ends up being easier (And usually faster) to simply reinstall. Sad but true. Even for issues that should be relatively simple to resolve are difficult due to the lack of feedback from the system.
Things taken for granted on Linux like verbose debug information, verbose startup/shutdown (w/logging), ability to checksum the installed binaries to verify they haven't been tampered with, ability to view *all* running processes, minimal areas in the system for something to startup, users running underprileged by default (a huge one), etc make it much easier to troubleshoot.
I'm not saying that learning how Windows works is not helpful and *might* provide insight as to how to troubleshoot *some* issues quickly -- but ultimately *most* of the common problems end up being things that cannot be sufficiently fixed without a full restore/reinstall from a known, verified source.
It's not the operating system that makes it necessary to frequently "format c:"
Well I suppose that is true.. if you have a computer with Windows installed, without a network connection and without any users -- it should work a-ok for quite some time and not require a reinstall.
Infact, I have certain Windows machines that are not on an Internet accessible network, limit what users can do (basically run one or two apps) and overall work quite well.. NT4, Windows 2000 machines running for years (6-7 years or more) without much more than the occasional reboot (granted, not as good as some *nix systems, but for systems that do not require 24/7 uptime, an occasional reboot is not that bad).
However, for a common use, internet capable operating system, it sucks. As far as I am concerned, Microsoft stated that Internet Explorer is part of the operating system and as such, if this part of the OS allows you to go to a website (or open an HTML email via Outlook/Outlook Express) and it installs malware on your system WITHOUT you having to download and install it -- its *NOT* a user issue.
Of course, us "computer gurus" know that we can work around many of the inherant design flaws of Windows by simply utilizing other software (Firefox, thunderbird, etc..) in addition to due-dilligence in system maintenance, etc but ultimately, that is working around the issue and a poor excuse for claiming a system is fine and its all user error.
True.. but I don't think anyone will argue that there was even remotely a notion of "desktop linux" 15 years ago. This is relatively recent (last 4-5 years?)
So... if Linux has been unable to measure up sufficiently to take significant desktop share over the past fifteen years, what exactly makes you think it's going to suddenly become important?
It takes time. There is a saying "It takes 20 years to make an overnight success." So umm.. Linux still has 5 years to go.. hehe..:) Needless to say, month after month, I hear more and more news of people understanding what FOSS/open standards/etc is all about. It seems like Linux is the only desktop os that has ever gained marketshare against Microsoft's monopoly. When your talking about hundreds of millions of installations, it takes time.:-)
I'm not saying that OS X is _not_ a good system. I think it is the best complete package for a desktop operating system available right now for home/creative use and it provides a lot of very nice apps that are really innovative and all of that..
However, there are a lot of computing tasks that simply do not need a garageband or iMovie or iDVD or any of that stuff. There are millions of systems out there that may only use one or two specific apps or utilize a web-based app.. Or perhaps is used exclusively for data entry purposes or a myriad of other well-defined tasks. For these types of users, Linux makes a great choice. It has a lower cost, has great thin-client capabilities (less administrative overhead, lower initial costs, lower TCO, etc..) and for a lot of office/pop/etc tasks, it is a real strong competitor in the marketplace.
Slashdot Mirror
Stealth datacenters? Sweeet!
So what is it? Is it always changing (release to release) or is it not? Seems like you want it both ways. I think a big difference is with *nix, administrative tasks tend to happen much closer to the core than in Windows which seems much more abstracted. Its this abstraction that tends to change frequently in Windows. The fact that this continues to change and depreciates old methods of accomplishing tasks is generally indicitive of a lower quality solution.
Perhaps the technology leaders have had more impact on the modern world than you give credit. Perhaps if Microsoft wasn't around, the original IBM PC would have flopped, upstart manufacturers (ie Compaq) would have continued the trend of building an operating system/apps for the hardware and the use of computers would have grown much slower. IBM gave creditbility to the concept of a PC for business use. It could have flopped and they could have easily axed the project for several years (or longer). It is very possible that many clone startups simply would not have been launched (no business market
I find that last part of your comment very interesting. I do agree that Microsoft does have perhaps some of the most brilliant people in the industry working for them. What are these constraints you are referring to? The marketing side of Microsoft? The structured, business centric management style (versus the free flowing, creative style of innovative technical companies)? The constraints of building software to satisfy both short-term and long-term shareholder wealth? I tend to believe that super technical solutions and feature complete designs do not bode well for long-term shareholder wealth.
Are we referring to desktop Linux or Windows?? I'll agree, the Linux core is quite solid
To believe what I wrote implied that there have not been any advancement on *nix over 30 years (or even 10 years) is stupid. There are many commands and tools that are very much in use today that would be found on either of those systems. I was more inferring that many of the core philophosies (file system permissions, file hierarchy, help systems, shells, everything is a file, logging, multi-user capability, etc..) while perhaps improved, have not have to be junked and rebuilt (as with Windows). Even with NT to Windows 2003 (10 year span, same core kernel architecture), there are very marked differences in how day-to-day administration tasks are handled. With *nix, I find knowledge builds on itself and is not necessary "obsolete" nearly as often as in Windows.
Obviously, this is purely hypothetical. It could very well be if Microsoft did not exist, the market would have been divided among multiple operating systems.. Perhaps without a dominate player, it would have fostered much more competition, a higher priority to write platform agnostic code and development tools that fostered cross platform development. Perhaps because of this, computing hardware would have been more expensive and as a result, things such as thin clients and server-centric computing would have prevailed. There is no way to know. As a result, it VERY WELL COULD BE that the demographic *COULD* be substantially different. It could very well be that network centric computing could have prevailed and as a result, networks were maintained by professional system administrators and their expertise in knowing all the pros/cons of various software solutions would have played a much bigger role in corporate technology meetings resulting in glossy sales pitches from inferior software vendors being dismissed.
The bottom line is Microsoft is a marketing company. It is not a company that prides itself on building superior technical solutions. Microsoft has been very successful because it was able to market itself better than the competition and was willing to engage in business practices that other companies may have felt were unethical or illegal. Many times throughout Microsoft's history, the marketing of a product determined feature sets and release dates. Microsoft understood early on that it was not a matter of building a great product but a product that was good enough that people would buy. As a result, a lot of fundamental functions found in other systems were absent or minimally developed in Windows. Check out Vista for example -- development on a flashy new interface took presidence over fundamental archtecture that would have made Vista technically superior (but harder to sell). A technology driven company would have put preference on the technically superior solution and side-lined the flashy graphics.. Microsoft being a marketing company has done and is doing the exact opposite.
Yes.
1. Other operating systems have a user security model that works. WinXP is still very difficult to maintain regular (non-admin) users. There is a LOT of workarounds that are required to make it function correctly (I think MS engineers call these "shims") due to application developers not testing for this scenario, unlike other systems (Mac OS and *NIX demand it).
2. This model has been utilized by *nix systems for over 30 years. While security issues have been found, they have largely been eliminated and it is infrequent to find escalation issues.
3. *nix systems are inherently very modular and consistent throughout. As a result, it is much easier to roll out a patch and rollback if necessary compared to Windows. Furthermore, given this architecture and well established APIs, it is easier and quicker to test patches and release them (not to mention provide competent admins actual source code access to understand the changes made -- let it be at the distribution level, corporate or organizational level).
4. *nix has a long history of being used in untrusted, multi-user settings (servers, thin clients, terminals, universities, banks, you name it..). Windows inherently *trusts* the user
Windows/DOS from the beginning has assumed a single, trusted user. It wasn't until NT came around that a true security model was inplace, but even that didn't take to the mainstream until XP arrived in 2001. Even with the release of XP and the possibility of enhanced security (underprivleged users), Microsoft elected to favor backwards compatibility/ease of use and defauled to Administrative level access for all users instead of enforcing underprivleged users and slapping application developers upside the head to write good code (Though in the 3rd party's defense, even Windows XP has some issues with the entire underprileged user configuration..).
5. So now we are on the verge of "Vista"
Anyways.. thats my take. Sure, any operating system *could* be run in such a way where a user can load up malicious code and undoubtedly, there will be bugs in the source code (it is written by humans after all..) --- however, given the initial focus on Unix to be utilized on untrusted networks in a multi-user environment and the fact they have had over 30 years to fine tune the code, make the code modular and it is still very prominent today (it was done right the first time) makes me think it is a valid, time tested model.
Compare this to the Microsoft model where every few years they have the "bet the company" on a new model.. its apparent to me that they simply are not building a model that is solid. Over the past 20 years, they have released what I consider 5 distinct versions of Windows (Windows 1, Windows 2, Windows 3, Windows 95, Windows NT) -- all with major fundamental changes in how they function. Windows Vista could very well be the sixth version (Atleast it *should* have been.. but with all the feature cut, it might not be..). This is compared to *nix where a lot of fundamental philosophies and tools very much date back over 30 years.
On a unix/linux system, a user has access to their own home folder and perhaps a temporary location -- thats about it. An application can be installed without having to *run* the application with super-user access (ie via a package manager). The package manager tells you _exactly_ what files it installed on the system and where those files are located.
So at best, the application can write multiple files in the users folder. If you get paranoid about this, there are security options in most *nix systems to not allow arbitrary create/modify dates on files. After an app is run, I could do a find in the users folder and locate each and every file that the application touched or modified during its execution and determine what type of data it wrote.
To get more sophisticated, I can setup versioning (as it is text files/regular files that I am dealing with) so I can see how a particular configuration changes over time. I don't get this with the registry. To do something similar with the registry would require a full backup of the registry then some method of combing the registry, one key at a time to compare the contents with a previous version. Needless to say, with the wide variety of system services running and reading/writing to the registry, determining which program wrote which keys can be nearly impossible (perhaps compare that against regmon or similar verbose logs.. yikes!!)
So having said all that.. it gets me back to some of my original complaints --> if the registry had a method to audit certain keys (ie query the registry for keys modified by a particular app during a certain time window) and had versioning capabilities to see how keys changed over time (ie revert back a section of the registry before a certain date) and if Windows' security model actually allowed users to run as regular users instead of administrators (even Vista's UAC seems quite broken to the point of severe aggervation) then the standard organizational structure inherent to the registry might be adequate.
If registry access is controlled through an API, it would seem that these types of features would be possible to impliment. It would significantly improve the usability of the registry to the point of being perhaps a preferred method of storing this data (ie provides a method to actually CLEAN OUT the registry when you uninstall an app..
Are you sure your software is developed properly? Seems like writing registry entries to HKCU/Software/YourProduct and other data/settings to the user's "Application Data" folder should work and fit within the user level security of Windows.
.. If it works under regular user accounts/with roaming profiles/etc than it sounds like the customer's issues are meritless and the sys admin is overzealous.
"Local Settings" are intended for only the local computer (ie it is _NOT_ saved when doing roaming profiles, etc) -- Ideal for cache files, etc. Needless to say, I agree a PITA to have a novice navigate to that folder to do anything.
You should be testing your software using regular user accounts
Well yah.. but
Thats the issue.
Just out of curiosity, what's your gripe with the registry?
.. as programs store their configs in the registry, it is not possible to point an app to a different configuration. Ie- in a *nix config, I can simply point my apps to different config files and this adjusts runtime accordingly. Pretty nice for testing as well (much easier than attempting to locate a config key, export from registry, make a change, run it.. see if it works, reimport the reg key, yada yada..).
.. I do like the fact the registry provides a standard interface for configuration data (versus various config file formats when dealing with text configs). Though I would like to see separate registry files for each app (ie a user config, system-wide config) so I have the ability to see *exactly* what config settings a particular app uses and modifies.
While in *theory* the registry is ok, I find major problems in the following areas:
1. Migrating configs from one system to another system. On a *nix based system, I can simply copy the text configs and be on my way.. With the registry, there is no standard way to export the config of a given application easily and consistently.
2. Organization - ties into #1 -- there are LOTS of programs that store/update/modify registry information in various parts of the registry. As a result, it is *VERY* difficult to track down configuration issues unless it has been previously documented (ie KB article). Outlook tops my list for aggervation with this one.
3. Lack of alternate configs
4. Lots of data loaded un-necessarily. The registry contains a LOT of information. Configs for apps I use infrequently still are loaded and still need to be dealt with (a source of general slowdown).
5. No ability to add comments to particular settings (ie a comment line in a text config file).
6. AFAIK, no built-in versioning control (can't see how the registry has changed over time)
Having said all that
Sounds like smoke and mirrors.. Make a big fuss about UAC that everyone who is testing is focused on UAC issues and DRM just silently passes without any media attention.
Brilliant!
Thin clients are ideal in those situations:
.. quieter lab (servers are in the closet), lower A/C costs
.. add another server to the cluster or update the existing servers and *all* clients benefit (no need to buy an entire lab worth of computers every few years..) -- think of computer failure/replacement before the upgrade cycle -- this has the potential for added administrative overhead (ie different disk images).
.. ie rdp sessions to Windows and Linux servers .. this offers a wider range of software and choice for the user.
.. certain apps don't work well in this scenario -- ie full screen video playback, some multimedia functions, etc.. beefing up your network infrastructure might be necessary (ie multiple gigabit links to the servers setup on switch to full 100mbps to each client) depending on the intended application.
1. Centralized administration.. update software on the main server and your done = much lower administrative overhead. All thin clients offer same software offering.
2. If a thin client dies, within minutes you can swap it with another thin client and be back up and running (no extended downtime, reimaging, etc..).
3. Lower power consumption
4. Lower heat output
5. Centralized network-wide update
6. As more money is poured into the server backend, each user does get the added benefit -- common programs are already loaded in memory (fast startup times), user gets the capability of a multi-processor system with fast disk subsystem and gobs of memory.
7. Thin clients could be configured to boot into different servers
Possible drawbacks
- Limited disk/flash drive functionality -- might be necessary, might not be (though most should be utilizing email or online transfer I'd imagine..)
- If backend is not sufficiently redundant (ie server cluster), there could be the potential for single-points of failure.
- Run away processes or heavy processing from a single user could adversely impact all users on a given server. Resource allocation or monitoring is required.
You seem to be forgetting that you're able to read Slashdot (or any Internet site) because the Internet allows you to connect from your desktop machine/laptop/etc.
To take this a bit further:
Open Standard: TCP/IP - free for anyone to impliment on any system. Allows the system to interact with millions of other systems.
Closed Standard: Historical Online Serivces (AOL, Compuserve, Prodigy, etc..). Not free for anyone to impliment. Only accessible from systems which the company felt was in *their* best interest. Not cross-network compatible (ie before the Internet forced them, you couldn't send an email from your AOL account to a Prodigy account). Not available for end-user develop (what you see is what you get).
Sadly, a majority of computer users never had to deal with those closed systems and live in a "Windows" world where they don't quite understand the importance of open standards. I think the closest (for them) might be instant messaging compared to email. I can send an email to anyone -- doesn't matter what email client, operating system, etc they use. However, instant messaging requires me to be on the same network, have different IM clients (granted there are unofficial multi-client apps) and they app speak different, incompatible languages.
So basically your having to shell out $1200+ for SMS server plus $50 per system to do what *should* be a simple task.
Even with this expensive addition for simply installing software, your *STILL* having to inconvience users by having them enable VNC and sitting around while you mess around with their computer when doing non-standards software installs (versus an SSH connection allowing you to work in the background). This does not eliminate *ANY* of my original complaints about having to fix apps with filemon/regmon and the associated costs. While it is getting better it is still no where near the ease-of-use that is on the *nix side. I seriously hope it gets MUCH better.
Sure, if you have MSI installers for your applications, you can set them up via group policy to show in the "Add New Programs" dialog. That is assuming, of course, the program is bundled in an MSI installer (very hit and miss) and the program is designed to work under a limited user account (unlikely). In reality though, it is a pain-in-the-ass. Your still messing with filemon/regmon to fix an app, resetting file permissions/registry security permissions and tinkering with the app to make it work. Linux and BSD both have far and away MANY MANY more apps that "just work" in a centralized manner and include the available tools to easily package up specialty apps to use the same mechanism.
Your absolutely right. The *nix way:
1. User needs a particular application. Depending on company policy, the user may be able to install in their own home folder. If not, they could submit a request to suppot.
2. Support authorizes request, does a remote SSH connection to the users machine, installs the software (while the user is still working) and notifies user that the software was installed.
3. Software ties into centralized package management system so suppot can keep tabs on security notifications, updates, etc and roll it (easily) into the centralized update mechanism.
The Windows way:
1. The user needs software and does not have admin rights. The chances the user can install in their home folder is close to 0%. User requires IT to install.
2. IT receives the request and approves it. Perhaps IT gets lucky and the software is packaged as an MSI that can be installed via group policy. IT adds the install files to a network share and adjusts group policy. Tells user to restart or wait until next boot to get the update. Most likely the software cannot be installed via MSI (no auto-install MSI exists) and manual installation will happen (lets face it, creating an MSI is a PITA, especially for non-standard software).
3. IT contacts the user to tell them they will access their system remotely and to log out (no concurrent users in XP). User logs out and IT logs in remotely via RDP rendering the computer inaccessible for the user.
4. IT installs the software as administrator (via remote share). IT logs out and notifies the user the software was installed.
5. A little while later, user contacts support that the software does not run properly. Apparently the software needs to be run as admin first time to initiate some files in the program files folder. Admin repeates step 2 and 3 to finalize the software install. Unfortunately, the software refuses to run via RDP. Great. Support has to either have local user login as a temporary admin to run the software or admin has to physically access the machine.
6. Admin decides to go to the machine to step through the install. Runs the software, logs in as the user account and it still is not operational. Admin then has to pull out regmon/filemon to determine the issues (as the regular user). Once done, admin has to re-acquire admin level rights (ie runas or admin shares) to make file permission changes/registry security changes.
7. After a debugging session, the software finally works as expected for the user (hopefully). Admin then writes down all the steps required in the event of a software upgrade, future install, etc..
8. Admin decides to notify software company so hopefully next version is fixed.. software company's support is not interested and state "admin access required". Blech.
9. There is no central management of the software, so admin has to manually check for updates (along with the myraid of other software). Perhaps in the spare time, the admin writes a script to assist in the installation.
While I *will* say the _ideal_ corporate installation scenario on Windows is much better (load up MSIs and set a group policy to do auto-installs), there is WAY TOO MUCH software that simply does not fit the mold. Even software that does manage to utilize this method sometimes requires elaborate step-by-step (slipstream, etc..) to make it function right (ie MS Office 2003) in this scenario.
I'd honestly be happy with the sudo equivilent. Allow specific software to run via sudo w/o password (transparent to the user). This could solve the legacy issue while forcing future software development to test against regular user accounts.
Writing to a standard is important. I can label my page XHTML 1.0 Transitional compliant and know that if a browser supports that standard, my page will show properly (or atleast very close). I can develop in Firefox and have a high degree of confidence the design will render and function properly in Konqueror, Safari, Opera and other browsers.
Beyond this, I follow accessibility guidelines so individuals with disabilities can access the content with ease (ie color blind tests, speech synthesis navigation, access keys, etc.)
Being able to study and master a standard and write compliant pages is a very enjoyable process. Knowing my design is accessible for a wide range of users (users with disabilities, pdas, cellphones, desktops, laptops, various operating systems, etc..) is very important. Knowing that future versions of browsers should not break my pages (such as the issue with IE6 pages breaking with IE7) is reassuring that there is some future-proof to the design.
Unfortuantely we live in a world where Internet Explorer still dominates. And unfortunately a nicely developed compliant page tends to break in various ways in Internet Explorer -- this absolutely SUCKS. So the use of dumbed down syntax, hacks and other workarounds are the norm to attempt to make what IE6 renders look presentable while still maintaining compliance. PITA.
This is where it gets tricky. Do I *really* want to spend time attempting to shoehorn an elegant standards compliant webpage into IE6? Does my customer want to pay? I think the answer is a reassounding "NO". Developing *for* IE6 tends to be more ideal as many browsers have had to compromise to render poorly written IE-exclusive pages properly. Generally a customer is much more forgiving if a page doesn't render quite right outside of Internet Explorer. However, I believe in open standards and will continue to develop to the W3C standards *FIRST* and shoehorn it into IE as an afterthought. Granted, after learning the myriad of hacks and tricks and limitations of IE, this process does go much quicker- however, it still ultimately really sucks. Augh.
Windows != Linux and Linux != Windows
So many switchers want a drop-in replacement. This is not the case. If the expectation is a "free Windows" then they will be sorely disappointed and not give Linux a fair shake.
As a result, a successful Linux switcher needs one of the following:
1. Reason to switch to Linux (the "killer app")
2. Reason why Windows is not viable (security risk, drm, whatever..)
There are lots of areas where using Linux makes sense. However, it *does* require some learning of new methods of accomplishing tasks. Unfortunately, so many new people to Linux attempt to run it like Windows which is generally a bad idea (I find myself doing the reverse which tends to also be a bad idea).
For those who were wondering.. the 24hour fitness location does indeed appear to be legit. It is in a shopping center at Point Loma in San Diego.
Exactly what problem are they having? No Vista release? Its not like their computers will stop working .. at best, the problem is viruses/spyware/etc which joe sixpack Windows users believe that *all* systems have those problems. Besides, fear of the unknown generally outweighs known deficiencies.
Kiddies remember.. Microsoft problems (how to increase profit) are different from users problems (how to lower TCO, have a secure computing environment). As a result, Microsoft solutions address Microsoft problems. If it so happens to fix a user problem, then your lucky.
Who says that? Everyone I talk to still is "I have certain niche/industry app that outputs reports and only interfaces with Microsoft Office". Perhaps my customers are 5 years behind the curve. I guess on the plus side, they were REALLY easy to get migrated over to Firefox. :)
Free help is all great .. but lets face it .. its FREE. I frequent message boards and I, along with others, help many people. People who expect IRC or a message board to be the first source for problem resolution will generally be disappointed at the results.
If people are not willing to do some reading and self study to understand a topic should *really* consider paying someone to do it for them. This might be a paid enterprise distro like Red Hat or local consultant/LUG.
The expectation that you should get top priority (ie have someone chat with you in real-time about an issue) for FREE is ridiculous.
If you want free support, be understanding of the person providing it to you. They are not getting paid:
1. Understand the platform. There are lots of books on basics of Linux. FreeBSD has the excellent Freebsd Handbook. If you don't understand the underlying platform, your in for some issues. Getting up to speed on *nix fundamentals is important.
2. RTFM. Most applications at minimum will come with some form of installation/configuration docs. Use them to install your software.
Assuming there is a issue with #2 -- do a google search for the problem. If you have an error message, use that as your search term. Many times I'll find a thread on a mailing list that provides some additional clarification/resolution details.
If the search fails, be as concise as possible about your problem and post it to a forum that addresses that issue (ie subforum or mailing list for the particular application). Tell people what you have done so far, where the issue occurred and what you attempted to do to resolve it.
If you are in a position where you cannot wait a few days for the reply, I'd strongly recommend looking for paid support.
Will you get your problem resolved for free? Maybe not, but if you show that you are personally committed to resolving the issue then your chances of having the issue resolved will increase.
It's astonshing how little technicians know about the inner workings of Windows NT, routinely recommending reinstalls for totally fixable problems after their magic utilities fail.
.. is it a registry setting? is it a corrupt file? is it permissions? who knows!)
Thats the biggest issue I have with Windows. I can run tools to get a pretty good idea if an issue is hardware related (memtest, burn-in tools, power monitoring, hard disk diagnostic, etc..) but if it is *not* and it *is* a Windows problem, where do you honestly start?
Close to 90% of all non-hardware issues w/Windows is the result of malware. Sure running a "magic utility" *might* get it -- a few years ago, it seemed to do a pretty good job.. nowadays, it is largely useless.. run a handful of anti-spyware tools, anti-virus tools and at the end of the exercise, it might *seem* clean only to have the issue reappear soon after (either from attaching to an app or user (going to website or receiving infected email)).
The remaining 10% end up being a mix, including startup issues where there is a lack of any information on how to address the issue. Unlike Linux where it is quite verbose as to what is happening with Windows your stuck with a list of things that already happened successfully (safe mode, command line mode).. quite pointless.
Then there is the random issues that cause occasional crashes or other abnormal operating behavior. Once again, without apps that have logging or debugging facilities, tracking down the case of these issues is once again very painstaking (perhaps a regmon/filemon might work.. most of the time you feel like your searching for a needle
Bottom line -- troubleshooting a Windows machine is largely a guessing game. Occassionally you might get lucky and have an easy issue that can be solved within a few guesses. Most of the time, I'm left scratching my head. It ends up being easier (And usually faster) to simply reinstall. Sad but true. Even for issues that should be relatively simple to resolve are difficult due to the lack of feedback from the system.
Things taken for granted on Linux like verbose debug information, verbose startup/shutdown (w/logging), ability to checksum the installed binaries to verify they haven't been tampered with, ability to view *all* running processes, minimal areas in the system for something to startup, users running underprileged by default (a huge one), etc make it much easier to troubleshoot.
I'm not saying that learning how Windows works is not helpful and *might* provide insight as to how to troubleshoot *some* issues quickly -- but ultimately *most* of the common problems end up being things that cannot be sufficiently fixed without a full restore/reinstall from a known, verified source.
It's not the operating system that makes it necessary to frequently "format c:"
Well I suppose that is true.. if you have a computer with Windows installed, without a network connection and without any users -- it should work a-ok for quite some time and not require a reinstall.
Infact, I have certain Windows machines that are not on an Internet accessible network, limit what users can do (basically run one or two apps) and overall work quite well.. NT4, Windows 2000 machines running for years (6-7 years or more) without much more than the occasional reboot (granted, not as good as some *nix systems, but for systems that do not require 24/7 uptime, an occasional reboot is not that bad).
However, for a common use, internet capable operating system, it sucks. As far as I am concerned, Microsoft stated that Internet Explorer is part of the operating system and as such, if this part of the OS allows you to go to a website (or open an HTML email via Outlook/Outlook Express) and it installs malware on your system WITHOUT you having to download and install it -- its *NOT* a user issue.
Of course, us "computer gurus" know that we can work around many of the inherant design flaws of Windows by simply utilizing other software (Firefox, thunderbird, etc..) in addition to due-dilligence in system maintenance, etc but ultimately, that is working around the issue and a poor excuse for claiming a system is fine and its all user error.
New? Linux is about 15 years old.
:) Needless to say, month after month, I hear more and more news of people understanding what FOSS/open standards/etc is all about. It seems like Linux is the only desktop os that has ever gained marketshare against Microsoft's monopoly. When your talking about hundreds of millions of installations, it takes time. :-)
True.. but I don't think anyone will argue that there was even remotely a notion of "desktop linux" 15 years ago. This is relatively recent (last 4-5 years?)
So... if Linux has been unable to measure up sufficiently to take significant desktop share over the past fifteen years, what exactly makes you think it's going to suddenly become important?
It takes time. There is a saying "It takes 20 years to make an overnight success." So umm.. Linux still has 5 years to go.. hehe..
I'm not saying that OS X is _not_ a good system. I think it is the best complete package for a desktop operating system available right now for home/creative use and it provides a lot of very nice apps that are really innovative and all of that..
However, there are a lot of computing tasks that simply do not need a garageband or iMovie or iDVD or any of that stuff. There are millions of systems out there that may only use one or two specific apps or utilize a web-based app.. Or perhaps is used exclusively for data entry purposes or a myriad of other well-defined tasks. For these types of users, Linux makes a great choice. It has a lower cost, has great thin-client capabilities (less administrative overhead, lower initial costs, lower TCO, etc..) and for a lot of office/pop/etc tasks, it is a real strong competitor in the marketplace.
I've never seen such blatant imitation as KDE's Control Center is of OS X's System Preferences. I actually laughed out loud the first time I saw it.
.. all depends on what you want to do with the system. It is a tool like any other system.
Just curious.. what are you talking about?
KDE control center screen shot
Apple System Preferences
As far as linux "catching up"