Unix has similar constructs. They're called pipes. You just send the output of one program as the input for another program, and voila. The best part is, you don't have to click and drag to select text, then click Services->Terminal->evaluate. It happens automatically whenever you use a shell interactively or run a shell script. It's quite brilliant really, and highly underrated.
There are some things that the pipe system does not handle well right now because "the baby was thrown out with the bathwater", so to speak. The idea of piping from program to program fell out of favor because shells have been about the only place where the idea has been implemented. When system designers realize that they should have used this piping idea from the beginning, then some fairly sophisticated new GUI architectures will likely emerge. Pasteboards, Nextstep Services, OLE and COM, and OpenDoc have all been attempts to restore this idea, and most of them failed because the essential simplicity and elegance of pipes was not recaptured.
Let your mind wander around among the opportunities for visually representing a piping architecture and see what interesting ideas come to mind.
Some of Raskin's concerns are simplicity, focus, modality and uniformity. The Human Interface describes all of this in mindnumbing detail. They are valid issues that should be incorporated into interface designs, but usually are not. I think Raskin's contention in the article is that OSX did not pay as much attention to his current ideals as he would have liked. But his ideals really don't have much to do with the OS per se.
Naturally, a computer needs an OS to manage it's resources and process. And any programmer that writes code will undoubted need the services of an OS (loaders, drivers, memory managers, etc.) But there are some things about modern OS architecture that are not obvious to non-systems prople. Things like shells (CLI & GUI), file browsers and process/task managers attempt to put a good face on necessarily complicated concepts. These things just have to be there for the computer and the programmer. Users on the other hand, should not be forced to understand the intricacies of something like the common hierarchical file system. They should feel confident that they can keep some data in the computer without the fear that it may "disappear" or (more likely) be misplaced somewhere in the tree.
For most application developers, interface design begins at the frame of the main window. It's not so bad once you get into the app, but getting from the login screen to comfortably settled into a primary application like a word processor or point-of-sale system is usually a complicated affair in the current scheme. Login, then land in a "shell", then "start" the "program", then "load" the "file" you want to work with. It all makes sense to someone who knows that all this means to the computer. But it sure was hard to explain it to my grandmother. My personal anti-favorite is Microsoft's MDI scheme, spawned by the Office team, but abandoned by same for Outlook. You can't get *anyone* but a computer geek to remember which X to click to close one document. At least 50% of the time they close the whole app! But I digress...
Almost every popular PC game developed in the last 5 years avoids most of this. The game starts by taking over the whole screen and introduces you to the goal. Then it introduces you to it's control dialect. Finally it shows you how to work towards goal using that dialect. The whole idea behind "making user-interfaces consistent" is that programs will naturally become "easier to learn and use." This inconsistency with other apps should make the game harder to understand, but it doesn't. It's easier, and preschoolers, senior citizens and everyone in between can get handle on how to operate a game in just a few minutes. The reason is that game designers use the same principles that Raskin and Cooper espouse.
Games generally have a mark/resume function; that is, you can "save your game" and "reload" it when you want to pick up that game where you left off. Of course, most game developers use a file to store the state of the game where it is being marked for later resumption. But the good interfaces for mark/resume do not inflict the full complexity of the file system on the gamer. You mark your place and that marker goes into a list. You can request to see the list and resume the game from any of the markers. This is such a good approach because it's about as much complexity as the non-system savvy user can reliably handle. It's also a good approach because it puts most of the burden on computer to categorized persistent data into directories and files, store them in the hierarchy, and track their location for future reference. I think the more of this kind of design that we see, the easier computers will be perceived to be.
Naturally, none of this has anything to do with the OS itself. The perception that the file browser, application dock/task bar and other screen accoutrements are somehow inextricably linked to the OS is what leads interface-heads like Raskin believe that the OS is, by association, equally flawed. There's nothing backwards about Unix, but there's plenty that's wrong with Windows Explorer, Workspace Manager (or whatever it's called in OSX), Finder, and various X-based window managers. Each one is based on the same concept: "here's your files (hierarchically arranged for your inconvenience), some of the files can make the computer do something useful. good luck. and oh yeah, click Start." If a game did this, you'd throw it in the garbage. Hard.
So what does all this lead to? Special, easy-to-use consumer shell-and-apps-in-one like Microsoft Bob or General Magic's MagicCap? Or customized game-like shells with 3D graphics and startup training sessions? Or how about dedicated multifunction applications with super-extensibility like GNU Emacs? Probably not. I think it's something that has yet to appear, like the Unix OS in the 60s, or the spreadsheet in the 70s, or the suit that makes Bill Gates look good. It just hasn't been invented yet. So rest assured that Unix, like other good ideas: transistors, Von Neumann architecture, CRTs, and FPS, will continue to exist and thrive. Then, imagine the kind of hell it would raise at Microsoft if whole new paradigms for overall system usuability start bubbling up out of the Open Source community faster than they can keep track of them. Nautilus is cool but it isn't the answer. It's only incrementally better than Explorer in Windows 2000. The source is open, you're free to change it. The metaphor is open, too. Change it, evolve it, improve it. If sucks, it will die. If it's good, it will thrive. If it's really good, it will change everything.
I'd say that *not* developing this way is extreme. It's easy to categorize as extremists the developers who want to design themselves silly before they code anything. Those guys squirm pretty hard when they're getting skewered in a meeting with senior managers who care about the ends and not the means. They sound like idiots when they have nothing to hide behind but an idealized vision of how the project "should" have gone. That's pretty stressful. I would gamble that more milestone dates are missed because of "analysis paralysis" than any other problem - paralysis caused by extreme devotion to some method of design or construction. Getting fired for not delivering is definitely a wrong turn for any developer's career path. Those that understand this deliver early and often. They balance the means of development with the ends required by the business (or users). This is true for open source and internal corporate projects alike.
XP prescribes some interesting techniques, and some seem more useful than others. I think the author recommends that you scale into XP gradually, try the methods incrementally, keep the ones that work for you, and drop the ones that don't.
Like common sense, it seems old and obvious, but it isn't very common. I guess it's the rarity of it that makes it seem extreme.
Take the pride of a man's effort away from him and give it a committee that little or no emotional or economic investment in it? Can anyone name another software project where this was done and the project improved?
There are no fields in Project 2000 for "love", "devotion", "pride", or "repute". On paper it might seem that more hands will make lighter work, but development by committee will surely make lighter work of causing Linux to fail.
Read "Mythical Man Month" to understand why more programmers to not necessary make a project go faster. Read "Cathedral and Bazaar" to understand the motivational value of pride, commitment, and repute in the Open Source community.
if( rebuild.benefit > rebuild.cost )
{
rebuild.begin();
} else
{
legacy.patch();
}
porting this to your favorite language is left as an exercise to the troller.
Nextstep was based on the Mach kernel and BSD4.3 from it's initial release in 1989. The swapfile problem I mentioned was endemic to their particular implementation of Mach. Unless Apple's engineers picked up pager sources from Mach 3 or implemented a new pager themselves, OS/X will still have this problem.
Next gambled everything on their OS, but they could not fix this problem. If it wasn't important enough to fix in Nextstep, it couldn't possibly be important enough to fix now. Apple may have opened the Darwin source, but Jobs clearly does not have the same dedication to overall system quality and performance that Linux and FreeBSD users have grown accustomed to. It's all about selling image at Apple - it's about the money.
I used to use Nextstep - the predecessor to OS/X. Nextstep used a swapfile scheme that prevented any swapped pages from being removed from the file if another page had been allocated in the file after it. In other words, the only way to shrink the swapfile was to deallocate pages in exactly the reverse order of their allocation - a nearly impossible task. When probed about the problem, Avie Tavanian (CTO of Apple, then the chief OS designer for Next) said that it would be exceedingly difficult to alter the swapfile algorithm. Perhaps it's different in OS/X, but his statement gives me good reason to doubt it.
What was the big deal about a big swapfile? The bigger it got, the slower the system became. I used to reboot twice a day to keep my system from bogging down. I had a 64Mb system (the most you could get in a typical workstation back then), and I ran emacs, the compiler/linker/debugger suite (modified from gcc & gdb) and my programs (they topped out around 10Mb). I was SO HAPPY to switch to NT because it meant that I could reboot only about once a week instead of twice a day!
I'm looking forward to moving back to *nix someday when the tools finally match those on Windows (emacs and cygwin ports have made NT bearable). But I'll switch back to Win95 before I got back to Nextstep or any current incarnation that behaves the same way.
In the most long-winded way imaginable, the author has said "OOP doesn't live up to its hype" and "OOP wasn't a silver bullet that quickly and easily improved the quality of his work."
Duh.
Before the web came along, OOP was the most hyped thing in technology. A lot of people made their livings selling snake oil in the form of books, seminars, methodologies, training courses, tools, libraries, etc. These leaches are just out there. Always have been, always will be. And they aren't just in tech. Pick up an investment rag and look at the ads. They're ridiculous. They're the culmination of almost a century of hucksterism.
Professionals have the responsibility to see through this and find the kernel of useful genius that made the topic so cool in the beginning. Believing the hype always leads to bitterness and regret. Creating the hype leads to a painful demise (I hope).
OOP tools are a big improvement. I like a lot of them, but none substitute for good techniques. How something (anything) is constructed has more significance in its final value than what material or which tool is used (except for things made from rare metals or minerals). I spent some time around IBM as a kid, and the acronym seen everwhere was TINSTAAFL - There is no such thing as a free lunch.
Don't believe the hype, and don't waste time being pissed off if you did. That's just more time wasted. You're young, your smart, go build something!
It's ZERO-click ordering!
But seriously, Kamen's VC says "he had been sure that he wouldn't see the development of anything in his lifetime as important as the World Wide Web -- until he saw IT". Now at first I thought, "Come on, no one GETS a thing like web in just one sales meeting". But later while I was making chile I thought "Hey Jobs understood the PARC research right away. He understood the Pixar technology right away. He even recognized the genius of the Apple II while it was still a board full of handwraps." So then I thought "Ok, I'll forget that he's paying Bezos his Time-Man-Of-The-Year tax. I'll forget that iCubes crack (pfpfpf ha). I'll even forget how insanely great Nexts were supposed to be, and I'll step into the reality distortion field one last time and I'll believe it when Jobs says something is really cool."
And then I thought, "Ok that's enough crack for tonight. Time to finish the chile."
BTW, my burgers taste better that McDonalds anyway!;-)
Despite your clear ability to make a better hamburger than McDonalds, the labor and equipment costs involved in producing millions of these prevents you as an individual from becoming a competitor. Employers realize there are no such production costs associated with IP and that a single individual can become a dangerous competitor. Developers need a usable defense against corporate encroachment into their personal mental space. In this case, the distinction between hamburger design and hamburger production is a significant one.
I'm having a nightmare where the Linux community spends all its time in-fighting while Microsoft keeps sinking their proprietary claws into every piece of exposed user flesh they can find. I guess I'm dreaming about what happened to Unix in the early 90s when major vendors argued over irrelevant minutia while Microsoft wrote NT. Pinch me and wake me up so I don't have to see this happen all over again!
I can see the value in reducing a child's exposure to violence. What concerns me is the permissive attitude towards "idealized violence" where the realistic reactions are quickly swept off the edge of the screen (i.e. spurting arteries, shattered bones, immense pain and suffering, wrecked lives, inconsolable families, pointless death). Children who watch sterilized attacks on disposable victims learn that violence is okay because the ramifications are insignficant. If someone gets shot in a movie, I want the director to show him drown in his own blood. Naturally, I don't want my children to see this at all until they're old enough to deal with it. But I definitely don't want them to watch PG-rated death where the consequences are quickly out-of-sight and out-of-mind.
I know many people who were staunch supporters of Microsoft in this issue. Believing in a free market, they felt that Microsoft had simply outperformed the competition and deserved the rewards for their efforts. The also felt that the case brought against them was a last-ditch effort by fussy childish millionaires to compete with Gates in the only arena they could.
But as this case has proceeded, much attention has been drawn to Microsoft's lame whining arguments and brutish tactics. These former supporters of Microsoft have questioned their beliefs and envisioned the long-term effects of an entity like Microsoft. They have taken the time to digest some the Open Source litany. Some of them turned completely against Microsoft, fdisked away Windows, and dove head first into Linux et al. Others still use grudgingly still use Windows because they now despise Microsoft but they still see the Windows/Office juggernaut as superior tech for them.
The longer this trial drags on, the more exposure people in general will get to the ugly side of Microsoft. The longer this trial drags on, the more time Open Source developers will have to create better answers to the question, "if not Microsoft, then what?".
I've read a number of posts here criticizing the dim state of affairs at the Patent Office. What I haven't seen from this august body of patent law experts (snicker, snort) is anything resembling a workable alternative. Sure, the patent process needs to be overhauled! But do you really want to leave it up to the members of Congress to come up with a better solution? The same Congress that brought you UCITA and other fine pieces of legislation? I didn't think so.
Law is like the Open Source code for democratic society. You've found a bug, and you have the source. Let's see if you can hack a fix for it.
Crazy stories follow Steve Jobs everywhere he goes. But the real story could be much simpler. It's possible that Radeon was not working properly or could not be manufactured in volume in time for the Cube shipments. Jobs was taken to the woodshed by press and customers for the NeXTDimension debacle. I doubt he will *ever again* embarrass himself by announcing with houpla something that can't be delivered.
An OS/browser that traverses ad links in literally the blink of an eye would cause more defections to Linux than any feature that could be added to Linux. For all of their prowess, Microsoft can also be their own worst enemy. e P.S. I don't even like point-to-focus
Slashdot Mirror
There are some things that the pipe system does not handle well right now because "the baby was thrown out with the bathwater", so to speak. The idea of piping from program to program fell out of favor because shells have been about the only place where the idea has been implemented. When system designers realize that they should have used this piping idea from the beginning, then some fairly sophisticated new GUI architectures will likely emerge. Pasteboards, Nextstep Services, OLE and COM, and OpenDoc have all been attempts to restore this idea, and most of them failed because the essential simplicity and elegance of pipes was not recaptured.
Let your mind wander around among the opportunities for visually representing a piping architecture and see what interesting ideas come to mind.
Naturally, a computer needs an OS to manage it's resources and process. And any programmer that writes code will undoubted need the services of an OS (loaders, drivers, memory managers, etc.) But there are some things about modern OS architecture that are not obvious to non-systems prople. Things like shells (CLI & GUI), file browsers and process/task managers attempt to put a good face on necessarily complicated concepts. These things just have to be there for the computer and the programmer. Users on the other hand, should not be forced to understand the intricacies of something like the common hierarchical file system. They should feel confident that they can keep some data in the computer without the fear that it may "disappear" or (more likely) be misplaced somewhere in the tree.
There are dozens of examples like this where the current overarching conceptualization a computer's user interface falls flat on it's face. I recommend Alan Cooper's About Face for an entertaining description of many of them. He may be "the father of Visual Basic", but he doesn't pull any punches when it comes to beating up Windows and Office for their crufty interface work.
For most application developers, interface design begins at the frame of the main window. It's not so bad once you get into the app, but getting from the login screen to comfortably settled into a primary application like a word processor or point-of-sale system is usually a complicated affair in the current scheme. Login, then land in a "shell", then "start" the "program", then "load" the "file" you want to work with. It all makes sense to someone who knows that all this means to the computer. But it sure was hard to explain it to my grandmother. My personal anti-favorite is Microsoft's MDI scheme, spawned by the Office team, but abandoned by same for Outlook. You can't get *anyone* but a computer geek to remember which X to click to close one document. At least 50% of the time they close the whole app! But I digress...
Almost every popular PC game developed in the last 5 years avoids most of this. The game starts by taking over the whole screen and introduces you to the goal. Then it introduces you to it's control dialect. Finally it shows you how to work towards goal using that dialect. The whole idea behind "making user-interfaces consistent" is that programs will naturally become "easier to learn and use." This inconsistency with other apps should make the game harder to understand, but it doesn't. It's easier, and preschoolers, senior citizens and everyone in between can get handle on how to operate a game in just a few minutes. The reason is that game designers use the same principles that Raskin and Cooper espouse.
Games generally have a mark/resume function; that is, you can "save your game" and "reload" it when you want to pick up that game where you left off. Of course, most game developers use a file to store the state of the game where it is being marked for later resumption. But the good interfaces for mark/resume do not inflict the full complexity of the file system on the gamer. You mark your place and that marker goes into a list. You can request to see the list and resume the game from any of the markers. This is such a good approach because it's about as much complexity as the non-system savvy user can reliably handle. It's also a good approach because it puts most of the burden on computer to categorized persistent data into directories and files, store them in the hierarchy, and track their location for future reference. I think the more of this kind of design that we see, the easier computers will be perceived to be.
Naturally, none of this has anything to do with the OS itself. The perception that the file browser, application dock/task bar and other screen accoutrements are somehow inextricably linked to the OS is what leads interface-heads like Raskin believe that the OS is, by association, equally flawed. There's nothing backwards about Unix, but there's plenty that's wrong with Windows Explorer, Workspace Manager (or whatever it's called in OSX), Finder, and various X-based window managers. Each one is based on the same concept: "here's your files (hierarchically arranged for your inconvenience), some of the files can make the computer do something useful. good luck. and oh yeah, click Start." If a game did this, you'd throw it in the garbage. Hard.
So what does all this lead to? Special, easy-to-use consumer shell-and-apps-in-one like Microsoft Bob or General Magic's MagicCap? Or customized game-like shells with 3D graphics and startup training sessions? Or how about dedicated multifunction applications with super-extensibility like GNU Emacs? Probably not. I think it's something that has yet to appear, like the Unix OS in the 60s, or the spreadsheet in the 70s, or the suit that makes Bill Gates look good. It just hasn't been invented yet. So rest assured that Unix, like other good ideas: transistors, Von Neumann architecture, CRTs, and FPS, will continue to exist and thrive. Then, imagine the kind of hell it would raise at Microsoft if whole new paradigms for overall system usuability start bubbling up out of the Open Source community faster than they can keep track of them. Nautilus is cool but it isn't the answer. It's only incrementally better than Explorer in Windows 2000. The source is open, you're free to change it. The metaphor is open, too. Change it, evolve it, improve it. If sucks, it will die. If it's good, it will thrive. If it's really good, it will change everything.
I'd say that *not* developing this way is extreme. It's easy to categorize as extremists the developers who want to design themselves silly before they code anything. Those guys squirm pretty hard when they're getting skewered in a meeting with senior managers who care about the ends and not the means. They sound like idiots when they have nothing to hide behind but an idealized vision of how the project "should" have gone. That's pretty stressful. I would gamble that more milestone dates are missed because of "analysis paralysis" than any other problem - paralysis caused by extreme devotion to some method of design or construction. Getting fired for not delivering is definitely a wrong turn for any developer's career path. Those that understand this deliver early and often. They balance the means of development with the ends required by the business (or users). This is true for open source and internal corporate projects alike.
XP prescribes some interesting techniques, and some seem more useful than others. I think the author recommends that you scale into XP gradually, try the methods incrementally, keep the ones that work for you, and drop the ones that don't.
Like common sense, it seems old and obvious, but it isn't very common. I guess it's the rarity of it that makes it seem extreme.
Take the pride of a man's effort away from him and give it a committee that little or no emotional or economic investment in it? Can anyone name another software project where this was done and the project improved?
There are no fields in Project 2000 for "love", "devotion", "pride", or "repute". On paper it might seem that more hands will make lighter work, but development by committee will surely make lighter work of causing Linux to fail.
Read "Mythical Man Month" to understand why more programmers to not necessary make a project go faster. Read "Cathedral and Bazaar" to understand the motivational value of pride, commitment, and repute in the Open Source community.
if( rebuild.benefit > rebuild.cost ) { rebuild.begin(); } else { legacy.patch(); } porting this to your favorite language is left as an exercise to the troller.
Try emacs-NT and the Cygwin's GNU ports. It's almost like having a unix box.
Nextstep was based on the Mach kernel and BSD4.3 from it's initial release in 1989. The swapfile problem I mentioned was endemic to their particular implementation of Mach. Unless Apple's engineers picked up pager sources from Mach 3 or implemented a new pager themselves, OS/X will still have this problem.
Next gambled everything on their OS, but they could not fix this problem. If it wasn't important enough to fix in Nextstep, it couldn't possibly be important enough to fix now. Apple may have opened the Darwin source, but Jobs clearly does not have the same dedication to overall system quality and performance that Linux and FreeBSD users have grown accustomed to. It's all about selling image at Apple - it's about the money.
I used to use Nextstep - the predecessor to OS/X. Nextstep used a swapfile scheme that prevented any swapped pages from being removed from the file if another page had been allocated in the file after it. In other words, the only way to shrink the swapfile was to deallocate pages in exactly the reverse order of their allocation - a nearly impossible task. When probed about the problem, Avie Tavanian (CTO of Apple, then the chief OS designer for Next) said that it would be exceedingly difficult to alter the swapfile algorithm. Perhaps it's different in OS/X, but his statement gives me good reason to doubt it.
What was the big deal about a big swapfile? The bigger it got, the slower the system became. I used to reboot twice a day to keep my system from bogging down. I had a 64Mb system (the most you could get in a typical workstation back then), and I ran emacs, the compiler/linker/debugger suite (modified from gcc & gdb) and my programs (they topped out around 10Mb). I was SO HAPPY to switch to NT because it meant that I could reboot only about once a week instead of twice a day!
I'm looking forward to moving back to *nix someday when the tools finally match those on Windows (emacs and cygwin ports have made NT bearable). But I'll switch back to Win95 before I got back to Nextstep or any current incarnation that behaves the same way.
Now you know where it came from.
In the most long-winded way imaginable, the author has said "OOP doesn't live up to its hype" and "OOP wasn't a silver bullet that quickly and easily improved the quality of his work."
Duh.
Before the web came along, OOP was the most hyped thing in technology. A lot of people made their livings selling snake oil in the form of books, seminars, methodologies, training courses, tools, libraries, etc. These leaches are just out there. Always have been, always will be. And they aren't just in tech. Pick up an investment rag and look at the ads. They're ridiculous. They're the culmination of almost a century of hucksterism.
Professionals have the responsibility to see through this and find the kernel of useful genius that made the topic so cool in the beginning. Believing the hype always leads to bitterness and regret. Creating the hype leads to a painful demise (I hope).
OOP tools are a big improvement. I like a lot of them, but none substitute for good techniques. How something (anything) is constructed has more significance in its final value than what material or which tool is used (except for things made from rare metals or minerals). I spent some time around IBM as a kid, and the acronym seen everwhere was TINSTAAFL - There is no such thing as a free lunch.
Don't believe the hype, and don't waste time being pissed off if you did. That's just more time wasted. You're young, your smart, go build something!
It's ZERO-click ordering! But seriously, Kamen's VC says "he had been sure that he wouldn't see the development of anything in his lifetime as important as the World Wide Web -- until he saw IT". Now at first I thought, "Come on, no one GETS a thing like web in just one sales meeting". But later while I was making chile I thought "Hey Jobs understood the PARC research right away. He understood the Pixar technology right away. He even recognized the genius of the Apple II while it was still a board full of handwraps." So then I thought "Ok, I'll forget that he's paying Bezos his Time-Man-Of-The-Year tax. I'll forget that iCubes crack (pfpfpf ha). I'll even forget how insanely great Nexts were supposed to be, and I'll step into the reality distortion field one last time and I'll believe it when Jobs says something is really cool." And then I thought, "Ok that's enough crack for tonight. Time to finish the chile."
0xdeadbeef was cool, but my favorite was the init used by NeXT: 0xcafebabe, in honor of the Barrones hotties in Menlo Park.
Despite your clear ability to make a better hamburger than McDonalds, the labor and equipment costs involved in producing millions of these prevents you as an individual from becoming a competitor. Employers realize there are no such production costs associated with IP and that a single individual can become a dangerous competitor. Developers need a usable defense against corporate encroachment into their personal mental space. In this case, the distinction between hamburger design and hamburger production is a significant one.
I'm having a nightmare where the Linux community spends all its time in-fighting while Microsoft keeps sinking their proprietary claws into every piece of exposed user flesh they can find. I guess I'm dreaming about what happened to Unix in the early 90s when major vendors argued over irrelevant minutia while Microsoft wrote NT. Pinch me and wake me up so I don't have to see this happen all over again!
I can see the value in reducing a child's exposure to violence. What concerns me is the permissive attitude towards "idealized violence" where the realistic reactions are quickly swept off the edge of the screen (i.e. spurting arteries, shattered bones, immense pain and suffering, wrecked lives, inconsolable families, pointless death). Children who watch sterilized attacks on disposable victims learn that violence is okay because the ramifications are insignficant. If someone gets shot in a movie, I want the director to show him drown in his own blood. Naturally, I don't want my children to see this at all until they're old enough to deal with it. But I definitely don't want them to watch PG-rated death where the consequences are quickly out-of-sight and out-of-mind.
I know many people who were staunch supporters of Microsoft in this issue. Believing in a free market, they felt that Microsoft had simply outperformed the competition and deserved the rewards for their efforts. The also felt that the case brought against them was a last-ditch effort by fussy childish millionaires to compete with Gates in the only arena they could.
But as this case has proceeded, much attention has been drawn to Microsoft's lame whining arguments and brutish tactics. These former supporters of Microsoft have questioned their beliefs and envisioned the long-term effects of an entity like Microsoft. They have taken the time to digest some the Open Source litany. Some of them turned completely against Microsoft, fdisked away Windows, and dove head first into Linux et al. Others still use grudgingly still use Windows because they now despise Microsoft but they still see the Windows/Office juggernaut as superior tech for them.
The longer this trial drags on, the more exposure people in general will get to the ugly side of Microsoft. The longer this trial drags on, the more time Open Source developers will have to create better answers to the question, "if not Microsoft, then what?".
Law is like the Open Source code for democratic society. You've found a bug, and you have the source. Let's see if you can hack a fix for it.
If the folks at ntv.ru did not know about the Slashdot Effect, they will soon.
That'll be 2 cents please.
An OS/browser that traverses ad links in literally the blink of an eye would cause more defections to Linux than any feature that could be added to Linux. For all of their prowess, Microsoft can also be their own worst enemy. e P.S. I don't even like point-to-focus