POSIX is most definitely not the be all end all of how a Unix system should act
While it does not encompass the entirety of a platform, it is *something* to keep in mind and implement, warning users when usage runs afowl of POSIX standards. I've seen in the community where they disagree with what POSIX prescribes, but implement it that way because adherence to standards is an important differentiator between the *nix world and certain other platforms...
And every time I need to do some quick math, do I have to write a script for it now? Because that's "all that matters"?
His point was that the output wouldn't screw up scripts. The implicit assumption is that someone isn't horribly bothered by the banner interactively. If it would bother you so much, aliasing bc to 'bc -q' would solve your nitpick, though it is not obvious to some people that the application started since it gives no prompt. I personally prefer python as a quick calculator myself anyway (except some base conversions which are quicker in bc to type)
That's almost funny. Pretty much the only thing a GNU man page has ever told anyone about anything, is that they should be using "info" instead, if they want to get ANY information on the program...
Usually, I do a man on a GNU utility and get a generally typical man page. It most likely contains the info I need, with a small 'see also' section that says to go to info for full documentation, which generally contains volumes of incredibly verbose documentation I would rarely need, moreso than any man page except maybe bash...
First, your last point about external drives for backup, there are two distinct points being met here.
A sane backup regiment is indeed key to protect against more catastrophic hardware and software problems. It's also a pain to have to resort to that. Most people that have a 'couple USBs' to handle backup don't implement proper backup procedures, and are not at significantly greater protection from hardware failure than the much-maligned RAID-5 configuration.
RAID-1 is expensive relative to 5 (commonly 2n storage to store n data), and in the common usage, a degraded config is equally at risk as RAID-5 (replace the failed drive, and if your RAID-5 rebuild would have failed because of long-untouched sectors being bad, the mirror rebuild would fail too). Yes, you can do more drives in RAID-1 (I actually do in some special cases), but most don't bother to go to that expense). RAID-6 is more reasonable, but the base problem of long-dead unknown sections is still present.
This is why most array set up nowadays do background consistency checks with idle IO time, to detect and rewrite failures on otherwise unmanipulated parts of the disks..
RAID is about zero-downtime error tolerance/recovery without significant hassle. It isn't capable of recovering from everything, but it is a *lot* better than having to go to your backup media. Combined with increasingly popular online snapshotting capability, and the hassle of going to backup to retrieve a file for hardware or software failure becomes a relative rarity.
Yes, AMD has been on socket AM2-like for a 'while' relative to intel, but not too long they were in socket 754 and 939. Before that, Socket A. Before that, Slot A. And the generation before that (which *finally* gets you in the ballpark that original article would be relative to now) was socket 7.
On Video card, it's getting harder to find a servicable AGP card. While AGP was starting to become popular in that time frame, they generally won't accept the cards today (keyed for different voltage).
HDD he'd probably be fine replacing, it's not hard to find 40-pin IDE drives that would work in the controller of something that old..
PSU you actually could be fine, Baby AT had only recently died out, so ATX has been ubiquitous since then.
Fans haven't changed in incompatible ways along the way.
So in short, processors, vid card, and memory are hard to chase down as their interfaces have been very different in incompatible ways over time. With this in mind, ensure your motherboard and video card require only passive cooling, and that your CPU cooler accept a standard (80 mm probably) fan.
In shorter, don't sweat it, make sure the hard drive storage is redundant, that a sane backup strategy is in place, and don't fear replacing the whole system if things go bad down the road. If third party software is involved, keep it safely archived.
But Cisco is trying to be a 'virtualization solution' company too. They have the networking reputation, Sun would flesh out the server rep, *and* Sun owns a Xen fork *and* Virtualbox.
The servers/workstations alone would be enough to make it a potentially wise decision for Cisco to pursue Sun, but with ownership over two virtualization technologies that are gaining mindshare against the high-cost VMWare, I would think that would cinch the deal for a company like Cisco.
3. The randr extention I thought had evolved to deal with this. The main problem I have is that things like the nvidia driver choose a proprietary way instead of implementing the standard. They co-opt the Windows stuff too, so linux is not alone on that. 4. I don't have that problem on sleep/resume, or any other laptop goodies...
Not so much yum/rpm fundamentally (there are a few tricks that yum can do over apt, and a few situations deb can represent that rpm cannot), so much as packaging decisions.
In RH world, you have either their quickly outdated 'enterprise' track, which they will not cede for free in any obvious fashion, though CentOS eventually fills that gap for RHEL content, or Fedora, which never ever seems to stabilize sufficiently and makes no particular effort to integrate well with non-free content.
Ubuntu has a more predictible cycle (i.e. Fedora plopped in KDE 4.2 months after 10 released, and Ubuntu would not) and a cleaner relationship between 'LTS' and normal (i.e. 8.4 is LTS for free and was the 'normal' distro as well, while RHEL5 was FC6, but not quite so simple). Ubuntu also seems to be more concerned about a tightly integrated experience.
The flip side is that I am stuck with fedora 10 now because Ubuntu 8.10 kernel has some issues with my hardware unlikely to be addressed until Jaunty...
I'm guessing that's a 4-socket box with 6 dimms per socket? I think the real metric for virtualization long term with respect to memory will be dimm slots per socket rather than aggregate per system.
6 per socket is a respectable number in the blade space, admittedly.
There is exceedingly fat margins in storage, *even* by cisco standards, and that's a high benchmark. The SAN market is a vendors dream, where nickel and diming every little feature and even every little port on every switch is the status quo, except the nickles and dimes are more like 5 and 10 thousand dollars.
As far as technical reasons, they are mostly not there. One exception is that Cisco is pushing to replace FC with Ethernet, presumably with the promise of an escape from the painful FC market practices. Though assuredly they will bring some of the market behaviors over, they will make it somewhat easier to make the sale. They tried to just release a product into that market against the likes of Brocade and QLogic, but I think Cisco has realized their only substantial chance to stay vital is to suck in storage infrastructure into their fabric they have some reputation in, ethernet.
People are already starting more and more to consider other vendors 'good enough' for traditional networking needs. Cisco wants to own the whole mess so that people will be more afraid to move off.
However, a *vendor* still can't afford to neglect MS, since so many customers have drunk the MS kool aid.
An individual organization can afford to ignore Windows much of the time. A company seeking to become more of a single source to as many people as possible can't afford to ignore MS or Linux, and even ignoring Solaris, AIX, and FreeBSD is dubious even for vendors that are not Sun or IBM.
I think both Dell and HP can sell a total solution with their badge throughout. Dell admittedly isn't much on 'total stack support', but HP certainly is in that game.
One could argue that the HP rebadged switches are not 'cisco'-good, but by the same token I'll wager the Cisco-servers aren't 'HP'-good.
Conspicuously absent from that game is of course IBM, which hasn't had it's name on a piece of non-blade networking equipment in a long time and after the whole Lenovo thing, really isn't in a position to offer single-vendor. Strange with so many companies eager to get that marketing bullet point, IBM runs screaming away from it.
I will say, in their defense, a pure Cisco network from a managability perspective is easy to look after compared to the alternatives. Cisco retains technical justification for their reputation.
But from what I've seen, their server technology appears relatively weak. I.e. their blades appear less dense than 1U servers. I'm not surprised though, in recent history even in their core competency of networking, density and performance have not been impressive compared to competition.
I think the same end could have been achieved by pulling together a partnership. Then again, they already have enough high-margin vendors in play to probably price this thing out there without pulling in yet another company that would insist on their slice.
I personally would have rather seen something a bit more fresh, like getting behind and committing to a technology like KVM instead of VMWare. I know, that would be marketing suicide, and I shouldn't be looking to the traditional powerhouses to snub VMWare yet with their current market position, but it would've been interesting.
I don't see tftp as ever having been an important part of the internet over long-haul connections. Tftp would have been what it was intended to be and is, a very straightforward protocol that can be implemented with incredibly tiny footprint with little risk of getting it wrong. Notably: -TCP is *much* better at reliable communication without penalty. TFTP is intentionally dumb, send a block, ack a block, send a block, ack a block. Again, easy to write, horrible performance. In TCP we have adjusting window sizes and partial acknowledgements and all sorts of features where acks are not required as often and data retransmit on fail is more granular. You can implement a UDP based protocol with some features, but it would no longer be remotely like tftp. -TFTP has a 16-bit block number field. That makes for some tiny filesizes unless you have ludicrous block size. If you have ludicrous block size, any single packet drop would require retransmit of the entire thing. This could have been increased, but not without breaking compatibility and effectively making a new protocol.
RHEL 5.3 still has tons more drivers than Win2k8. I know from very painful experience.
It's a natural consequence of a) as mentioned before, the nature of the licensing, but probably more importantly... b) the release cycle. RHEL is pretty good about timely major updates compared to eternities for MS service packs.
First, I will say I use antenna only for TV. My signal does break up from time to time because I have a crappy attenna and haven't bothered to correct. With the same setup, the analog channels go really bad before digital starts to break up. I will the point where digital starts breaking up it does so rapidly. It's a misnomer to say digital doesn't accomodate degraded signals at all, it's actually fairly resilient due to the error correction available in the stream. Added bonus of no DRM-like crap in the stream. Cable and Satellite vendors like to encrypt the traffic such that end-users can not use them as they see fit.
I will also say I use MythTV for DVR function. It's great, though I pay a small fee for TV listings, it's much cheaper by comparison and gets me most of the shows of interest. Even without listings, while playing most televisions can get some info out of the stream to tell you text about what is playing.
However, the general experience is still degraded for most. DVRs are by and large tied into Cable and Satellite providers (broadcast market considered too cheapass to deal with the headache of no obvious integrated listings mechanism). Some channels are not on broadcast and probably would never be. Particularly with the lack of any sort of DRM even attempted, many networks are off-put (despite the futility of the measures taken so far).
For the same reason it is a pain for commercial apps, it is a pain for OSS too. A disproportionate amount of effort in various projects is invested in spinning on API updates...
Most things have calmed down, but audio frameworks for some reason stay in a state of significant flux. Today's 'correct' API is pulseaudio, which will abstract the underlying mess, but who knows what tomorrow brings. I'm still haven't followed esd and arts lately to see if they have relevance. dmix and the like I bunch up in alsa which I think you don't touch directly as an app developer because a higher layer controls it...
When your workforce is faced with a lower sales volume, you either lay them off or invest for the rebound. If your R&D workforce was invested in short-term, incremental projects (accessories, product shrinks, etc), and your projections for market opportunity appear to be poor regardless of what you might do, it may make sense to start on long-term projects. Sure , you have some trying to do cost-savings to salvage margin on what you do sell or to reduce price to consumer, but it seems Sony's ability to pull that off is limited, and as such that only warrants a small investment.
That said, Sony is not an example of a company with the financial health to think that way, and as such layoffs are an unfortunately more plausible path.
I whole heartedly agree with most of your complaints, the crux being that MS purports to know what's good for your computer to the extent of overriding what you know in and of itself. MS should handle unsigned content better, one single warning when you install and an administrator to allow it. Of course, they are in this weird bastardized state of 'everyone is administrator' and 'noone is an administrator except microsoft'. Managing system startup aspects before any login would be the role of a administrator, but MS can't seem to nail that concept down.
Now for writes to Program Files, MS is in a tricky situation. Through your complaint about per-user views into that directory, I take it you are complaining about things that would be written to '/etc' rather than things that would be written to rc files in the home directory. I think the parent is thinking you mean the latter. The latter is by *far* the most common case of application developers, and thus MS has to do something to be able to run those applications yet not break separation of users to the extent they pull it off. It's not perfect, but MS is in a bind, many of the applications they need to support no longer have anyone who *could* update them to be better about file locations per user. MS has a large part of the blame due to recommendations made in Windows 95, however application developers would have done it despite any microsoft recommendations not to in Win9x world, which inherited security concerns from DOS which at its inception could not have been expected to meaningfully protect data (too expensive/complex to implement in the home desktop market at the time). Win95 could have been like 2k/XP, but some applications under DOS to this day require something like dosbox in 2k+, and that wouldn't have been feasible in 1995 either. As to files written to configure things, officially the 'registry' is where they are supposed to go. It's a horrible looking mess, but that is the paradigm MS chose and as such, Windows developers should not have much reason to store configuration in flat-files under Program Files. Of course, the ubiquity of 'ini' files goes against that too, so MS is just all clusterfuck.
Unix and Linux are thankfully spared a lot of this. Through being unforgiving out of the gate, they forced application developers to behave. They don't have to worry about legacy or about the degree to which someone is an administrator. That doesn't stop some vendors from being absolutely brain-dead (I've seen some clone their entire application on initial run to the users home directory), but at least you know what is what.
I mean, look at this. It's clearly Apple's IP. It's clearly a new invention.
Except for those pesky people who did it before dating back to 1984.
Seriously, Apple's patent is an instance of "something-already-done . . . on a phone!" As ridiculous as the large number of "on the internet" patents.
I do agree with you that the duration of phases of patents are fubar. For instance, the time between application and granting of a patent is absurdly long. This means a potential small business owner that wants more assurances than "patent pending" may avoid committing to that endeavor. Then after bing granted, there is a conundrum. For a product like the iPhone and generally large companies, the protection is much longer than required to let the originator benefit. On the other hand, for a small business, a three year term may not be enough for them to barely get off the ground.
That *even* if it is a 'business' person that has an idea, without available competent, perhaps desperate tech workers, the idea may not have the required resources to get it off the ground.
If the big companies never laid off, they'd retain all the talent and the industry would stagnate. I know if I make it through this economic situation and don't get laid off, I probably will not look for any other work or be the least bit receptive to all but the most unreasonable offers.
I happen to use Gnome day-to-day, but several projects deserve more attention for their implementation of alternative and interesting UI strategies.
GNUstep is at the top of my list. There was a lot that NeXT got right that didn't translate to the ultimate end-user experience in OSX. The implementation of services allowed a lot more unix-philosophy of small, special purpose applications able to intelligently communicate. I think OSX still has it, but the OSX developers shrug it off.
Another I have found interesting is the ROX desktop, inspired by Risc OS. They made a lot more interesting use of drag and drop, and fully embracing application directory packaging.
Slashdot Mirror
POSIX is most definitely not the be all end all of how a Unix system should act
While it does not encompass the entirety of a platform, it is *something* to keep in mind and implement, warning users when usage runs afowl of POSIX standards. I've seen in the community where they disagree with what POSIX prescribes, but implement it that way because adherence to standards is an important differentiator between the *nix world and certain other platforms...
And every time I need to do some quick math, do I have to write a script for it now? Because that's "all that matters"?
His point was that the output wouldn't screw up scripts. The implicit assumption is that someone isn't horribly bothered by the banner interactively. If it would bother you so much, aliasing bc to 'bc -q' would solve your nitpick, though it is not obvious to some people that the application started since it gives no prompt. I personally prefer python as a quick calculator myself anyway (except some base conversions which are quicker in bc to type)
That's almost funny. Pretty much the only thing a GNU man page has ever told anyone about anything, is that they should be using "info" instead, if they want to get ANY information on the program...
Usually, I do a man on a GNU utility and get a generally typical man page. It most likely contains the info I need, with a small 'see also' section that says to go to info for full documentation, which generally contains volumes of incredibly verbose documentation I would rarely need, moreso than any man page except maybe bash...
First, your last point about external drives for backup, there are two distinct points being met here.
A sane backup regiment is indeed key to protect against more catastrophic hardware and software problems. It's also a pain to have to resort to that. Most people that have a 'couple USBs' to handle backup don't implement proper backup procedures, and are not at significantly greater protection from hardware failure than the much-maligned RAID-5 configuration.
RAID-1 is expensive relative to 5 (commonly 2n storage to store n data), and in the common usage, a degraded config is equally at risk as RAID-5 (replace the failed drive, and if your RAID-5 rebuild would have failed because of long-untouched sectors being bad, the mirror rebuild would fail too). Yes, you can do more drives in RAID-1 (I actually do in some special cases), but most don't bother to go to that expense). RAID-6 is more reasonable, but the base problem of long-dead unknown sections is still present.
This is why most array set up nowadays do background consistency checks with idle IO time, to detect and rewrite failures on otherwise unmanipulated parts of the disks..
RAID is about zero-downtime error tolerance/recovery without significant hassle. It isn't capable of recovering from everything, but it is a *lot* better than having to go to your backup media. Combined with increasingly popular online snapshotting capability, and the hassle of going to backup to retrieve a file for hardware or software failure becomes a relative rarity.
Yes, AMD has been on socket AM2-like for a 'while' relative to intel, but not too long they were in socket 754 and 939. Before that, Socket A. Before that, Slot A. And the generation before that (which *finally* gets you in the ballpark that original article would be relative to now) was socket 7.
On Video card, it's getting harder to find a servicable AGP card. While AGP was starting to become popular in that time frame, they generally won't accept the cards today (keyed for different voltage).
HDD he'd probably be fine replacing, it's not hard to find 40-pin IDE drives that would work in the controller of something that old..
PSU you actually could be fine, Baby AT had only recently died out, so ATX has been ubiquitous since then.
Fans haven't changed in incompatible ways along the way.
So in short, processors, vid card, and memory are hard to chase down as their interfaces have been very different in incompatible ways over time. With this in mind, ensure your motherboard and video card require only passive cooling, and that your CPU cooler accept a standard (80 mm probably) fan.
In shorter, don't sweat it, make sure the hard drive storage is redundant, that a sane backup strategy is in place, and don't fear replacing the whole system if things go bad down the road. If third party software is involved, keep it safely archived.
But Cisco is trying to be a 'virtualization solution' company too. They have the networking reputation, Sun would flesh out the server rep, *and* Sun owns a Xen fork *and* Virtualbox.
The servers/workstations alone would be enough to make it a potentially wise decision for Cisco to pursue Sun, but with ownership over two virtualization technologies that are gaining mindshare against the high-cost VMWare, I would think that would cinch the deal for a company like Cisco.
slashdot is in obvious need of DLC..
(but mostly I'm just getting an acheivement).
Slashdot jokingly stumbles upon the next big thing in social networking websites...
1 & 2, yes the keyword there is 'legally'.
3. The randr extention I thought had evolved to deal with this. The main problem I have is that things like the nvidia driver choose a proprietary way instead of implementing the standard. They co-opt the Windows stuff too, so linux is not alone on that.
4. I don't have that problem on sleep/resume, or any other laptop goodies...
Not so much yum/rpm fundamentally (there are a few tricks that yum can do over apt, and a few situations deb can represent that rpm cannot), so much as packaging decisions.
In RH world, you have either their quickly outdated 'enterprise' track, which they will not cede for free in any obvious fashion, though CentOS eventually fills that gap for RHEL content, or Fedora, which never ever seems to stabilize sufficiently and makes no particular effort to integrate well with non-free content.
Ubuntu has a more predictible cycle (i.e. Fedora plopped in KDE 4.2 months after 10 released, and Ubuntu would not) and a cleaner relationship between 'LTS' and normal (i.e. 8.4 is LTS for free and was the 'normal' distro as well, while RHEL5 was FC6, but not quite so simple). Ubuntu also seems to be more concerned about a tightly integrated experience.
The flip side is that I am stuck with fedora 10 now because Ubuntu 8.10 kernel has some issues with my hardware unlikely to be addressed until Jaunty...
Of the IBM solution.
I'm guessing that's a 4-socket box with 6 dimms per socket? I think the real metric for virtualization long term with respect to memory will be dimm slots per socket rather than aggregate per system.
6 per socket is a respectable number in the blade space, admittedly.
You are right, my mistake
There is exceedingly fat margins in storage, *even* by cisco standards, and that's a high benchmark. The SAN market is a vendors dream, where nickel and diming every little feature and even every little port on every switch is the status quo, except the nickles and dimes are more like 5 and 10 thousand dollars.
As far as technical reasons, they are mostly not there. One exception is that Cisco is pushing to replace FC with Ethernet, presumably with the promise of an escape from the painful FC market practices. Though assuredly they will bring some of the market behaviors over, they will make it somewhat easier to make the sale. They tried to just release a product into that market against the likes of Brocade and QLogic, but I think Cisco has realized their only substantial chance to stay vital is to suck in storage infrastructure into their fabric they have some reputation in, ethernet.
People are already starting more and more to consider other vendors 'good enough' for traditional networking needs. Cisco wants to own the whole mess so that people will be more afraid to move off.
However, a *vendor* still can't afford to neglect MS, since so many customers have drunk the MS kool aid.
An individual organization can afford to ignore Windows much of the time. A company seeking to become more of a single source to as many people as possible can't afford to ignore MS or Linux, and even ignoring Solaris, AIX, and FreeBSD is dubious even for vendors that are not Sun or IBM.
I think both Dell and HP can sell a total solution with their badge throughout. Dell admittedly isn't much on 'total stack support', but HP certainly is in that game.
One could argue that the HP rebadged switches are not 'cisco'-good, but by the same token I'll wager the Cisco-servers aren't 'HP'-good.
Conspicuously absent from that game is of course IBM, which hasn't had it's name on a piece of non-blade networking equipment in a long time and after the whole Lenovo thing, really isn't in a position to offer single-vendor. Strange with so many companies eager to get that marketing bullet point, IBM runs screaming away from it.
I will say, in their defense, a pure Cisco network from a managability perspective is easy to look after compared to the alternatives. Cisco retains technical justification for their reputation.
But from what I've seen, their server technology appears relatively weak. I.e. their blades appear less dense than 1U servers. I'm not surprised though, in recent history even in their core competency of networking, density and performance have not been impressive compared to competition.
I think the same end could have been achieved by pulling together a partnership. Then again, they already have enough high-margin vendors in play to probably price this thing out there without pulling in yet another company that would insist on their slice.
I personally would have rather seen something a bit more fresh, like getting behind and committing to a technology like KVM instead of VMWare. I know, that would be marketing suicide, and I shouldn't be looking to the traditional powerhouses to snub VMWare yet with their current market position, but it would've been interesting.
For patents, no, I believe a patent holder is free to ignore 'infringement' at their option.
I don't see tftp as ever having been an important part of the internet over long-haul connections. Tftp would have been what it was intended to be and is, a very straightforward protocol that can be implemented with incredibly tiny footprint with little risk of getting it wrong. Notably:
-TCP is *much* better at reliable communication without penalty. TFTP is intentionally dumb, send a block, ack a block, send a block, ack a block. Again, easy to write, horrible performance. In TCP we have adjusting window sizes and partial acknowledgements and all sorts of features where acks are not required as often and data retransmit on fail is more granular. You can implement a UDP based protocol with some features, but it would no longer be remotely like tftp.
-TFTP has a 16-bit block number field. That makes for some tiny filesizes unless you have ludicrous block size. If you have ludicrous block size, any single packet drop would require retransmit of the entire thing. This could have been increased, but not without breaking compatibility and effectively making a new protocol.
RHEL 5.3 still has tons more drivers than Win2k8. I know from very painful experience.
It's a natural consequence of
a) as mentioned before, the nature of the licensing, but probably more importantly...
b) the release cycle. RHEL is pretty good about timely major updates compared to eternities for MS service packs.
First, I will say I use antenna only for TV. My signal does break up from time to time because I have a crappy attenna and haven't bothered to correct. With the same setup, the analog channels go really bad before digital starts to break up. I will the point where digital starts breaking up it does so rapidly. It's a misnomer to say digital doesn't accomodate degraded signals at all, it's actually fairly resilient due to the error correction available in the stream. Added bonus of no DRM-like crap in the stream. Cable and Satellite vendors like to encrypt the traffic such that end-users can not use them as they see fit.
I will also say I use MythTV for DVR function. It's great, though I pay a small fee for TV listings, it's much cheaper by comparison and gets me most of the shows of interest. Even without listings, while playing most televisions can get some info out of the stream to tell you text about what is playing.
However, the general experience is still degraded for most. DVRs are by and large tied into Cable and Satellite providers (broadcast market considered too cheapass to deal with the headache of no obvious integrated listings mechanism). Some channels are not on broadcast and probably would never be. Particularly with the lack of any sort of DRM even attempted, many networks are off-put (despite the futility of the measures taken so far).
For the same reason it is a pain for commercial apps, it is a pain for OSS too. A disproportionate amount of effort in various projects is invested in spinning on API updates...
Most things have calmed down, but audio frameworks for some reason stay in a state of significant flux. Today's 'correct' API is pulseaudio, which will abstract the underlying mess, but who knows what tomorrow brings. I'm still haven't followed esd and arts lately to see if they have relevance. dmix and the like I bunch up in alsa which I think you don't touch directly as an app developer because a higher layer controls it...
When your workforce is faced with a lower sales volume, you either lay them off or invest for the rebound. If your R&D workforce was invested in short-term, incremental projects (accessories, product shrinks, etc), and your projections for market opportunity appear to be poor regardless of what you might do, it may make sense to start on long-term projects. Sure , you have some trying to do cost-savings to salvage margin on what you do sell or to reduce price to consumer, but it seems Sony's ability to pull that off is limited, and as such that only warrants a small investment.
That said, Sony is not an example of a company with the financial health to think that way, and as such layoffs are an unfortunately more plausible path.
I whole heartedly agree with most of your complaints, the crux being that MS purports to know what's good for your computer to the extent of overriding what you know in and of itself. MS should handle unsigned content better, one single warning when you install and an administrator to allow it. Of course, they are in this weird bastardized state of 'everyone is administrator' and 'noone is an administrator except microsoft'. Managing system startup aspects before any login would be the role of a administrator, but MS can't seem to nail that concept down.
Now for writes to Program Files, MS is in a tricky situation. Through your complaint about per-user views into that directory, I take it you are complaining about things that would be written to '/etc' rather than things that would be written to rc files in the home directory. I think the parent is thinking you mean the latter. The latter is by *far* the most common case of application developers, and thus MS has to do something to be able to run those applications yet not break separation of users to the extent they pull it off. It's not perfect, but MS is in a bind, many of the applications they need to support no longer have anyone who *could* update them to be better about file locations per user. MS has a large part of the blame due to recommendations made in Windows 95, however application developers would have done it despite any microsoft recommendations not to in Win9x world, which inherited security concerns from DOS which at its inception could not have been expected to meaningfully protect data (too expensive/complex to implement in the home desktop market at the time). Win95 could have been like 2k/XP, but some applications under DOS to this day require something like dosbox in 2k+, and that wouldn't have been feasible in 1995 either. As to files written to configure things, officially the 'registry' is where they are supposed to go. It's a horrible looking mess, but that is the paradigm MS chose and as such, Windows developers should not have much reason to store configuration in flat-files under Program Files. Of course, the ubiquity of 'ini' files goes against that too, so MS is just all clusterfuck.
Unix and Linux are thankfully spared a lot of this. Through being unforgiving out of the gate, they forced application developers to behave. They don't have to worry about legacy or about the degree to which someone is an administrator. That doesn't stop some vendors from being absolutely brain-dead (I've seen some clone their entire application on initial run to the users home directory), but at least you know what is what.
I mean, look at this. It's clearly Apple's IP. It's clearly a new invention.
Except for those pesky people who did it before dating back to 1984.
Seriously, Apple's patent is an instance of "something-already-done . . . on a phone!" As ridiculous as the large number of "on the internet" patents.
I do agree with you that the duration of phases of patents are fubar. For instance, the time between application and granting of a patent is absurdly long. This means a potential small business owner that wants more assurances than "patent pending" may avoid committing to that endeavor. Then after bing granted, there is a conundrum. For a product like the iPhone and generally large companies, the protection is much longer than required to let the originator benefit. On the other hand, for a small business, a three year term may not be enough for them to barely get off the ground.
That *even* if it is a 'business' person that has an idea, without available competent, perhaps desperate tech workers, the idea may not have the required resources to get it off the ground.
If the big companies never laid off, they'd retain all the talent and the industry would stagnate. I know if I make it through this economic situation and don't get laid off, I probably will not look for any other work or be the least bit receptive to all but the most unreasonable offers.
I happen to use Gnome day-to-day, but several projects deserve more attention for their implementation of alternative and interesting UI strategies.
GNUstep is at the top of my list. There was a lot that NeXT got right that didn't translate to the ultimate end-user experience in OSX. The implementation of services allowed a lot more unix-philosophy of small, special purpose applications able to intelligently communicate. I think OSX still has it, but the OSX developers shrug it off.
Another I have found interesting is the ROX desktop, inspired by Risc OS. They made a lot more interesting use of drag and drop, and fully embracing application directory packaging.