Google, Youtube, myspace, facebook, et al boomed after that period. I know Google already existed, and unsure about the dates of the rest, and even who started each, but I suspect they benefited greatly from the deluge of willing workers out there. Perhaps one or many of those would have never gotten sufficiently off the launch pad to be considered a success.
As painful and uncertain as ubiquitous layoffs are, the small silver lining is that some companies with relevant vision but lacking in the workforce to realize their good ideas will suddenly be able to have some good workforce.
As their IE demonstrated, the apps have *some* control over their taskbar presentation. I don't know if it is as flexible as Dock though. So Win7 may see more apps doing stuff like that in the taskbar instead of resorting to tray icons.
Yes, the fundamental philosophy each inherited is different, but in effect at the 'dock' or 'taskbar' representation, Windows 7 and OSX end up presenting things similarly.
He makes the point that the OSX dock is for applications and that Windows is for each window, though Microsoft is heavily encouraging grouping that makes it seem as much like the dock as possible. True, in Windows this can be turned off, but that doesn't do anything to disprove the intent is to acheive the model the Dock presents. He says that when you close the last application window, it dissapears from the taskbar. The issue there is it behaves the same on Windows 7 and OSX, if an application exits, then the dock icon or taskbar presennce will disappear unless persistantly set.
He mentions things like the presence of the notification area as proof of difference, but all it really proves is that MS had a few different design ideas as they went and they must support all of them as a consequence.
Just like WindowMaker largely deals with non-GNUstep applications and makes them seem NeXT like through some of the best window group identifying methods in an X system, Windows is trying to fight clutter by removing quicklaunch and taskbar redundancy, and enabling the taskbar presence to be manipulated to replace system tray presence.
Leave sprint and come back in later for the decent stuff. I.e. by mid year they are supposed to have a handful of android devices and of course the palm pre. Leaving sprint and going for a month-to-month prepaid carrier may be appealing.
You may not hear it in your setup, but in my setup of hand-woven pure gold-plated copper wrapped in diamond-encrusted insulation, the artifacts of FLAC come through clearly.
I agree with the perspective on microblogging as athe only thing a site does. I just don't see the revenue stream in something like that inherently. I do see the alternative possibility that Twitter becomes a brand name and licenses their presence to be integrated in other sites. I think there will be a focus on bringing together currently disparate aspects of 'social networking' and revenue strategies to evolve. Currently, I don't think the revenue streams can stand on their own, but social networking is too ubiquitous and popular for *no one* to get a rational business plan going.
I think the outlook on targeted advertising is particular. The only aspect that is potentially interesting is that too much money went in and set impossible expectations. However, the quality of the advertising I think too significant to discount. Interactive, targeted advertising is something leaps and bounds over television. There are a few hotspots on television where almost everyone will see advertising, and some shows with such a narrow fanbase it actually turns out to be kind of targeted. However, the production cost to participate is non-trivial, and viewers have to take it upon themselves to write down details to research it later if they have never heard of the product. Also, the ubiquity of DVR reduces the exposure to ads.
The statement on social news had nothing to do with the value of social news sites, and everything to do with neglecting a business plan. This is no surprise.
On online video, they claim that other than YouTube and Hulu, little will be left. I would support the statement, with the note that Porn content sites will continue.
On online radio, I would be reluctant to say that's out, but again the focus is not inherent flaws, but rather the recording industries being resistant towards that model and making life hard intentionally. The recording indutry is ass-backwards enough to sink an industry that would be highly valuable to them.
MKV is a container format. It's not impossible for a container format to induce overhead, but in all likelihood that isn't the case.
The codec would be something like h264,xvid,indeo,theora,etc for video, aac, mp3,vorbis,wav,etc.
I don't know about Quicktime, but avi is horribly limited. Ogg seemed to have promise for a container format, but for whatever reason MKV came about with support for some killer features menus and vobsub format subtitle tracks. I have never seen an mkv with menu, but I have heard it exists.
It would be interesting to know the codecs involved.
My question is why they have to make it more confusing by bundling it separately. If they are striving to be an easy sort of experience, they should be able to have a unified media, perhaps with a special option to disable 64-bit even if possible at install time.
I also wonder why they don't have any strategy like Apple had for 'Universal Binaries'. I suppose they are at a disadvantage for not having a more comprehensive application directory strategy, which Apple easily made use of to get multi-architecture applications that looked like a single icon to the typical end-user.
I understand the need for 32-bit (many Atom, pre-core2 non-netburst Intel processors), but it wouldn't frustrate users and stall application developers so much if they had taken certain measures.
PAE is not a panacea. There is a performance penalty and it is a hackish way of solving the problem. As you acknowledge, it does not address the per-process limitations. With certain desktop appplications, notably more advanced games, I could see the per-process limit being hit, even if PAE gave you at least warm fuzzies about your apparent total memory. There is a reason why distributions provided PAE-disabled kernels in x86 world.
Though you mention buggy 32-bit code having problems in long mode, I have never seen that occur in Linux or Windows. In terms of 16-bit code, I was unaware of that, however considering the vintage of such code (i.e. Pentium 60 was last processor on the market before Win95 became essentially ubiquitous), I suspect a fully emulated environment is quite possible. I haven't run into 16-bit applications in an eternity though.
I will say that Linux and Windows don't provide a facility to make the situation trivial for application vendors. I'm not sure if Apple is going to do something for x86/x86_64 applications, but they certainly have proven a useful strategy in the PPC/x86 case of leveraging application directories and conventions to have 'Universal Binaries', along with convenient checks in their development tools to build such a thing. I don't use OSX as there is much I'm not crazy about, but they did an excellent job of enabling application vendors to support two very different platforms without putting too much burden on their build environment or the users.
MS is typically paranoid about really really old OSes, and uses a layout with a iso9660 visible file: mount -t iso9660 -o loop 7000.0.081212-1400_client_en-us_Ultimate-GB1CULXFRE_EN_DVD.iso t [root@localhost Download]# ls t readme.txt [root@localhost Download]# umount t [root@localhost Download]# mount -t udf -o loop 7000.0.081212-1400_client_en-us_Ultimate-GB1CULXFRE_EN_DVD.iso t [root@localhost Download]# ls t autorun.inf bootmgr efi sources upgrade boot bootmgr.efi setup.exe support
I got to a page that had a 'download now' button and a license key, and the download now button didn't work. (Using Firefox on Fedora 10 at the moment).
I did a view source, copied the url and pasted, it gave me some weird message on screen about IE and java, but the ISO started downloading anyway.
Is it really MFlop or GFlops? 78 GFlops may seem a tad high to me, but 78 MFlops is much lower than I would expect. A Core2 based quad core 3.0 ghz would get 48 GFlops theoretical peak double precision gflops...
The problem I had was that the VM console was not a convenient way to use apps, and 'remote' X and such performed noticeably worse than local due to the performance of the virtual network bridge and two IP stacks being significantly worse than a local Unix socket X usually uses.
chroot I did not advocate as security, so much as library isolation, so any funky library requirements are met. However, lxc is certainly more comprehensive for this sort of activity.
BTW, don't know why you would say anything special would have to be done for 32-bit in a 64-bit env. All the OSes in x86_64 and ppc64 support running 32 bit applications in 64-bit setups.
I know that is Verizon's price. I'm unsure about AT&T, but T-mobile's is a tad lower as is Sprint's. Sprint's is particularly interestingly low for shared plans relative to the rest. This of course makes sense, as at the moment Sprint is the most desperate as they have a lousy reputation and must take the most drastic action. I'm pretty sure that Verizon has the highest prices (excepting AT&T, who I've no looked up), and they also happened to have the largest market share.
In other words, things are shaping up pretty much as one would expect a competitive market to shape up, with the leaders enjoying the benefits of reputation. The fact that things are not more different as they are makes sense too. Competition should force competitor's to price equivalently. In the auto industry, a common 4-door sedan will run in the 15-20 thousand US dollar area, regardless of manufacturer. There are outliers, certainly, but the major auto makers tend to manage the same price points.
If I'm ever forced to deal with an issue like incompatible versions of glibc in the future, I could contain that; or if I want to try upgrading a piece of software, I can roll back to a snapshot or keep multiple copies of the virtual appliance around
Why not use chroot/jails/containers/etc? The multiple kernel instances serve only to add overhead (trust me, I did virtualization and it suffered signigifcant performance degradation within a host). The performance may have had more to do with VM-host networking speed, but I'm much happier with the latter.
If you had to bridge OS types, that is another matter, but the user experience per VM can not converge (Windows will have drive letters, other's won't, Applications won't transparently interleave, etc).
And then there is trying to be different for the sake of being different.
Too many people seem to think if it remotely resembles in some way technology they have already seen, it must be antiquated and stale. In the framework of being Unix-like, GNU and Linux can be found in consumer routers, high-end networking equipment, servers, cell-phones, DVRs, other set-top boxes, the list goes on. Each field with a highly customized and frequently innovative stack on top of familiar Unix-like concepts. Underneath it all, there exists a filesystem with same-old devnodes, with shell commands and a filesystem hierarchy that is familiar. To tinker with that just because the concepts are decades old would be akin to saying "hey, round wheels have been in use for centuries, let's put some triangular wheels in our next model to break out of that rut!". My experience suggests there aren't any particularly more compelling ideas at this level to date, and interesting concepts built upon these layers are not held back by any particular aspects of them. The only thing that change for the sake of being 'new' will do is make it hard to follow without sufficient benefit.
In your context, Xorg isn't the origin of your perceived troubles, the developers of applications on top of it are. I doubt you'd be satisfied with a one-app-at-a-time desktop environment, so you'd probably be hoping for someone else to port or create a desktop UI in the event of an Android push to the desktop, with no particular reason why it wouldn't come to the same results you don't like. Maybe you want to tinker with GNUstep, ROX, XFCE, or ratpoison, I'm not sure what you like and can't speak to your tastes. Though many of those may not be sufficient as it stands, but perhaps one jives with you and you'd contribute to advancing its state. There are no shortage of UI concepts to try without going down the Gnome/KDE path. A fleshed out GNUstep on top of Xorg, for example, could feel identical to OSX UI, despite being on top of the 'old and crufty, unix-like UI architecture'.
In terms of moving millions of units instead of hundred of thousands, that is precisely what Android is doing. Android is a purpose-build platform and is a very interesting platform for that market. In terms of displacing Microsoft on the desktop without migrating users from that form factor, Android won't do that. Users are, by and large, content with the paradigm that Apple, MS, and most Linux distributions provide. To ask them to radically change what they do will not win them over.
800x480 is still a lot of resolution compared to the G1. And an important difference here is that the netbook has a huge screen in physical size compared to a phone. It may have better aggregate resolution, but the DPI being horrible points to a different style of interaction.
A phone tends to have less resolution, but in an even tinier form factor. That means your applications are designed for a 3" display that happens to be pretty good in terms of DPI. If you had 2560x1600 on a 3" display, you still wouldn't stick gobs of windows and icons into it, you'd just have a really crisp small application.
The reality would be a netbook equipped with Android would be an oversized cell-phone. It wouldn't offer anything meaningfully advantageous over a cell phone (same apps, same amount of data, happens to be bigger), without the portability of the cell phone. If the netbook vision/market is one that resonates best with a UI like Android, then it is doomed to fade away immediately in the face of equivalent phones.
The thing about the multi-window paradigm is it gives the user the choice. As you say, you can just maximize anyway, and alt-tab or whatever to switch. The ability to operate otherwise may be ignored if you wish.
However, I make use of the screen real estate. When programming, I'll have documentation up concurrently. I don't have to ask the computer to switch contexts for me, I just look over. When doing some work, I may need to tail a log file so I'll notice and instantly process the data when it happens. Sometimes, I leave windows up, stuck to the workspace and on top to remind me that I need to get back to it as soon as it is ready for interaction while I move on. Very frequently, I arbitrarily need to link together two disparate parts of two applications due to a correlation between them neither developer would have intended. Often, I need a specific viewport and can disregard parts allowing me to achieve what I want through control of the overlap.
Microsofts remote desktop and NX and vnc lack one thing I'd like, application integration with my desktop. Meaning even the "tray" presence of an application melds with everything else. I know some hacks have applications interleaved in other windows, but to date remote applications with the exception of X do not manage to get into the same "tray" my local applications get into. I hear of a NX rootless mode, but I've never actually figured out how to try it. A rootless NX session with detach capabilities may be my holy grail, but the other solutions, as it stands, don't have the required visibility into the details to make it happen (correct me if I am wrong about RDP/Netmeeting).
Just as screen's existence does not obviate the need for ssh, NX's work complements X's architecture, it does replace it.
I agree with you that accommodating high-latency links and session management are two aspects the core Xorg server lacks, but the underlying technology is fundamentally amenable to achieve those ends through additions.
Finally, the question is what ends will be achieved by a replacement technology that Xorg has not achieved itself. I've seens hosts of projects come and go with the aim of implementing some featureset that X lacks, sometimes claiming it's not even possible to address the need through extending X. The problem is by the time they can get off the ground, Xorg has implemented an extension to accommodate the need.
You can change number of monitors spanned, resolution, orientatation. The only one that it may lack is changing color depth dynamically (not sure), but then again, people don't generally have reason to change that in X.
As much as so many people seem to hate X (many for no particularly well found technical reason I will add, some have technical justifications, but many just think it's 'old'), Android would not be an improvement in display or UI technology for desktop usage: -No inherent remote display capabilities. X has this in it's very foundation. There was no reason for a cell-phone/embedded OS to implement such functionality in the contexts Android target, so this wasn't a bad decision. -Multi-window operation. Again, the target is applications where the resolution, screen size, and interface methods do not lend themselves well for multiple windows. As such the paradigm is single application. -Extending from the above, no advanced window management/compositing. The inter-application effects and utility with 3D acceleration found in Compiz, Aero, and Quartz have no reason to be there, despite providing productivity benefits (at least in the compiz and Quartz variants).
Do not get excited about the prospect of any arbitrary display technology displacing X, regardless of the underlying technical merits in the given context. Try to understand the hard technical reasons for your X hate, and do a bit of research to make sure they are not FUD or that the Xorg team isn't already addressing your concerns in a reasonable manner.
From what I've tried, Android is a great platform for the environment it targets. It achieves this by not trying to be a one-size fits all solution. Usage styles that work on the desktop do not scale to handheld devices. By the same token, good handheld UI does not scale to Desktop.
There were two parts, a presumably obvious warning, then braking. Presumably if attempting a lane change and a loud warning goes off, you stop changing lanes. Ditto for drowsy drifting.
And in your disabled car scenario, braking may reduce it from fatality to serious injury.
I think more sophisticated sensors that give off really annoying alerts to demand driver attention and action are required. Annoying so that people don't start banking on them too much. That is the chief danger, people stop bothering to check because a nice beep will let them know most of the time. If it is a grating alarm, they may be more reluctant..
I think there is a limit on the whole hardware/software roles heer, but: -If not upgradeable, their original firmware may have been busted, and they would be SOL. Their original firmware happened to not have *this* problem likely out of luck rather than knowing. -If no "software" (not plausible, but hypothetical), then same deal.
To an extent, "fix it in firmware" philosophy in the industry has influenced product release quality. I don't think a lack of testing has been pervasive, though, just shipping without addressing known problems. In this specific context, I doubt any test case they would nominally have would have caught this before ship, and thus the upgradeable firmware could be their hope of recovery (though it sounds that their may be no non-intrusive recovery procedure).
In terms of MS brand loyalty, I'm not sure what more they can do to customers that they haven't already done. xBox360 far outpace PS3 sales despite much criticism for failed units. Windows made it to XP despite giving the home user an incredibly unstable experience to that date. People swear by IE despite the fact it always trails other browsers in standards compliance and performance (not just the people too lazy to get something else, some people consciously choose it). I know people who chase Windows Mobile and use that variant of IE despite that variant of IE is even worse.
Given, these are a minority, most are at best indifferent to MS. They use MS because their needed apps are Windows-only, the vendors target Windows because the users aren't moving. MS revenue is pretty much rooted in that chicken and egg left over from the days where viable choice was limited. I see a lot more conscious avoidance of the Zune and WinMo devices, which I would like to attribute to recognition MS is too powerful to let it grow, yet the 360 is very successful. Maybe WinMo and Zune are just bad product and the consumers just don't care.
It's not a magical MD5 sum cracker, it's just a way of having an index of pre-computed strings that checksum to various values.
The only ubiquitous usage that is vulnerable to this attack is Microsoft SAM database. Many one-off applications similarly implement unsalted hashes. Unices salt passwords and are therefore not inclined to suffer. It doesn't matter the hashing algorithm in use, they are not particularly differently susceptible to this sort of attack. Note also that cracking the hashes in the SAM database is not even required, as NTLM has the client provide the pre-computed hash instead of password. It's really an extra-braindead architecture.
Slashdot Mirror
Google, Youtube, myspace, facebook, et al boomed after that period. I know Google already existed, and unsure about the dates of the rest, and even who started each, but I suspect they benefited greatly from the deluge of willing workers out there. Perhaps one or many of those would have never gotten sufficiently off the launch pad to be considered a success.
As painful and uncertain as ubiquitous layoffs are, the small silver lining is that some companies with relevant vision but lacking in the workforce to realize their good ideas will suddenly be able to have some good workforce.
As their IE demonstrated, the apps have *some* control over their taskbar presentation. I don't know if it is as flexible as Dock though. So Win7 may see more apps doing stuff like that in the taskbar instead of resorting to tray icons.
Yes, the fundamental philosophy each inherited is different, but in effect at the 'dock' or 'taskbar' representation, Windows 7 and OSX end up presenting things similarly.
He makes the point that the OSX dock is for applications and that Windows is for each window, though Microsoft is heavily encouraging grouping that makes it seem as much like the dock as possible. True, in Windows this can be turned off, but that doesn't do anything to disprove the intent is to acheive the model the Dock presents. He says that when you close the last application window, it dissapears from the taskbar. The issue there is it behaves the same on Windows 7 and OSX, if an application exits, then the dock icon or taskbar presennce will disappear unless persistantly set.
He mentions things like the presence of the notification area as proof of difference, but all it really proves is that MS had a few different design ideas as they went and they must support all of them as a consequence.
Just like WindowMaker largely deals with non-GNUstep applications and makes them seem NeXT like through some of the best window group identifying methods in an X system, Windows is trying to fight clutter by removing quicklaunch and taskbar redundancy, and enabling the taskbar presence to be manipulated to replace system tray presence.
Leave sprint and come back in later for the decent stuff. I.e. by mid year they are supposed to have a handful of android devices and of course the palm pre. Leaving sprint and going for a month-to-month prepaid carrier may be appealing.
That is Rabbi Daniel Lapin.
You may not hear it in your setup, but in my setup of hand-woven pure gold-plated copper wrapped in diamond-encrusted insulation, the artifacts of FLAC come through clearly.
I agree with the perspective on microblogging as athe only thing a site does. I just don't see the revenue stream in something like that inherently. I do see the alternative possibility that Twitter becomes a brand name and licenses their presence to be integrated in other sites. I think there will be a focus on bringing together currently disparate aspects of 'social networking' and revenue strategies to evolve. Currently, I don't think the revenue streams can stand on their own, but social networking is too ubiquitous and popular for *no one* to get a rational business plan going.
I think the outlook on targeted advertising is particular. The only aspect that is potentially interesting is that too much money went in and set impossible expectations. However, the quality of the advertising I think too significant to discount. Interactive, targeted advertising is something leaps and bounds over television. There are a few hotspots on television where almost everyone will see advertising, and some shows with such a narrow fanbase it actually turns out to be kind of targeted. However, the production cost to participate is non-trivial, and viewers have to take it upon themselves to write down details to research it later if they have never heard of the product. Also, the ubiquity of DVR reduces the exposure to ads.
The statement on social news had nothing to do with the value of social news sites, and everything to do with neglecting a business plan. This is no surprise.
On online video, they claim that other than YouTube and Hulu, little will be left. I would support the statement, with the note that Porn content sites will continue.
On online radio, I would be reluctant to say that's out, but again the focus is not inherent flaws, but rather the recording industries being resistant towards that model and making life hard intentionally. The recording indutry is ass-backwards enough to sink an industry that would be highly valuable to them.
MKV is a container format. It's not impossible for a container format to induce overhead, but in all likelihood that isn't the case.
The codec would be something like h264,xvid,indeo,theora,etc for video, aac, mp3,vorbis,wav,etc.
I don't know about Quicktime, but avi is horribly limited. Ogg seemed to have promise for a container format, but for whatever reason MKV came about with support for some killer features menus and vobsub format subtitle tracks. I have never seen an mkv with menu, but I have heard it exists.
It would be interesting to know the codecs involved.
I don't Vista was any cheaper for 32-bit edition.
My question is why they have to make it more confusing by bundling it separately. If they are striving to be an easy sort of experience, they should be able to have a unified media, perhaps with a special option to disable 64-bit even if possible at install time.
I also wonder why they don't have any strategy like Apple had for 'Universal Binaries'. I suppose they are at a disadvantage for not having a more comprehensive application directory strategy, which Apple easily made use of to get multi-architecture applications that looked like a single icon to the typical end-user.
I understand the need for 32-bit (many Atom, pre-core2 non-netburst Intel processors), but it wouldn't frustrate users and stall application developers so much if they had taken certain measures.
Wow... Just enough knowledge to be dangerous..
PAE is not a panacea. There is a performance penalty and it is a hackish way of solving the problem. As you acknowledge, it does not address the per-process limitations. With certain desktop appplications, notably more advanced games, I could see the per-process limit being hit, even if PAE gave you at least warm fuzzies about your apparent total memory. There is a reason why distributions provided PAE-disabled kernels in x86 world.
Though you mention buggy 32-bit code having problems in long mode, I have never seen that occur in Linux or Windows. In terms of 16-bit code, I was unaware of that, however considering the vintage of such code (i.e. Pentium 60 was last processor on the market before Win95 became essentially ubiquitous), I suspect a fully emulated environment is quite possible. I haven't run into 16-bit applications in an eternity though.
I will say that Linux and Windows don't provide a facility to make the situation trivial for application vendors. I'm not sure if Apple is going to do something for x86/x86_64 applications, but they certainly have proven a useful strategy in the PPC/x86 case of leveraging application directories and conventions to have 'Universal Binaries', along with convenient checks in their development tools to build such a thing. I don't use OSX as there is much I'm not crazy about, but they did an excellent job of enabling application vendors to support two very different platforms without putting too much burden on their build environment or the users.
MS is typically paranoid about really really old OSes, and uses a layout with a iso9660 visible file:
mount -t iso9660 -o loop 7000.0.081212-1400_client_en-us_Ultimate-GB1CULXFRE_EN_DVD.iso t
[root@localhost Download]# ls t
readme.txt
[root@localhost Download]# umount t
[root@localhost Download]# mount -t udf -o loop 7000.0.081212-1400_client_en-us_Ultimate-GB1CULXFRE_EN_DVD.iso t
[root@localhost Download]# ls t
autorun.inf bootmgr efi sources upgrade
boot bootmgr.efi setup.exe support
I got to a page that had a 'download now' button and a license key, and the download now button didn't work. (Using Firefox on Fedora 10 at the moment).
I did a view source, copied the url and pasted, it gave me some weird message on screen about IE and java, but the ISO started downloading anyway.
Is it really MFlop or GFlops? 78 GFlops may seem a tad high to me, but 78 MFlops is much lower than I would expect. A Core2 based quad core 3.0 ghz would get 48 GFlops theoretical peak double precision gflops...
The problem I had was that the VM console was not a convenient way to use apps, and 'remote' X and such performed noticeably worse than local due to the performance of the virtual network bridge and two IP stacks being significantly worse than a local Unix socket X usually uses.
chroot I did not advocate as security, so much as library isolation, so any funky library requirements are met. However, lxc is certainly more comprehensive for this sort of activity.
BTW, don't know why you would say anything special would have to be done for 32-bit in a 64-bit env. All the OSes in x86_64 and ppc64 support running 32 bit applications in 64-bit setups.
I know that is Verizon's price. I'm unsure about AT&T, but T-mobile's is a tad lower as is Sprint's. Sprint's is particularly interestingly low for shared plans relative to the rest. This of course makes sense, as at the moment Sprint is the most desperate as they have a lousy reputation and must take the most drastic action. I'm pretty sure that Verizon has the highest prices (excepting AT&T, who I've no looked up), and they also happened to have the largest market share.
In other words, things are shaping up pretty much as one would expect a competitive market to shape up, with the leaders enjoying the benefits of reputation. The fact that things are not more different as they are makes sense too. Competition should force competitor's to price equivalently. In the auto industry, a common 4-door sedan will run in the 15-20 thousand US dollar area, regardless of manufacturer. There are outliers, certainly, but the major auto makers tend to manage the same price points.
If I'm ever forced to deal with an issue like incompatible versions of glibc in the future, I could contain that; or if I want to try upgrading a piece of software, I can roll back to a snapshot or keep multiple copies of the virtual appliance around
Why not use chroot/jails/containers/etc? The multiple kernel instances serve only to add overhead (trust me, I did virtualization and it suffered signigifcant performance degradation within a host). The performance may have had more to do with VM-host networking speed, but I'm much happier with the latter.
If you had to bridge OS types, that is another matter, but the user experience per VM can not converge (Windows will have drive letters, other's won't, Applications won't transparently interleave, etc).
And then there is trying to be different for the sake of being different.
Too many people seem to think if it remotely resembles in some way technology they have already seen, it must be antiquated and stale. In the framework of being Unix-like, GNU and Linux can be found in consumer routers, high-end networking equipment, servers, cell-phones, DVRs, other set-top boxes, the list goes on. Each field with a highly customized and frequently innovative stack on top of familiar Unix-like concepts. Underneath it all, there exists a filesystem with same-old devnodes, with shell commands and a filesystem hierarchy that is familiar. To tinker with that just because the concepts are decades old would be akin to saying "hey, round wheels have been in use for centuries, let's put some triangular wheels in our next model to break out of that rut!". My experience suggests there aren't any particularly more compelling ideas at this level to date, and interesting concepts built upon these layers are not held back by any particular aspects of them. The only thing that change for the sake of being 'new' will do is make it hard to follow without sufficient benefit.
In your context, Xorg isn't the origin of your perceived troubles, the developers of applications on top of it are. I doubt you'd be satisfied with a one-app-at-a-time desktop environment, so you'd probably be hoping for someone else to port or create a desktop UI in the event of an Android push to the desktop, with no particular reason why it wouldn't come to the same results you don't like. Maybe you want to tinker with GNUstep, ROX, XFCE, or ratpoison, I'm not sure what you like and can't speak to your tastes. Though many of those may not be sufficient as it stands, but perhaps one jives with you and you'd contribute to advancing its state. There are no shortage of UI concepts to try without going down the Gnome/KDE path. A fleshed out GNUstep on top of Xorg, for example, could feel identical to OSX UI, despite being on top of the 'old and crufty, unix-like UI architecture'.
In terms of moving millions of units instead of hundred of thousands, that is precisely what Android is doing. Android is a purpose-build platform and is a very interesting platform for that market. In terms of displacing Microsoft on the desktop without migrating users from that form factor, Android won't do that. Users are, by and large, content with the paradigm that Apple, MS, and most Linux distributions provide. To ask them to radically change what they do will not win them over.
800x480 is still a lot of resolution compared to the G1. And an important difference here is that the netbook has a huge screen in physical size compared to a phone. It may have better aggregate resolution, but the DPI being horrible points to a different style of interaction.
A phone tends to have less resolution, but in an even tinier form factor. That means your applications are designed for a 3" display that happens to be pretty good in terms of DPI. If you had 2560x1600 on a 3" display, you still wouldn't stick gobs of windows and icons into it, you'd just have a really crisp small application.
The reality would be a netbook equipped with Android would be an oversized cell-phone. It wouldn't offer anything meaningfully advantageous over a cell phone (same apps, same amount of data, happens to be bigger), without the portability of the cell phone. If the netbook vision/market is one that resonates best with a UI like Android, then it is doomed to fade away immediately in the face of equivalent phones.
The thing about the multi-window paradigm is it gives the user the choice. As you say, you can just maximize anyway, and alt-tab or whatever to switch. The ability to operate otherwise may be ignored if you wish.
However, I make use of the screen real estate. When programming, I'll have documentation up concurrently. I don't have to ask the computer to switch contexts for me, I just look over. When doing some work, I may need to tail a log file so I'll notice and instantly process the data when it happens. Sometimes, I leave windows up, stuck to the workspace and on top to remind me that I need to get back to it as soon as it is ready for interaction while I move on. Very frequently, I arbitrarily need to link together two disparate parts of two applications due to a correlation between them neither developer would have intended. Often, I need a specific viewport and can disregard parts allowing me to achieve what I want through control of the overlap.
Microsofts remote desktop and NX and vnc lack one thing I'd like, application integration with my desktop. Meaning even the "tray" presence of an application melds with everything else. I know some hacks have applications interleaved in other windows, but to date remote applications with the exception of X do not manage to get into the same "tray" my local applications get into. I hear of a NX rootless mode, but I've never actually figured out how to try it. A rootless NX session with detach capabilities may be my holy grail, but the other solutions, as it stands, don't have the required visibility into the details to make it happen (correct me if I am wrong about RDP/Netmeeting).
Just as screen's existence does not obviate the need for ssh, NX's work complements X's architecture, it does replace it.
I agree with you that accommodating high-latency links and session management are two aspects the core Xorg server lacks, but the underlying technology is fundamentally amenable to achieve those ends through additions.
Finally, the question is what ends will be achieved by a replacement technology that Xorg has not achieved itself. I've seens hosts of projects come and go with the aim of implementing some featureset that X lacks, sometimes claiming it's not even possible to address the need through extending X. The problem is by the time they can get off the ground, Xorg has implemented an extension to accommodate the need.
You can change number of monitors spanned, resolution, orientatation. The only one that it may lack is changing color depth dynamically (not sure), but then again, people don't generally have reason to change that in X.
As much as so many people seem to hate X (many for no particularly well found technical reason I will add, some have technical justifications, but many just think it's 'old'), Android would not be an improvement in display or UI technology for desktop usage:
-No inherent remote display capabilities. X has this in it's very foundation. There was no reason for a cell-phone/embedded OS to implement such functionality in the contexts Android target, so this wasn't a bad decision.
-Multi-window operation. Again, the target is applications where the resolution, screen size, and interface methods do not lend themselves well for multiple windows. As such the paradigm is single application.
-Extending from the above, no advanced window management/compositing. The inter-application effects and utility with 3D acceleration found in Compiz, Aero, and Quartz have no reason to be there, despite providing productivity benefits (at least in the compiz and Quartz variants).
Do not get excited about the prospect of any arbitrary display technology displacing X, regardless of the underlying technical merits in the given context. Try to understand the hard technical reasons for your X hate, and do a bit of research to make sure they are not FUD or that the Xorg team isn't already addressing your concerns in a reasonable manner.
From what I've tried, Android is a great platform for the environment it targets. It achieves this by not trying to be a one-size fits all solution. Usage styles that work on the desktop do not scale to handheld devices. By the same token, good handheld UI does not scale to Desktop.
There were two parts, a presumably obvious warning, then braking. Presumably if attempting a lane change and a loud warning goes off, you stop changing lanes. Ditto for drowsy drifting.
And in your disabled car scenario, braking may reduce it from fatality to serious injury.
I think more sophisticated sensors that give off really annoying alerts to demand driver attention and action are required. Annoying so that people don't start banking on them too much. That is the chief danger, people stop bothering to check because a nice beep will let them know most of the time. If it is a grating alarm, they may be more reluctant..
I think there is a limit on the whole hardware/software roles heer, but:
-If not upgradeable, their original firmware may have been busted, and they would be SOL. Their original firmware happened to not have *this* problem likely out of luck rather than knowing.
-If no "software" (not plausible, but hypothetical), then same deal.
To an extent, "fix it in firmware" philosophy in the industry has influenced product release quality. I don't think a lack of testing has been pervasive, though, just shipping without addressing known problems. In this specific context, I doubt any test case they would nominally have would have caught this before ship, and thus the upgradeable firmware could be their hope of recovery (though it sounds that their may be no non-intrusive recovery procedure).
In terms of MS brand loyalty, I'm not sure what more they can do to customers that they haven't already done. xBox360 far outpace PS3 sales despite much criticism for failed units. Windows made it to XP despite giving the home user an incredibly unstable experience to that date. People swear by IE despite the fact it always trails other browsers in standards compliance and performance (not just the people too lazy to get something else, some people consciously choose it). I know people who chase Windows Mobile and use that variant of IE despite that variant of IE is even worse.
Given, these are a minority, most are at best indifferent to MS. They use MS because their needed apps are Windows-only, the vendors target Windows because the users aren't moving. MS revenue is pretty much rooted in that chicken and egg left over from the days where viable choice was limited. I see a lot more conscious avoidance of the Zune and WinMo devices, which I would like to attribute to recognition MS is too powerful to let it grow, yet the 360 is very successful. Maybe WinMo and Zune are just bad product and the consumers just don't care.
It's not a magical MD5 sum cracker, it's just a way of having an index of pre-computed strings that checksum to various values.
The only ubiquitous usage that is vulnerable to this attack is Microsoft SAM database. Many one-off applications similarly implement unsalted hashes. Unices salt passwords and are therefore not inclined to suffer. It doesn't matter the hashing algorithm in use, they are not particularly differently susceptible to this sort of attack. Note also that cracking the hashes in the SAM database is not even required, as NTLM has the client provide the pre-computed hash instead of password. It's really an extra-braindead architecture.