I hope it's just you, because I am aiming for a long and happy life doing computer programming. Not necessarily the IT industry in all its "glory", but somehow your story has sown a seed of doubt in me. But it's good that you're happy though. After all, it seems our bodies were simply not made to be put onto an office chair with eyes staring at a computer screen for hours straight...
I would speculate that BeOS went about the UI latency another way. I think what they did was to actively handle keyboard and mouse interrupts in a way where on each such interrupt BeOS would wake up the process that handled and routed the messages according to which window these should go, with processes that owned this window getting on top of the CPU-task-switch list. On top of that, they might intentionally slow-down (buffer) certain interrupts, such as mouse movement, if they trapped these at all, so that these would not have other I/O driven processes starve for CPU-time. But like I said, I think the clicks would be handled immediately.
This is in contrast to Linux, where the keyboard and mouse interrupts do not explicitly cause any process to wake up, but where these end up as events in an event queue of a process and then the CPU scheduler by its usual way of going about things wakes up each process (with CFS it will basically do a round-robin of sorts). So when you click a mouse, Linux does not really care - your mouse event simply ends up in an event queue, and then a process that wants to listen to these events does something about it, with the DIFFERENCE that it will only do that when it gets CPU-time, in its due time. When said due time is longer than necessary, users complain, and so it is the job of CPU scheduler to switch to processes that handle UI events as soon as it possibly can, while at the same time give necessary time to I/O driven processes churning away in the background at all times. In short Linux prioritizes processes, while BeOS prioritizes user initiated events. When Linux CPU sheduler is as good at giving event driven processes his attention promptly as BeOS is at not starving IO driven processes, both will be of roughly equal performance. However, I would prefer BeOS' way of doing things.
I can't say if its the placebo effect, but just about every part of my desktop experience now feels noticeably snappier, in UI response times across the entire desktop... (i used the script instructions, not the kernel patch.)
OK, once we managed to implant people everywhere with the analogy between a real organic virus and it's now just as common computer counterpart. People realized that it's a scary thing, and Norton Antivirus was born. I think it is time now to implant clueless moms and dads everywhere with a new idea - that buying a new pill you never seen in your life promising to cure you of cold, will most likely not do the trick. In other words, it's amazing how much people trust computer antivirus programs they never have even heard of before, but go and try to ask your mum to drink a mixture as an "antivirus" to common cold - she'll dismiss it on the spot. I think it's time we pushed the virus analogy a step deeeper - computer system is your body, would you want to experiment with unknown pills without asking some sort of authority on the subject first?
Talking about initial null references and all, I don't know about your Java compiler, but mine refuses to compile a program where an initially unassigned reference is attempted to be used. That's what it's all about isn't it - if the initial use of a unassigned (null) reference is prohibited at compile-time, then surely nothing will propagate anywhere and make a mess? Please advise;-)
Additionally, and regardless of how smart/strict a compiler is, are you saying that you would prefer another constant such as say 'unassigned' (which in fact cannot be assigned explicitly) as a value for unassigned references? Then, if an 'unassigned' value pops up from nowhere at runtime after your program has aborted with a thrown exception, you at least know that it was not a null pointer but that you're using a compiler that cannot tell where an unassigned reference is being used? Just thinking aloud...
Would you happen to know how one can recognize a handheld (in a good abstract way CSS does) BEFORE serving the page to said handheld? Because CSS only kicks in after the page is at client side. Of course it can reshape the content to a great degree, including hiding and rewriting it, but there is the waste of having to send it in the first place, knowing that it will be "discarded" at client side. Also, many handhelds benefit from less page weight to have to wait for and parse, that's where it would help too...
As a web developer I strongly disagree with the notion that a phone should include anything as specific as "Android" in the UA string. It just means every mobile-aware web developer out there needs to SPECIFICALLY cater for Android phones (otherwise there would not be a need for the string, would it?). The right way to do these kind of things is with CSS and it's 'handheld' media profile (http://www.w3.org/TR/CSS21/media.html#at-media-rule). And on top of it, don't go ape with fixed widths;-) You can also get the screen size via client side scripting host (Javascript) if you care about such things. Most of the time, if the site has been designed well, it will work just fine on any modern Internet-enabled phone.
I think you would agree with me that polluting UA strings with specific product names is a BAD IDEA. You would say "yeah, they are already have been doing it for years with IE/Mozilla etc" but in any case, this has never been designed as a courtesy for web developers to make decisions as to what version of the site to serve. It's the last resort piece of information, in case you really need to know what browser user is running.
If you really feel strong about this, at least think about including a profile of the browser instead - like the string "mobile", not "Android". Because otherwise we would soon need "iPhone", "Symbian", "Windows CE" or whatever mobile product is on the market at a particular moment...
Ditto. On Ubuntu, ever since version 8 something, the 'update-apt-xapian-index' binary, once started, even though a background process by design, is REALLY noticeable. It also consumes 97% CPU while it's doing whatever it's doing, which lasts a couple of minutes at most, then quits. In any case, it's annoying enough so that I tracked it down to being part of System Update, and changed the frequency of system update to once a week from once a day as before. This is how users command system updating, so next time developers of cool systems complain users are insecure because they don't patch their systems, shove it and remember - users decide what to update, and if your update is suboptimal, don't blame it on the users. As a result of an intrusive system update system, my operating system is one week behind a possibly critical update. Not much of course, but just an example...
If you let application developers (one of the least experienced group of developers out there) be responsible for responsiveness of desktop GNU/Linux, it is doomed. You need to enforce this from bottom-up, not top-to-bottom. The reality is that application code quality depends on the development environment. It's bad enough a lot of Linux applications are completely unmanaged and require decent knowledge of C in order not to suck. THe bold mission to educate those developers about how THEY need to account for responsiveness issues in THEIR application code is suicide. You can't expect the entire ecosystem to start shifting towards better I/O code. Just look at the state of network programming on Linux - it's VERY hard to develop a server for instance - there are so many things one needs to grok well - lingering sockets, thread synchronization, event handling using poll/epoll (entire libraries are written abstracting these for ease of use). You don't want the same level of difficulty programming file I/O, that's a step back, not forward. Like I said earlier, the proper focal point where this needs to be fixed is the kernel.
If you are talking about fixing the standard C library (which includes the 'read' I/O routines) then that's the wrong place too, because the library only contains the wrappers, it's again the kernel doing the actual job, so it's again the kernel you need to patch in that case. You can of course introduce a level of abstraction on top of stdlib, which makes the I/O scheduling issue go away by means of intelligent/heuristic reading/writing, and that's the least of all evils here. But I would still rework the scheduler instead, everything else is beating around the bush.
Let's add even more perspective: I think we can fairly assume that 99% of all "desktop" Linux users would prefer GUI responsiveness to boosting file copy speeds even up to 20%. As I mentioned elsewhere in this discussion, there are case studies that point out this fact - that for desktop users it's all about perceptive performance - how fast their buttons click back when they click on them and so on. Now, where am I going with this? Well, this means 'ionice' will not help them, and the analogy here is that 'ionice' is like a scalpel in a situation demanding a brain controlling a hand holding a scalpel. Which happens to be... the OPERATING SYSTEM kernel. Part of the reason we have computers is for them to aid us in our lives, often give us more free time. Today, 50% of those 99% of "desktop" Linux users have too little clue and/or time/desire to fiddle with 'ionice' on a case-by-case basis. In any case, 'ionice' is an ADDITION to, not a SUBSTITUTION for a solution to this problem. I don't mind 'ionicing' now and then, but I often want to spend my focus on things only human can do.
And of course (poor rhetorics again / trigger happy on the keyboard) the correct description of the behavior would not be Transmission eating my CPU. What I was observing however is that with enough torrents/seeds to apparently saturate the disk bandwidth (no big deal if you got a 10mbps Internet line both ways like I do) the rest of system GUI really was stopping to be responsive enough. Having 'ionice'd Transmission all the way to the background would make a considerable improvement to the point where things would be just acceptable. But I would always know when I had left it running in the background:-)
No intention from my side to badmouth the application. I like it a lot because of its simplicity and function. But I haven't fired it for months exactly because I am still afraid it will eat my CPU as the torrents are churning:-) You may be exactly right about the issue having been fixed, what do I know. My version is 1.92 (10621) that was bundled with Ubuntu 10.04. Mind you it's not Transmissions own GUI that suffered, it was any other process that I wanted to work with through the GUI.
My poor rhetorics regardless, the OP is wrong - there is neither a need for Linux to know that a file copy need be done in background (no need does not mean a user can't hint the system about his preference), nor should the users be dependent on 'ionice' to have responsive systems - Windows gets it right ENOUGH without user intervention.
Same goes for CONFIG_HZ - I think we all know deep down inside that nobody is going to bother resetting variables to fix the symptoms of a problem lying somewhere else entirely. Also, Transmission was just an example - I am sure its program is fairly straightforward, certainly straightforward enough to not make it a culprit - a 'dd if=/dev/sda of=/dev/sdb' will starve the system in much the same manner.
It seems to me you don't really know what you're talking about. As much as one wants one's file copying to be finished sooner, it should never EVER impair responsiveness of a workstation. That's what multitasking operating systems with GUIs are all about. It has nothing to do with Linux or its kernel knowing where it's priorities should be.
Have you ever heard the BitTorrent client Transmission? Whenever the thing has anything to do (downloading / uploading) I have an almost useless desktop. Now, I don't really care how fast it writes to disk as long as it keeps a decent pace, but I do care about being able to be productive while it's doing its job, otherwise I could resort to MS-DOS or somthing.
You are obviously confusing concurrency with latency. Latency has been proved time and again to be THE decisive factor for desktop users. It's all on Internet, just do some googling and you'll find case studies which show what is more important to users - whether their 700Mb DivX file copy finishes in 3 minutes instead of 5 or whether their computer keeps being as responsive as they are used to, during those minutes. Users always prefer latency, which is why Con Kolivas' work is appreciated, regardless of what you may have heard (in particular from Linus.) His whole argument with the opponents of a plugin-scheduler (and scheduler plugin system) revolved around the fact that what works for servers doesn't always work for desktops.
Precisely. And compromising an OS is in fact an expected norm by any self-respecting computer user. It goes together with having the right to f.e. change system files etc. So the second question is valid: why bother? For those with "trusted computing" systems however, it's a whole other mixbag.
There are tons of problems with this, not the least of which lies in the fact that if you have a secure boot and trusted environment, you don't really need a NAND chip to read an identity from, you can make do with a file that user cannot remove or alter, i.e. a system file. That's what trusted would mean here. This however presents another problem - amount of users willing to use such a "trusted" system is inversely proportional to how many of these users grok computers. Typically, your mildly paranoid hackers and UNIX minimalists will reject such system on sight because they value their right to introspection and control, while someone like their moms and dads with Windows won't even know or care as long as they can write their Word documents and send email. Then again, the first group goes out of their way to enlighten all other groups on how to grok more IT, including deleting all cookies, which is freely available through Googling, including links to software that does it for you with a click of a button. Making a completely secure identification scheme, if possible, would lead to revolt in the first group (and outright rejection, as mentioned) and an active propaganda with the aim of educating all the other groups against using the method again.
I don't think your analogy is appropriate. Arguably, they should give users preferences, which is different from a car. Car is hardware, the pedal is at one place, the brake at another. If these don't suit you, because you learned to drive with different combination of pedal placements, you are right - it's a disaster of proportions. However, a user account is personal, and placement of buttons is not a problem since these are personal preference - some people DO prefer buttons in different places than what's usual for you - the problem is in having and keeping a personal user account, no matter what car you drive. With cars, it's a pipe dream - I mean you take the wheel of your friends weird vehicle with swapped pedals, the car does not care that it's you not the friend driving, and it for sure won't accomodate the pedals for you. With software however, it's expected, just as it is expected that when you click a link, you may want Firefox, while your friend would want Internet Explorer. So there. My point is - sometimes car analogies suck.
Silverlight 4 only 'runs' on Microsoft Windows. Moonlight goes as far as supporting Silverlight 2.0 specs, and even that is flaky - no DRM support (don't bitch about it to me, bitch about it to content developers deploying it), some parts of API is missing, codecs have to be downloaded manually and more funk. Compare that to Flash Player, a similar and similarly abused technology, but one which works on most platforms today without a lot of funky quirks. I would know, I write Flash Player applications on Ubuntu.
In a nutshell: Silverlight is not even in the same league as Flash, as far as adoptance and platform support is concerned. Microsoft is also out of touch with reality and it is my opinion that they should not be depended upon when it comes to "enriching" the Web, but I have elaborated on this before, so I am not going to repeat myself.
In fact the whole article sounds (didn't say it in fact is) like someones desperate pitch to bring peoples attention back to Silverlight, as if it is already forgotten. Which it should be, because there is at least one wrong thing with it - the abovementioned platform support, which I believe will not catch up anyway. Things just go too fast these days, if you are not on top after a year, scrap it and redirect dire resources elsewhere.
It's certainly nice they are improving the JavaScript engine code - it will lead to less CPU cycles spent on JS intensive pages (most of the stuff published today), but I feel there are other areas as well that should always stay a priority on par or above the JS engine code: startup time and removing cruft that slows this down, possibly having a lightweight firefox "starter" process, so that some important cache is always in memory (i know the OS caches a lot of stuff, but I can't help but notice the delay still). Some Gecko rendering tweaks would help too - I am sure there are lots of room for optimizations there. Anyway, the Firefox code is large enough to be worked on for loong time, making it better and better. I still applaud Mozilla for trying and delivering what we currently have.
Slashdot Mirror
"Fuck off." is even better
I hope it's just you, because I am aiming for a long and happy life doing computer programming. Not necessarily the IT industry in all its "glory", but somehow your story has sown a seed of doubt in me. But it's good that you're happy though. After all, it seems our bodies were simply not made to be put onto an office chair with eyes staring at a computer screen for hours straight...
I would speculate that BeOS went about the UI latency another way. I think what they did was to actively handle keyboard and mouse interrupts in a way where on each such interrupt BeOS would wake up the process that handled and routed the messages according to which window these should go, with processes that owned this window getting on top of the CPU-task-switch list. On top of that, they might intentionally slow-down (buffer) certain interrupts, such as mouse movement, if they trapped these at all, so that these would not have other I/O driven processes starve for CPU-time. But like I said, I think the clicks would be handled immediately.
This is in contrast to Linux, where the keyboard and mouse interrupts do not explicitly cause any process to wake up, but where these end up as events in an event queue of a process and then the CPU scheduler by its usual way of going about things wakes up each process (with CFS it will basically do a round-robin of sorts). So when you click a mouse, Linux does not really care - your mouse event simply ends up in an event queue, and then a process that wants to listen to these events does something about it, with the DIFFERENCE that it will only do that when it gets CPU-time, in its due time. When said due time is longer than necessary, users complain, and so it is the job of CPU scheduler to switch to processes that handle UI events as soon as it possibly can, while at the same time give necessary time to I/O driven processes churning away in the background at all times. In short Linux prioritizes processes, while BeOS prioritizes user initiated events. When Linux CPU sheduler is as good at giving event driven processes his attention promptly as BeOS is at not starving IO driven processes, both will be of roughly equal performance. However, I would prefer BeOS' way of doing things.
I can't say if its the placebo effect, but just about every part of my desktop experience now feels noticeably snappier, in UI response times across the entire desktop... (i used the script instructions, not the kernel patch.)
OK, once we managed to implant people everywhere with the analogy between a real organic virus and it's now just as common computer counterpart. People realized that it's a scary thing, and Norton Antivirus was born. I think it is time now to implant clueless moms and dads everywhere with a new idea - that buying a new pill you never seen in your life promising to cure you of cold, will most likely not do the trick. In other words, it's amazing how much people trust computer antivirus programs they never have even heard of before, but go and try to ask your mum to drink a mixture as an "antivirus" to common cold - she'll dismiss it on the spot. I think it's time we pushed the virus analogy a step deeeper - computer system is your body, would you want to experiment with unknown pills without asking some sort of authority on the subject first?
Talking about initial null references and all, I don't know about your Java compiler, but mine refuses to compile a program where an initially unassigned reference is attempted to be used. That's what it's all about isn't it - if the initial use of a unassigned (null) reference is prohibited at compile-time, then surely nothing will propagate anywhere and make a mess? Please advise ;-)
Additionally, and regardless of how smart/strict a compiler is, are you saying that you would prefer another constant such as say 'unassigned' (which in fact cannot be assigned explicitly) as a value for unassigned references? Then, if an 'unassigned' value pops up from nowhere at runtime after your program has aborted with a thrown exception, you at least know that it was not a null pointer but that you're using a compiler that cannot tell where an unassigned reference is being used? Just thinking aloud...
Would you happen to know how one can recognize a handheld (in a good abstract way CSS does) BEFORE serving the page to said handheld? Because CSS only kicks in after the page is at client side. Of course it can reshape the content to a great degree, including hiding and rewriting it, but there is the waste of having to send it in the first place, knowing that it will be "discarded" at client side. Also, many handhelds benefit from less page weight to have to wait for and parse, that's where it would help too...
As a web developer I strongly disagree with the notion that a phone should include anything as specific as "Android" in the UA string. It just means every mobile-aware web developer out there needs to SPECIFICALLY cater for Android phones (otherwise there would not be a need for the string, would it?). The right way to do these kind of things is with CSS and it's 'handheld' media profile (http://www.w3.org/TR/CSS21/media.html#at-media-rule). And on top of it, don't go ape with fixed widths ;-) You can also get the screen size via client side scripting host (Javascript) if you care about such things. Most of the time, if the site has been designed well, it will work just fine on any modern Internet-enabled phone.
I think you would agree with me that polluting UA strings with specific product names is a BAD IDEA. You would say "yeah, they are already have been doing it for years with IE/Mozilla etc" but in any case, this has never been designed as a courtesy for web developers to make decisions as to what version of the site to serve. It's the last resort piece of information, in case you really need to know what browser user is running.
If you really feel strong about this, at least think about including a profile of the browser instead - like the string "mobile", not "Android". Because otherwise we would soon need "iPhone", "Symbian", "Windows CE" or whatever mobile product is on the market at a particular moment...
OMG, dying consumers ;-)
Ditto. On Ubuntu, ever since version 8 something, the 'update-apt-xapian-index' binary, once started, even though a background process by design, is REALLY noticeable. It also consumes 97% CPU while it's doing whatever it's doing, which lasts a couple of minutes at most, then quits. In any case, it's annoying enough so that I tracked it down to being part of System Update, and changed the frequency of system update to once a week from once a day as before. This is how users command system updating, so next time developers of cool systems complain users are insecure because they don't patch their systems, shove it and remember - users decide what to update, and if your update is suboptimal, don't blame it on the users. As a result of an intrusive system update system, my operating system is one week behind a possibly critical update. Not much of course, but just an example...
If you let application developers (one of the least experienced group of developers out there) be responsible for responsiveness of desktop GNU/Linux, it is doomed. You need to enforce this from bottom-up, not top-to-bottom. The reality is that application code quality depends on the development environment. It's bad enough a lot of Linux applications are completely unmanaged and require decent knowledge of C in order not to suck. THe bold mission to educate those developers about how THEY need to account for responsiveness issues in THEIR application code is suicide. You can't expect the entire ecosystem to start shifting towards better I/O code. Just look at the state of network programming on Linux - it's VERY hard to develop a server for instance - there are so many things one needs to grok well - lingering sockets, thread synchronization, event handling using poll/epoll (entire libraries are written abstracting these for ease of use). You don't want the same level of difficulty programming file I/O, that's a step back, not forward. Like I said earlier, the proper focal point where this needs to be fixed is the kernel.
If you are talking about fixing the standard C library (which includes the 'read' I/O routines) then that's the wrong place too, because the library only contains the wrappers, it's again the kernel doing the actual job, so it's again the kernel you need to patch in that case. You can of course introduce a level of abstraction on top of stdlib, which makes the I/O scheduling issue go away by means of intelligent/heuristic reading/writing, and that's the least of all evils here. But I would still rework the scheduler instead, everything else is beating around the bush.
Let's add even more perspective: I think we can fairly assume that 99% of all "desktop" Linux users would prefer GUI responsiveness to boosting file copy speeds even up to 20%. As I mentioned elsewhere in this discussion, there are case studies that point out this fact - that for desktop users it's all about perceptive performance - how fast their buttons click back when they click on them and so on. Now, where am I going with this? Well, this means 'ionice' will not help them, and the analogy here is that 'ionice' is like a scalpel in a situation demanding a brain controlling a hand holding a scalpel. Which happens to be... the OPERATING SYSTEM kernel. Part of the reason we have computers is for them to aid us in our lives, often give us more free time. Today, 50% of those 99% of "desktop" Linux users have too little clue and/or time/desire to fiddle with 'ionice' on a case-by-case basis. In any case, 'ionice' is an ADDITION to, not a SUBSTITUTION for a solution to this problem. I don't mind 'ionicing' now and then, but I often want to spend my focus on things only human can do.
And of course (poor rhetorics again / trigger happy on the keyboard) the correct description of the behavior would not be Transmission eating my CPU. What I was observing however is that with enough torrents/seeds to apparently saturate the disk bandwidth (no big deal if you got a 10mbps Internet line both ways like I do) the rest of system GUI really was stopping to be responsive enough. Having 'ionice'd Transmission all the way to the background would make a considerable improvement to the point where things would be just acceptable. But I would always know when I had left it running in the background :-)
I meant version 1.93, not 1.92.
No intention from my side to badmouth the application. I like it a lot because of its simplicity and function. But I haven't fired it for months exactly because I am still afraid it will eat my CPU as the torrents are churning :-) You may be exactly right about the issue having been fixed, what do I know. My version is 1.92 (10621) that was bundled with Ubuntu 10.04. Mind you it's not Transmissions own GUI that suffered, it was any other process that I wanted to work with through the GUI.
My poor rhetorics regardless, the OP is wrong - there is neither a need for Linux to know that a file copy need be done in background (no need does not mean a user can't hint the system about his preference), nor should the users be dependent on 'ionice' to have responsive systems - Windows gets it right ENOUGH without user intervention.
Same goes for CONFIG_HZ - I think we all know deep down inside that nobody is going to bother resetting variables to fix the symptoms of a problem lying somewhere else entirely. Also, Transmission was just an example - I am sure its program is fairly straightforward, certainly straightforward enough to not make it a culprit - a 'dd if=/dev/sda of=/dev/sdb' will starve the system in much the same manner.
I did not make up the studies, in case you are ironic about them telling you what you want:
http://portal.acm.org/citation.cfm?id=339420
http://www.sapdesignguild.org/community/design/perc_perf.asp
and of course the closely related term http://en.wikipedia.org/wiki/Perceived_performance
I'll admit it's not like googling Angelina Jolie but the information is out there
Well, his trolls are more knowledgeable than you and your trolls :-P
Depends on the filesystem, naturally.
It seems to me you don't really know what you're talking about. As much as one wants one's file copying to be finished sooner, it should never EVER impair responsiveness of a workstation. That's what multitasking operating systems with GUIs are all about. It has nothing to do with Linux or its kernel knowing where it's priorities should be.
Have you ever heard the BitTorrent client Transmission? Whenever the thing has anything to do (downloading / uploading) I have an almost useless desktop. Now, I don't really care how fast it writes to disk as long as it keeps a decent pace, but I do care about being able to be productive while it's doing its job, otherwise I could resort to MS-DOS or somthing.
You are obviously confusing concurrency with latency. Latency has been proved time and again to be THE decisive factor for desktop users. It's all on Internet, just do some googling and you'll find case studies which show what is more important to users - whether their 700Mb DivX file copy finishes in 3 minutes instead of 5 or whether their computer keeps being as responsive as they are used to, during those minutes. Users always prefer latency, which is why Con Kolivas' work is appreciated, regardless of what you may have heard (in particular from Linus.) His whole argument with the opponents of a plugin-scheduler (and scheduler plugin system) revolved around the fact that what works for servers doesn't always work for desktops.
Precisely. And compromising an OS is in fact an expected norm by any self-respecting computer user. It goes together with having the right to f.e. change system files etc. So the second question is valid: why bother? For those with "trusted computing" systems however, it's a whole other mixbag.
There are tons of problems with this, not the least of which lies in the fact that if you have a secure boot and trusted environment, you don't really need a NAND chip to read an identity from, you can make do with a file that user cannot remove or alter, i.e. a system file. That's what trusted would mean here. This however presents another problem - amount of users willing to use such a "trusted" system is inversely proportional to how many of these users grok computers. Typically, your mildly paranoid hackers and UNIX minimalists will reject such system on sight because they value their right to introspection and control, while someone like their moms and dads with Windows won't even know or care as long as they can write their Word documents and send email. Then again, the first group goes out of their way to enlighten all other groups on how to grok more IT, including deleting all cookies, which is freely available through Googling, including links to software that does it for you with a click of a button. Making a completely secure identification scheme, if possible, would lead to revolt in the first group (and outright rejection, as mentioned) and an active propaganda with the aim of educating all the other groups against using the method again.
I don't think your analogy is appropriate. Arguably, they should give users preferences, which is different from a car. Car is hardware, the pedal is at one place, the brake at another. If these don't suit you, because you learned to drive with different combination of pedal placements, you are right - it's a disaster of proportions. However, a user account is personal, and placement of buttons is not a problem since these are personal preference - some people DO prefer buttons in different places than what's usual for you - the problem is in having and keeping a personal user account, no matter what car you drive. With cars, it's a pipe dream - I mean you take the wheel of your friends weird vehicle with swapped pedals, the car does not care that it's you not the friend driving, and it for sure won't accomodate the pedals for you. With software however, it's expected, just as it is expected that when you click a link, you may want Firefox, while your friend would want Internet Explorer. So there. My point is - sometimes car analogies suck.
Yeah well, truth hurts.
For those who don't read subject line:
Silverlight 4 only 'runs' on Microsoft Windows. Moonlight goes as far as supporting Silverlight 2.0 specs, and even that is flaky - no DRM support (don't bitch about it to me, bitch about it to content developers deploying it), some parts of API is missing, codecs have to be downloaded manually and more funk. Compare that to Flash Player, a similar and similarly abused technology, but one which works on most platforms today without a lot of funky quirks. I would know, I write Flash Player applications on Ubuntu.
In a nutshell: Silverlight is not even in the same league as Flash, as far as adoptance and platform support is concerned. Microsoft is also out of touch with reality and it is my opinion that they should not be depended upon when it comes to "enriching" the Web, but I have elaborated on this before, so I am not going to repeat myself.
In fact the whole article sounds (didn't say it in fact is) like someones desperate pitch to bring peoples attention back to Silverlight, as if it is already forgotten. Which it should be, because there is at least one wrong thing with it - the abovementioned platform support, which I believe will not catch up anyway. Things just go too fast these days, if you are not on top after a year, scrap it and redirect dire resources elsewhere.
It's certainly nice they are improving the JavaScript engine code - it will lead to less CPU cycles spent on JS intensive pages (most of the stuff published today), but I feel there are other areas as well that should always stay a priority on par or above the JS engine code: startup time and removing cruft that slows this down, possibly having a lightweight firefox "starter" process, so that some important cache is always in memory (i know the OS caches a lot of stuff, but I can't help but notice the delay still). Some Gecko rendering tweaks would help too - I am sure there are lots of room for optimizations there. Anyway, the Firefox code is large enough to be worked on for loong time, making it better and better. I still applaud Mozilla for trying and delivering what we currently have.