But don't even try and tell me that it wasn't a buisness decision to fight Microsoft.
Of course it was. But Sun competed with Microsoft by doing something entirely different from anything Microsoft had done: a safe, cross-platform language and library based on C++ syntax and "Smalltalkish" semantics. Microsoft's response to Java/JVM is to make an almost identical, but incompatible, product.
It was designed to do one thing -- make money for Sun.
Actually, it wasn't designed for that at all. It was an accidental success: the industry was ready for a simple OOL, and the promise of applets pushed it over the edge. Once Sun saw Java catch on, they heavily promoted it.
If Microsoft were "proprietary" in the same way with their systems as Sun is with Java, I'd be quite happy. In any case, my point was not about whether Java was proprietary or not, or even whether it is a good language, but about who was "ripping off" who. The fact remains that Java was a new language and system in the marketplace when Sun created it, while C#/.NET is basically a carbon copy.
Funny... most people I've talked to will be using.NET for back-end server stuff (eg. server scripting) and front-end client stuff. Not for Application Service Provider stuff.
Java was natural language evolution: it was created out of a technical need for a simple language with features from Smalltalk, Pascal, and C++. When Sun created Java, they certainly weren't in competition with Smalltalk, Pascal, or C++ vendors.
C#/.NET, on the other hand, was a direct business response by Microsoft to Java. Microsoft saw that Java was doing well and couldn't bear to let Sun have the market. So, they came out with their own system that's incompatible but has an almost identical feature set. That's why C#/.NET is a Java rip-off.
Well, it doesn't matter what Mundie or anybody else opines: as long as everybody plays by the rules, the market will decide. Even Microsoft's use of unfair business practice and their massive investment in marketing, tying, bundling, and loss leaders has not killed open source. Imagine how much open source would catch on if it were allowed to compete on equal footing.
Here is my challenge to Mundie: play fair and let consumers actually choose. Here is another challenge to Mundie and Microsoft: stop talking about innovation and actually deliver; so far, no significant innovation has ever been delivered in Microsoft products.
I don't particularly like Apple's policies either. I don't trust them to "play nice" either: I think there is a good chance that they will try to create legal problems for open source projects they feel threatened by in the future. But, so what?
I think in the long run, Apple will figure out that it is not in their interest to keep modifications to open source software to themselves. If NeXT/Apple couldn't compete with open source software using proprietary software a few years ago, they won't be able to a few years from now either. And if they don't feed their changes back into the community, they'll just fall behind as they are trying to juggle ever more diverging code bases. That's why it probably doesn't matter much whether you use BSD or GPL in the long run.
Besides, even if Apple magically figures out how to track open source without feeding back into it, their adoption of standard open source APIs still helps the open source community by training programmers in APIs used by open source software and encouraging programmers that would otherwise only work on proprietary systems to contribute to open source. If we could get Microsoft to go as far as Apple has, we'd all be better off. Apple and Microsoft: please take advantage of us a bit more if you would.
Ummm, no, not really "FALSE". Yes, there are several Python "compilers" (I have used them), and they even run under Linux. However they don't do much for performance. For practical purposes, as far as I'm concerned, Python does not have native code compilers in the sense that CMU CommonLisp or Java do.
Re:tempest in a teapot
on
Cracking OSX
·
· Score: 2
How do you "break into" a machine that doesn't allow remote logins, e.g. any previous MacOS
You don't need remote logins to break into a machine. For example, many security problems are buffer overruns and allow you to execute some arbitrary machine code. You can use such security holes to disable access controls on the web server, to start up new servers, to share disks without access control, etc. The possibilities are endless, and the lack of process based security makes pre-MacOS X machines more vulnerable than UNIX boxes. If you really want something interactive, you can use those bugs to upload a short command line interpreter.
Conversely, well-run UNIX servers only run those services that they need to run, giving them the same protection as a stripped down pre-MacOS X machine.
But don't take it from me, take it from the W3C.
Which only goes to show that you shouldn't believe everything you read on the web. Think for yourself.
Sorry? Since when are XML, regexps, sockets, and graphics "common" feature in language specs? My copy of the C standard must be missing some headers....
Actually, you just misunderstood. I didn't mean that the language standard contain those libraries, but merely that there exist standard, widely available, portable implementations, written in terms of a smaller set of portable language constructs and library primitives. ANSI C, Java, and Scheme managed to do this, CommonLisp never did.
We have a standard, and implementations try as hard as they can to follow it.
While the ANSI CommonLisp standard is one of the larger standards around, it is amazingly deficient in nailing implementations down enough to let programmers write efficient, portable, robust code.
You seem to have caught a serious case of Java-itis: symptoms include conflating languages, libraries, and implementations, and believing that everything in the universe should be included in one of the three.
Guilty as charged: I want a simple language definition, low-cost implementations, interoperable multi-vendor implementations, reasonable performance, runtime safety, interactive development, and a large set of libraries. Java delivers the whole package, CommonLisp never did get it right. After 15 years of Lisp programming and waiting for vendors to get their act together, I, as many of my colleagues, switched to Java.
I don't think Lisp is a good prototyping environment anymore. The language is good, as is the compiler, but the libraries aren't. For prototyping, you spend way too much time reinventing the wheel.
While there were fewer choices when Graham started, today, I see little reason not to use either Python or Java for these kinds of prototypes. The convenience Graham got from closures can also be achieved with threads or nested classes (and Perl, Python, and some Java extensions support closures as well).
BTW, I don't think that Graham invented online store building. Several people seem to have come up with the concept and prototypes around the same time.
You must not have looked at CMU Common Lisp closely enough. It includes a binding to Motif, which for me works wonderfully with the Open Motif libraries.
A "binding to Motif" is not a full GUI toolkit, it's a kludgy workaround. Look at Java's Swing in comparison: full Postscript-like graphics model, entirely written in Java, and fully extensible in Java. Even as far as bindings go, Tkinter and Gtk+ bindings to Python beat CMU CommonLisp-to-Motif bindings any day in functionality, features, and ease of programming. Oh, and Java/Swing also supports multithreading.
The reason why people aren't interested in hiring Lisp people is simply due to a lack of education in Lisp. [...] Lisp is still fantastically useful but
people are afraid of it or don't know about it.
I know many ex-Lisp users, and it's not lack of education. It's lack of libraries, lack of evolution of the standard and language, lack of standardization, and high cost of commercial Lisp implementations that killed Lisp. It's also the availability of cheap and good alternatives like Python and Java.
It's a shame that Lisp is in shambles. But people stopped using it not because they didn't know any better or because they couldn't get over the syntax (Perl made it, after all) but because other tools got better and Lisp failed to keep up and address real-world needs of Windows and UNIX users.
I don't have much hope for Lisp anymore. There is a marginal chance that it will attract more users in the open source community if CMU CommonLisp finally gets released with multithreading, the language is brought into the 00's, and the standard libraries get improved and documented to include regular expressions, XML, sockets, HTML parsing, Internet protocols, graphics, binary I/O, and other common features. Then, perhaps, the fact that it runs about 10x faster than common scripting languages might start attracting users again.
journalling file systems are pretty useless
on
XFS 1.0 is Released
·
· Score: 3
As far as I'm concerned, journalling file systems are pretty useless. They only protect against a limited set of failures, so you still need backups or RAID for important data. They do save the overhead of running fsck at startup, but you spend more time in aggregate overhead than the occasional fsck. And journalling file systems generally only journal file system structure, not content, which means that partially written files may contain garbled content. Some file systems that claim they are journalling (NTFS, for example) don't even guarantee that operations are carried out (and journalled) in order, so they make essentially no meaningful guarantees compared to a non-journalling file system other than an unproven belief that they may be more robust.
In addition to the overhead, you also have to deal with the risks to your data from the fact that both the file system code itself is more complex and that utility programs and administrative tools may do the wrong thing with journalling file systems.
Altogether, I think you are better off with a RAID and a UPS; unless you have some serious failure, that will pretty much avoid the need for running fsck. If you have really critical needs, you will want a hot backup system that you can switch to if your primary system goes down anyway; that takes care of a lot of other problems and also lets you spend however much time you need on fsck.
(As an aside, fast reboots can't have been a driving factor for JFS on AIX: while JFS may have spared people the time for an fsck on reboot, many AIX server machines spent minutes or hours (!) scanning their SCSI buses on each reboot. I think many people who use journalling file systems don't do it because they need it but because it sounds "safer".)
Lisp is a nice, powerful programming language. But while 20 years ago, Lisp and Smalltalk were "it" when it came to high-powered dynamic languages, today, you have an embarrassment of riches.
I think that for practical purposes, something like Python is very close to CommonLisp. The major differences are lack of macros in Python (not necessarily a bad thing), a less complex object system (probably a good thing, too), and lack of compilation to native code for Python source code (but you don't get that much of a speedup). And Python actually has a better standard library, better built-in datatypes, better OS integration, and cleaner semantics. Jython with Java for compute intensive stuff actually does better than most CommonLisp compilers.
Yes, it is silly and wasteful that languages like Python, Perl, Tcl, etc. essentially reinvented Lisp and Smalltalk (Java made some sort of unholy but very functional compromise between Lisp and C++). But they did, and you might as well use them. None of those more recent languages have made the transition to a natively compiled environments like Lisp did, but on fast modern hardware, that matters less and less, and sooner or later they probably will.
Machines get broken into not because they are "UNIX-like" or because they are "Windows-like" but because their network services have bugs. Most of the time, those are bugs in server code, not in the kernel.
Whether MacOS X users choose to take advantage of the vast library of server code that they now, finally, have access to is for them to decide. If they don't, their machines will remain pretty much as secure as with earlier versions of MacOS.
Of course, given the strong support for Java that MacOS X supposedly has and the widespread availability of Java-based servers (web, ftp, smb, etc.), they may also choose to go with mostly Java-based services. Those aren't necessarily perfect either, but they avoid known UNIX bugs and they are intrinsically more robust against common problems like buffer overruns.
Altogether, I would expect the MacOS X security situation to be pretty good. What the article mostly shows is that there isn't much technical understanding at BusinessWeek. Reasoning that goes like "MacOS X is UNIX-like, therefore MacOS X will be susceptible to UNIX-like security problems" is simply not very informed.
The whole premise of that software is wrong. If you don't have control over the physical terminal equipment, then people can record the data using a variety of recording techniques no matter what you do with the software (screen capture, digital cameras, etc.). If you do have control over the physical terminal equipment, you don't need to bother with oddball plug-ins at all, you simply don't put any removable storage on the machine and limit its Internet access.
At best, plug-ins like that are an expression of policy and preference, not a security device, and only keep casual users from accidentally storing data. Trouble is that they are being marketed for security purposes: the article talks about proprietary design documents, the FBI, and sensitive corporate information. In my opinion, for that, they are completely unsuitable, and anybody who buys them for that is a fool.
Last but not least, the performance of the compiled code is excellent, better than C++ and close to C.
OCAML is a great language with a decent implementation, but this simply isn't true. Maybe for some applications OCAML pulls equal, but try writing numerical or semi-numerical code in it.
The only reason I can think of for doing so is to implicitly provide MS with a gratuitous revenue stream from an effective double purchase of an OS: the preinstalled one and the one for which we have the site license.
As Microsoft's letter points out: they don't offer site licenses for Windows in the sense you think you have. Their "site license" is for Windows upgrades; you have to buy the computer with an OEM or retail license for Windows if you want to take advantage of your site license for upgrades. So, in that regard, they are justified in being concerned about "unlicensed copies" of Windows.
Of course, this is a self-created situation: if they did offer site licenses the way you and I understand them, this issue would go away. And, in fact, the current situation is just fine with them: they get money from the OEMs, they get money from site licenses, they get to push Windows onto every shipping machine, and they have contracts with everybody and can use those contracts for business intelligence on who is jumping ship and for hassling people who do.
We have a Microsoft site license and we order some PCs without Windows preinstalled--to run Linux on them.
The complaint people have with the letter is Microsoft's limited and self-centered mindset, as if the only use of a PC was to run Windows on it:
Therefore,
we strongly advise that each new PC that will be
running a Microsoft Operating System be pre-
installed with an OEM version of the Operating
System. The alternative would be to purchase
retail product, at greater cost and
inconvenience to your customers.
Whether Microsoft does this kind of nonsense with Machiavellian deliberation or out of clueless incompetence doesn't really matter; the effect is the same: they make money for selling licenses that customers don't need or want. How are competitors to Microsoft outcompete Microsoft if every PC purchase automatically results in a license payment to Microsoft?
What difference does it make whether they go after small or large customers? Large customers may want to migrate to Linux as well.
For the last several computers I have ordered at work, I would have liked not to pay for a Windows license I don't need, but the manufacturer could never figure out how to credit us for it. Now, I have to worry about having Microsoft's minions hassle our IT department if I request a PC without Windows?
(BTW, what's wrong with moderation lately? I may not agree with the opinion of the posting I'm responding to either, but that doesn't make it a "troll". Moderators seem to confuse having a different opinion with trolling and flaming.)
Since nobody really fully understands the mechanisms by which RSI happens, the best you can do is to use whatever works for you.
However, I would distrust the ergonomic judgement of a company that puts a touchpad on a system designed for RSI sufferers; I think touchpads have many problems. It seems to me that a large mouse with foot pedals for buttons would be preferable: you'd get a regular break from typing (as you move your hand to the mouse), and you give your fingers a break (as you can use your arm to move the mouse and your feet for clicking).
But if you suffer from RSI and have tried a variety of pointing devices, it would be interesting to hear your experience. It might help others avoid similar problems.
I like Linux just as much as the next guy (and use it for running my site) but Windows 2000 is the best desktop platform I've yet seen. Office is the best office suite on the market as far as I'm conerned.
That's kind of like the proverbial guy who killed his parents asking for mercy because he is an orphan. Really: Microsoft has pretty much killed all the competition and all the innovation. Nobody else has the marketshare or resources anymore to compete. Sadly, what Microsoft is delivering is still pityful compared to what was possible two decades ago.
DirectX, COM, and other technologies are well designed AFAIK (never coded using either however.) C# looks like it has potential. These are all opinions, YMMV.
Gack. COM and C# are Microsoft's poor copies of other people's ideas. DirectX is merely a set of random APIs thrown together for game development. No long range planning, no design, no insight.
I'm 19 years old.
Better, more modern software than what Microsoft has developed was available before you were born. For starters, take a look at Smalltalk.
I'm guessing that if some large Linux based ISP picked up the entire userbase of another (NT based, perhaps?) ISP it would be declared a "Victory for Linux" etc., etc.
It wouldn't be a "victory for Linux", but it would probably be a blessing for the users. Microsoft has shown in the past that they are willing to deny access to anybody who isn't willing to buy their software at their inflated prices.
You see, the situation is simply not symmetric: Microsoft software is written with profit in mind, and that involves getting users entangled as much as possible in a web of dependencies and proprietary standards. Linux software is written by users and for users, and people in the Linux world have neither the means nor much of an interest to tie you to anything.
Metro Link, the keeper of the X Windows system flame
Is this hyperbole, or is MetroLink responsible in some basic way for XFree86 and X.org?
My own experience with MetroLink hasn't been so good: a few years ago, I ordered a copy of their "accelerated" X server, but it arrived without acceleration support, and they never delivered the promised update.
On February 7, 37 leading US economists signed a joint letter asking the federal communications commission (FCC) to allow broadcasters to lease spectrum they currently license from the government in secondary markets. [...] The study argued that government control of the radio frequencies led to inefficiencies
Of course it does: that's the whole point. Without government regulation, the market wouldn't tolerate those inefficiencies, and it would fail to deliver social and policy goals that we hold important as a society.
Delivering trinkets at the lowest possible price is ultimately not what modern economics and social policy should be about. We have an abundance of resources (food, information, etc.), and we now have the luxury of looking beyond the old imperatives of scarcity and optimal efficiency. Yet, mainstream economists are still behaving as if we didn't have enough bread or bandwidth.
My view of mainstream US economics is pretty dim. I don't view it as a science but as a morass of simplistic mathematical models, academic pressure, opportunism, corporate influence taking, lack of deep thinking, and political ambition. To be sure, there is some good, solid work in economics, some of it even recognized more widely, but it doesn't seem to be listened to by policy makers. Perhaps that is because it doesn't give any simple answers and instead forces policy makers to actually set their own goals that go beyond bigger SUVs and bigger burgers.
The mechanism for stopping this kind of economic insanity is simple: politics. Unless there is scarcity in something as basic as food or housing, politics trumps economics. We can decide to use tax dollars to finance public television, we can decide to keep open radio frequencies for micropowered radio and amateur radio, we can decide to keep open spectrum for telecommunications technologies that may look like a long-shot in the market but seem promising 10-20 years down the road. So, go out and vote against politicians that think the whole world is to be measured in dollars and cents. And punch those cards all the way through next time.
Slashdot Mirror
Of course it was. But Sun competed with Microsoft by doing something entirely different from anything Microsoft had done: a safe, cross-platform language and library based on C++ syntax and "Smalltalkish" semantics. Microsoft's response to Java/JVM is to make an almost identical, but incompatible, product.
It was designed to do one thing -- make money for Sun.
Actually, it wasn't designed for that at all. It was an accidental success: the industry was ready for a simple OOL, and the promise of applets pushed it over the edge. Once Sun saw Java catch on, they heavily promoted it.
If Microsoft were "proprietary" in the same way with their systems as Sun is with Java, I'd be quite happy. In any case, my point was not about whether Java was proprietary or not, or even whether it is a good language, but about who was "ripping off" who. The fact remains that Java was a new language and system in the marketplace when Sun created it, while C#/.NET is basically a carbon copy.
Obviously, you hang out with the wrong crowd.
C#/.NET, on the other hand, was a direct business response by Microsoft to Java. Microsoft saw that Java was doing well and couldn't bear to let Sun have the market. So, they came out with their own system that's incompatible but has an almost identical feature set. That's why C#/.NET is a Java rip-off.
Here is my challenge to Mundie: play fair and let consumers actually choose. Here is another challenge to Mundie and Microsoft: stop talking about innovation and actually deliver; so far, no significant innovation has ever been delivered in Microsoft products.
I think in the long run, Apple will figure out that it is not in their interest to keep modifications to open source software to themselves. If NeXT/Apple couldn't compete with open source software using proprietary software a few years ago, they won't be able to a few years from now either. And if they don't feed their changes back into the community, they'll just fall behind as they are trying to juggle ever more diverging code bases. That's why it probably doesn't matter much whether you use BSD or GPL in the long run.
Besides, even if Apple magically figures out how to track open source without feeding back into it, their adoption of standard open source APIs still helps the open source community by training programmers in APIs used by open source software and encouraging programmers that would otherwise only work on proprietary systems to contribute to open source. If we could get Microsoft to go as far as Apple has, we'd all be better off. Apple and Microsoft: please take advantage of us a bit more if you would.
Ummm, no, not really "FALSE". Yes, there are several Python "compilers" (I have used them), and they even run under Linux. However they don't do much for performance. For practical purposes, as far as I'm concerned, Python does not have native code compilers in the sense that CMU CommonLisp or Java do.
You don't need remote logins to break into a machine. For example, many security problems are buffer overruns and allow you to execute some arbitrary machine code. You can use such security holes to disable access controls on the web server, to start up new servers, to share disks without access control, etc. The possibilities are endless, and the lack of process based security makes pre-MacOS X machines more vulnerable than UNIX boxes. If you really want something interactive, you can use those bugs to upload a short command line interpreter.
Conversely, well-run UNIX servers only run those services that they need to run, giving them the same protection as a stripped down pre-MacOS X machine.
But don't take it from me, take it from the W3C.
Which only goes to show that you shouldn't believe everything you read on the web. Think for yourself.
Actually, you just misunderstood. I didn't mean that the language standard contain those libraries, but merely that there exist standard, widely available, portable implementations, written in terms of a smaller set of portable language constructs and library primitives. ANSI C, Java, and Scheme managed to do this, CommonLisp never did.
We have a standard, and implementations try as hard as they can to follow it.
While the ANSI CommonLisp standard is one of the larger standards around, it is amazingly deficient in nailing implementations down enough to let programmers write efficient, portable, robust code.
You seem to have caught a serious case of Java-itis: symptoms include conflating languages, libraries, and implementations, and believing that everything in the universe should be included in one of the three.
Guilty as charged: I want a simple language definition, low-cost implementations, interoperable multi-vendor implementations, reasonable performance, runtime safety, interactive development, and a large set of libraries. Java delivers the whole package, CommonLisp never did get it right. After 15 years of Lisp programming and waiting for vendors to get their act together, I, as many of my colleagues, switched to Java.
While there were fewer choices when Graham started, today, I see little reason not to use either Python or Java for these kinds of prototypes. The convenience Graham got from closures can also be achieved with threads or nested classes (and Perl, Python, and some Java extensions support closures as well).
BTW, I don't think that Graham invented online store building. Several people seem to have come up with the concept and prototypes around the same time.
A "binding to Motif" is not a full GUI toolkit, it's a kludgy workaround. Look at Java's Swing in comparison: full Postscript-like graphics model, entirely written in Java, and fully extensible in Java. Even as far as bindings go, Tkinter and Gtk+ bindings to Python beat CMU CommonLisp-to-Motif bindings any day in functionality, features, and ease of programming. Oh, and Java/Swing also supports multithreading.
The reason why people aren't interested in hiring Lisp people is simply due to a lack of education in Lisp. [...] Lisp is still fantastically useful but people are afraid of it or don't know about it.
I know many ex-Lisp users, and it's not lack of education. It's lack of libraries, lack of evolution of the standard and language, lack of standardization, and high cost of commercial Lisp implementations that killed Lisp. It's also the availability of cheap and good alternatives like Python and Java.
It's a shame that Lisp is in shambles. But people stopped using it not because they didn't know any better or because they couldn't get over the syntax (Perl made it, after all) but because other tools got better and Lisp failed to keep up and address real-world needs of Windows and UNIX users.
I don't have much hope for Lisp anymore. There is a marginal chance that it will attract more users in the open source community if CMU CommonLisp finally gets released with multithreading, the language is brought into the 00's, and the standard libraries get improved and documented to include regular expressions, XML, sockets, HTML parsing, Internet protocols, graphics, binary I/O, and other common features. Then, perhaps, the fact that it runs about 10x faster than common scripting languages might start attracting users again.
In addition to the overhead, you also have to deal with the risks to your data from the fact that both the file system code itself is more complex and that utility programs and administrative tools may do the wrong thing with journalling file systems.
Altogether, I think you are better off with a RAID and a UPS; unless you have some serious failure, that will pretty much avoid the need for running fsck. If you have really critical needs, you will want a hot backup system that you can switch to if your primary system goes down anyway; that takes care of a lot of other problems and also lets you spend however much time you need on fsck.
(As an aside, fast reboots can't have been a driving factor for JFS on AIX: while JFS may have spared people the time for an fsck on reboot, many AIX server machines spent minutes or hours (!) scanning their SCSI buses on each reboot. I think many people who use journalling file systems don't do it because they need it but because it sounds "safer".)
I think that for practical purposes, something like Python is very close to CommonLisp. The major differences are lack of macros in Python (not necessarily a bad thing), a less complex object system (probably a good thing, too), and lack of compilation to native code for Python source code (but you don't get that much of a speedup). And Python actually has a better standard library, better built-in datatypes, better OS integration, and cleaner semantics. Jython with Java for compute intensive stuff actually does better than most CommonLisp compilers.
Yes, it is silly and wasteful that languages like Python, Perl, Tcl, etc. essentially reinvented Lisp and Smalltalk (Java made some sort of unholy but very functional compromise between Lisp and C++). But they did, and you might as well use them. None of those more recent languages have made the transition to a natively compiled environments like Lisp did, but on fast modern hardware, that matters less and less, and sooner or later they probably will.
Whether MacOS X users choose to take advantage of the vast library of server code that they now, finally, have access to is for them to decide. If they don't, their machines will remain pretty much as secure as with earlier versions of MacOS.
Of course, given the strong support for Java that MacOS X supposedly has and the widespread availability of Java-based servers (web, ftp, smb, etc.), they may also choose to go with mostly Java-based services. Those aren't necessarily perfect either, but they avoid known UNIX bugs and they are intrinsically more robust against common problems like buffer overruns.
Altogether, I would expect the MacOS X security situation to be pretty good. What the article mostly shows is that there isn't much technical understanding at BusinessWeek. Reasoning that goes like "MacOS X is UNIX-like, therefore MacOS X will be susceptible to UNIX-like security problems" is simply not very informed.
At best, plug-ins like that are an expression of policy and preference, not a security device, and only keep casual users from accidentally storing data. Trouble is that they are being marketed for security purposes: the article talks about proprietary design documents, the FBI, and sensitive corporate information. In my opinion, for that, they are completely unsuitable, and anybody who buys them for that is a fool.
OCAML is a great language with a decent implementation, but this simply isn't true. Maybe for some applications OCAML pulls equal, but try writing numerical or semi-numerical code in it.
As Microsoft's letter points out: they don't offer site licenses for Windows in the sense you think you have. Their "site license" is for Windows upgrades; you have to buy the computer with an OEM or retail license for Windows if you want to take advantage of your site license for upgrades. So, in that regard, they are justified in being concerned about "unlicensed copies" of Windows.
Of course, this is a self-created situation: if they did offer site licenses the way you and I understand them, this issue would go away. And, in fact, the current situation is just fine with them: they get money from the OEMs, they get money from site licenses, they get to push Windows onto every shipping machine, and they have contracts with everybody and can use those contracts for business intelligence on who is jumping ship and for hassling people who do.
The complaint people have with the letter is Microsoft's limited and self-centered mindset, as if the only use of a PC was to run Windows on it:
Whether Microsoft does this kind of nonsense with Machiavellian deliberation or out of clueless incompetence doesn't really matter; the effect is the same: they make money for selling licenses that customers don't need or want. How are competitors to Microsoft outcompete Microsoft if every PC purchase automatically results in a license payment to Microsoft?
For the last several computers I have ordered at work, I would have liked not to pay for a Windows license I don't need, but the manufacturer could never figure out how to credit us for it. Now, I have to worry about having Microsoft's minions hassle our IT department if I request a PC without Windows?
(BTW, what's wrong with moderation lately? I may not agree with the opinion of the posting I'm responding to either, but that doesn't make it a "troll". Moderators seem to confuse having a different opinion with trolling and flaming.)
However, I would distrust the ergonomic judgement of a company that puts a touchpad on a system designed for RSI sufferers; I think touchpads have many problems. It seems to me that a large mouse with foot pedals for buttons would be preferable: you'd get a regular break from typing (as you move your hand to the mouse), and you give your fingers a break (as you can use your arm to move the mouse and your feet for clicking).
But if you suffer from RSI and have tried a variety of pointing devices, it would be interesting to hear your experience. It might help others avoid similar problems.
That's kind of like the proverbial guy who killed his parents asking for mercy because he is an orphan. Really: Microsoft has pretty much killed all the competition and all the innovation. Nobody else has the marketshare or resources anymore to compete. Sadly, what Microsoft is delivering is still pityful compared to what was possible two decades ago.
DirectX, COM, and other technologies are well designed AFAIK (never coded using either however.) C# looks like it has potential. These are all opinions, YMMV.
Gack. COM and C# are Microsoft's poor copies of other people's ideas. DirectX is merely a set of random APIs thrown together for game development. No long range planning, no design, no insight.
I'm 19 years old.
Better, more modern software than what Microsoft has developed was available before you were born. For starters, take a look at Smalltalk.
It wouldn't be a "victory for Linux", but it would probably be a blessing for the users. Microsoft has shown in the past that they are willing to deny access to anybody who isn't willing to buy their software at their inflated prices.
You see, the situation is simply not symmetric: Microsoft software is written with profit in mind, and that involves getting users entangled as much as possible in a web of dependencies and proprietary standards. Linux software is written by users and for users, and people in the Linux world have neither the means nor much of an interest to tie you to anything.
Is this hyperbole, or is MetroLink responsible in some basic way for XFree86 and X.org?
My own experience with MetroLink hasn't been so good: a few years ago, I ordered a copy of their "accelerated" X server, but it arrived without acceleration support, and they never delivered the promised update.
Of course it does: that's the whole point. Without government regulation, the market wouldn't tolerate those inefficiencies, and it would fail to deliver social and policy goals that we hold important as a society.
Delivering trinkets at the lowest possible price is ultimately not what modern economics and social policy should be about. We have an abundance of resources (food, information, etc.), and we now have the luxury of looking beyond the old imperatives of scarcity and optimal efficiency. Yet, mainstream economists are still behaving as if we didn't have enough bread or bandwidth.
My view of mainstream US economics is pretty dim. I don't view it as a science but as a morass of simplistic mathematical models, academic pressure, opportunism, corporate influence taking, lack of deep thinking, and political ambition. To be sure, there is some good, solid work in economics, some of it even recognized more widely, but it doesn't seem to be listened to by policy makers. Perhaps that is because it doesn't give any simple answers and instead forces policy makers to actually set their own goals that go beyond bigger SUVs and bigger burgers.
The mechanism for stopping this kind of economic insanity is simple: politics. Unless there is scarcity in something as basic as food or housing, politics trumps economics. We can decide to use tax dollars to finance public television, we can decide to keep open radio frequencies for micropowered radio and amateur radio, we can decide to keep open spectrum for telecommunications technologies that may look like a long-shot in the market but seem promising 10-20 years down the road. So, go out and vote against politicians that think the whole world is to be measured in dollars and cents. And punch those cards all the way through next time.
that they have to tell you? Is there some law that I'm not aware of?