Slashdot Mirror
Windows Nearly Ready For Desktop Use
wallykeyster writes "NewsForge (ed: a Slashdot sister site) has an interesting review of Windows XP Home, written from the perspective of a longtime Linux user (ed: Editor roblimo). The article clearly is intended to be somewhat humorous while making a point to the 'Linux isn't ready for the desktop' crowd. The reviewer does a fair job of pointing out the strengths of Windows along with the weaknesses that would be apparent to someone trying to make the switch from Linux." From the article: "Windows XP can't be considered consumer-ready until it has driver support for common LCD monitors during its installation and bootup procedure, especially if those monitors are easily and routinely recognized by popular Linux distributions. It's possible that the monitor manufacturers aren't willing to give Microsoft and other proprietary operating system companies the information they need to create appropriate drivers and that the manufacturers, not Microsoft, deserve the blame for this problem."
Sources whom I consider accurate have told me that despite Microsoft's claims that Longtooth will be released by 2006 or 2007, the planned release date is actually late in 2019. Microsoft's secret goals for this version are:
Microsoft will accomplish these goals through a variety of changes. First, Longtooth will no longer be based on the Windows NT design philosophy, as were Windows 2000 and XP. Instead, Microsoft will release MS-DOS 9.0 2003, a 64-bit multithreaded DOS written in VisualBASIC.Net, and Windows Longtooth will run on top of that. Also, Longtooth will contain more code changes than any previous version of Windows, both in the number of changed source lines of code (SLOCs) and in the percentage of the total Windows codebase changed. Tremendous numbers of new features are being implemented in completely new code.
More importantly, Microsoft employees are combing through the codebase, in a relentless search for code that is mature, stabilized, and proven. This search has proved difficult, but when found, such code will be marked for reimplementation. I'm told that most of this code will be reimplemented in VisualBASIC.NET, even if the prior version was written in another language, such as C or C++. Programmers making the new VisualBasic.NET code are not allowed to look at the code that already exists, so that fixes to known issues will not be known until well after the software is deployed to millions of users.
The reason for these changes is simple: Study after study conducted by Microsoft has proven that security through obscurity is the only way to go, especially in an operating system deployed to millions of users, with many instances running mission critical applications in finance, industry, government, and other sectors. Microsoft has identified that viruses, worms, spam, spyware, adware, malware, hackers, and phreakers are able to compromise Windows security because vulnerabilities in the code are known. By changing much of the codebase, especially the stablest and most proven parts, Microsoft will thwart the efforts of malicious programmers, as it will take time for them to find the new vulnerabilities in the unknown code.
To meet Microsoft's first goal of reducing the user's perception of the complexity of Windows, Microsoft will integrate a new technology, dubbed Microsoft Windows User Simplicity And Security Manager 2003, into Longtooth. This technology will hide all configuration settings from the user. All settings will be completely automatic, and the user will have no need to know or care what is under the hood. In reality, Longtooth will be the most complex version of Windows yet, with thousands of configuration settings controlling nearly every function of the operating system. The settings will be produced by discovery algorithms designed to automatically set a "sane" configuration. Since there will be no interface to modify any setting, the user will have no choice in his configuration, thus simplifying the user's perception of the system's complexity.
To meet the second goal of increased security, these settings will be scattered throughout the OS, its components, and in other areas of the file system. For example, Microsoft knows that viruses, worms, spam, spyware, adware, malware, hackers, and phreakers are interested in moving the icons on user desktops without the user's permission, so settings controlling the number and size of icons appearing on the desktop will be scattered throughout parts of the registry, batch files, .ini files, web bookmarks, in the Windows kernel, in the file allocation table, in th
large parts of it read as a critique not of windows per se but rather of the whole money-for-software framework.
examples:
Base Cost (as compared to Linux)
CD-Key
Expense of Additional Applications
lysergically yours
Great article! On more than one level:
On the other hand, I'd like to make my own contribution as to one of the most ongoing and glaring "needs fixing" of XP....
I think one thing that will eventually make Windows XP for HOME (or PRO) ready for the desktop is fixing the START button. I'm still trying to explain to some of the people I have to support "LOGOFF" and "TURN OFF COMPUTER" are accessed by clicking the START button. It's hard to explain to them why when even I don't get it.
Microsoft:
Linux nearly ready for server use.
It could be worse, it could be Monday.
I wonder if that was the point? By the standards that the ``Linux isn't ready for the desktop'' crowd apply to Linux, Windows isn't ready for the desktop, either.
I haven't tried to install OSX, so I can say that no OS that I am familiar with is ``ready for the desktop'' by those standards.
Roblimo just took the standard ``Linux isn't ready for the desktop'' article, replaced Linux with Windows and visa versa, and threw in a couple of very accurate slams at Windows weak points.
Good parody, based on truth. That's why it was funny.
See what I've been reading.
And I don't want to start another flamewar about what the best desktop for Linux is...
Why the ferk does a monitor even need a driver?
It bugs me when mundane devices need drivers.
Like keyboards and monitors.
What's next, my power supply will need a driver?
https://www.accountkiller.com/removal-requested
> A much better experiment would be to find people who have NEVER used computers in ANY form or OS. Give them
;)
> a configured Windows machine, and a configured Linux machine. THEN see which one gets used more.
> Now that would actually be a USEFUL study.
And it's been done. And GNU/Linux won. And it was something like RedHat 7.3 with Gnome 1.4.
Hopefully somebody still has that story, as I've long since lost the link
25% Funny, 25% Insightful, 25% Informative, 25% Troll
So I've been playing with Linux on my desktop receantly, Fedora Core 3 specifily. I've used Linux in server settings for a long time but never on the desktop, figure it'd be good to get some experience. Now, as you point out, when Windows is installed, it lacks hardware OpenGL acceleration. It does have a basic software layer, but it's slow. Direct3d acceleration also doesn't work. It only does 2d, and not all that fast. Easily solved, however. I go to ATi's site, download the driver, and click install, the rest is taken care of. DirectX, OpenGL, and the GDI are all fully accelerated.
So I get Fedora installed. It comes up, and recognises my card correctly and we go. However the interface is a little sluggish when it comes to refreshes. I run a GL app and discover it's using software rendering which is very slow, and low quality. So I again go to ATi's site and download the drivers, ATi does have Linux drivers as well as Windows. Then begins my quest:
The drivers are RPM, so I tell them to install, no dice, conflicts with Mesa. Removing that proves to completely hose X. Ok so leave Mesa there, force the ATi installation. X comes up and it looks like it's using the ATi driver, but still no acceleration. Dig around on the net, turns out you have to run a script to make them work. Ok, run script, no dice, can't find something. Consult with Linux guy, says the error means they need kernel headers, maybe source too. K, thought those were there, I told it to install all the dev stuff. Whatever, get kernel source, recompile kernel, and now headers are there. Try script again, no dice. More digging turns up reference to drivers being for 2.6.10 not 2.6.11 but try these patches. Patch files, run script, success. Then run next script, no dice, won't install the module. Linux guy looks at it, not sure why. Decide to just try 2.6.10 since I have something else that likes that anyhow, there's actually an apt package (no not yum, apt, apparantly you can get that for Fedora) that is supposed to make it work all nice and easy with that. Try that, it goes and installs successfully. Reboot and.... reports the kernel module is incompatible on bootup.
And that's where it stands until I go back to work next week.
I'm failing to see the big advantage here. While it looks like Mesa is a more complete implementation of GL than comes with Windows, it's still software so the quality is horrible and it;s so slow that it's totally unusable for professional work, or even gaming.
Now in Windows the problem was a simple fix. Download a driver, click install. Everything else was handled and it works superbly. In Linux, I've gone through quite a lengthy process and it STILL doesn't work. I'm sure I'll solve the problem on Tuesday, however I can gaurentee a non-techie would have given up long ago.