I think whatever it takes, MS will render the cost moot in this case to stave off such a scarily wide linux adoption. They must be aware that there is next to zero revenue opportunity to be had here, but they must subvert any potentially successful project that is explicitly a home user targetted product that is tied to Linux (i.e. eeepc). So I suspect the cost here would be either zero or a token low amount, but somehow it will be highly restricted.
In some ways, I believe XO aims to help countries without a significantly established computing market get one going. With this is mind, I do think inviting Microsoft and Adobe in as they are may be a mistake. If it acheives the success they plan, then establishing a market that is inherently set up for competitiveness would be ideal. With Linux, it's an open platform with a number of commercial companies packaging it up and selling the support. People are free to jump vendors when they demonstrate a lack of relevant vision (for me, Ubuntu's vision and execution came at a time when RH/Fedora's stopped matching mine, and I changed). With Flash, Adobe has a stranglehold on a significant portion of the platform the web runs on. By giving away the end-user portion for free, porting it to the three major OS players on x86, and in general not being intolerably bad given the scope, people complain less. However the fact remains there is not a competitive market without a standard to follow. Adobe has a stranglehold on the content creation piece which they make lucrative. If the OLPC project hopes to allow their target market to create as well as consume, then using Adobe flash could be a bad move. Of course, on a more realistic front, if OLPC doesn't become so big it can change the world, they would be left out in the cold, so I suppose it depends on how optimistic OLPC is about its success.
I'm not quite an open source fanatic, it's just that I see the software market today as very wrong relative to other markets from a business perspective. There are a number of compatible processor, video card, motherboard, chipset, etc vendors, and I'm not stuck to any one of them. When I go to buy a part for my car, there are inevitably a number of companies providing that part. When I buy a Ford, I don't have anything to lose when buying a Toyota, I'll still be able to drive all the same roads. No matter whose television I buy, I can watch the same shows. Nothing short of a platform like Linux with its business setup the way it is I see as a realistic path to getting out of the peculiarity of this market. Asking software developers to port to different APIs won't happen, it must be a number of OS providers implementing the same API that provides the basis of an open market. Unix might have provided a suitable ecosystem if Solaris, AIX, HP-UX, etc etc had targetted the desktop segment at the appropriate time, but they did not, and now Linux/x86 is probably the only market that has a chance to be ubiquitous (sad in a way since processor architecture lockdown is implicit, but at least there are multiple companies implementing x86)
$60 billion in annual revenues to software companies They limited the scope. This may be still arguable, but by limiting the scope of discussed impact, the flow of the revenue to other companies outside that scope can be ignored getting out of having the broken window argument apply to his statement.
The report was targeted toward the software industry. I'm wagering the report in general is a warning of what software companies need to prepare for, rather than an attempt to stop it. Any attempt to even basically understand the pervasiveness of open source software would lead someone to know the software development industry can't do something to stop it. There are definitely alarmist words used in the subject, but 'disruptive' has a particular connotation to it that is not positive or negative with this sort of analyst. Cars were a disruptive technology, for example. Disrputive simply means the industry is being transformed and business's catering to the needs being fulfilled by open source software need to adjust the scale of resources used in those endeavors. If not wanting to scale down, they have to figure out how to get the revenue in different ways. Before cars, there was a much higher demand for horeshoes. As cars came to dominate, there remained a market for horseshoes, but a lot of the market evaporated and they either had to focus on other metalworking markets (cars being a huge metalworking market) or leave the market. Either way, they had to retrain and move on, but analysts wouldn't say that cars were a bad thing, just a very different thing.
No, it isn't a robust scalable solution. To play nice with various standards and keep a given communication stream coherent, it has transmit hashes that pick the port to use based on packet criteria. If it tries to use criteria that would actually make the most level use of all member links, it would violate the aforementioned continuity criteria. I have seen all kinds of interesting behavior depending on the hashing algorithm employed. I have seen a place buy 500 servers from one vendor and have a 2 port aggregation to somewhere. The problem being, that vendor had all even mac addresses on the first ethernet port, and so one of the ports got to be virtually unused because it was a hash of the mac addresses mod the number of member ports. Since there were two ports, it was mod two and all evens went on one port, and only odds would have been the other.
I will say I agree with you on the message passing situation, it doesn't seem to be a significant penalty (I can still get Windows or better frames per second in 3d games, for example).
We have that already. It's called GTK+ or Qt or WxWidgets. Why should they be directly in X? While I in part agree with your sentiment, I will say that richer X primitives would mean better default remote performance. Instead of 'here are *all* of the x primitives required to draw a GTK button with the word Cancel on it', which is a not insignificant number, it could say 'draw Cancel button' and cut down on network performance requirements for good remote X. Keeping to a cross-platform API, but with the X implementations of the backend implemented as X extensions may have some value in remote usage scenarios.
I also agree with you on the sentiment of xdnd and cut and paste. As a user, I'm not seeing the problem. The only user issue I see is that the middle click paste sometimes confuses people, but I'd hate to see that go away. Nothing about that could be called an issue with the architecture regardless of the opinion.
X gets a lot of power from having abstractions that can be remote agnostic. I think the implementations have done a sufficient job of providing short-path optimizations for the local case without sacrificing the fundamental remote functionality. I think X's task of taking the network architecture and doing it locally fast has produced a smoother experience than the platforms that have had to do the opposite, and try to make their GUI cleanly remotely usable.
Sigh, RISC as a platform strategy is not dead. PA-RISC, yes, it was abandoned in favor of Itanium, but Power, SPARC, MIPS,and ARM continue. Apple is not *the* benchmark of relevant technology, despite what they would like everyone to believe. And if you do need Apple to use something to consider it relevant, look at Apple's ARM platform iPods and iPhone.
And, more to the point, there is no relevance to security in talking about PA-RISC, or any instruction set at all. Once you hop OS, you no longer readily run Windows-compiled code anyway. Malware is just as likely to call upon a scripting interpreter as being compiled (in this day and age, most take advantage of scripting features of browsers or some other facility anyway.
In terms of Linux v. OpenBSD on the antivirus front, it doesn't really matter. The same antivirus my company forces upon my linux workstation is avalable for OpenBSD as well: http://www.f-prot.com/news/gen_news/080225_bsdrelease.html
I'm a linux user for various reasons, but claiming that a linux platform is better than OpenBSD for complying with both the spirit and letter of this policy is silly. Both platforms have the tools that fit the description, and OpenBSD is far less likely from a philosophical perspective to give up security for convenience. Many Linux distros will embrace a new strategy before the security implications are thoroughly worked out for the sake of a feature, while OpenBSD will wait. Though not popular anymore, I remember when a handful of linux distributions had only the 'root' login, because they thought it was easy and didn't want to burden users with privilege escalation, as an example.
In any event, if the nature of the breach is obviously in no way related to compromising a computer system and rather is a more traditional way, than I doubt the bank would try to make a claim of relevance.
I use linux very extensively and find a number of niceties (compiz has far more practical features than Vista and OSX, and a number of general benefits of running a platform that is comprised entirely of things I can examine transparently myself but also is a healthy competitive landscape from the commercial vendor perspective). Making the hardware consist of interchangeable commodity parts has done wonders for the pricing of components, and the similar phenomenon is even more pronounced in software. Every user including gamers should appreciate what that means. Especially as MS increasingly treats the customers as the enemy (embracing DRM, increasingly bold 'anti-piracy' measures).
That said there are certain approaches: -Ignore Linux and gaming. The highly immediately pragmatic stand, probably what you would justify. The question here becomes are you forced up the upgrade trail by Vista? A weaker, yet not currently aggravating stance is to at least boycott Vista and tell microsoft you won't pay, and by extension boycotting games if they make DirectX 10 a requirement, hardware if they fail to provide XP drivers, etc.
-Use Linux and cave if Wine will run the game. Wine runs a surprisingly large number of games (Orange Box a popular example). This, of course, doesn't necessarily send the desired message, but it goes a ways. I have seen software patches and graphics drivers note Wine-specific issues, so some developers are seeing Wine as a valid demographic to target given the effort. This requires being vocal about your mode of usage, or else face game patches screwing up your experience by making Wine-incompatible design choices.
-Use Linux and refuse to buy any non-native games. There are some publishers that released native games. NeverWinter Nights (but not 2), id games, Savage 2. Reward them for publishing quality games for your platform, while being vocal about refusal to buy other titles. There are some decent Free games too, I was surprised how decent Nexuiz was (though I confess the artwork isn't as nice as other games, but the engine seems pretty good at its core).
I'm a hybrid of sorts. I'll check out a demo under wine if the game is overwhelmingly interesting (i.e. orange box) to see if I want it and would risk it, but will be much much more likely to buy a random game with a native linux binary. A lot of my gaming is reserved for console games, but FPS and RTS and the like I feel no console has an adequate interface (though metroid prime on wii was not too shabby). BTW, server-only binaries on linux aren't enough for me. I know it seems like being partly evangelical, but the reality is I want more out of my core platform experience and don't want to be beholden to a single corporate entity. The PC architecture is great for that, with multiple compatible vendors for practically every part except the OS platform, so long as MS is the dominant vendor. Making moves to change that is a good thing for consumers.
Sure, they may well not really want to help the Firefox or Open Office teams much, but if it's a choice between "PHP on Windows" or "PHP on Linux" I think it's obvious where Microsoft's interests lie. Of course, their interests lie in.Net on IIS on Windows, duh.
The difference being, OSX offered something intrinsically leaps and bounds better than their predecessor *and* Apple is a smaller software market anyway. It's easier to move a small, homogenous market to a new platform (the number of 'important' apps is small and were quickly ported). The market of people sticking with OS classic is uselessly small, so no one cared much about keeping them up to date. At the time of OSX, something with the sophistication of Unix marketed to the home user in a sane fashion was unprecedented. XP came out later based on the NT line and Linux was at the time hardly in a position to be that usable for the demographic in question.
Now Windows 7 is coming from a company that has not displayed itself as capable of meaningful innovation at the core of the platform for a while now. They promise doing things 'different' and claim it will be 'better', but they had the same thoughts and promises regarding a lot of the aspects of Vista that blew up in their face. They *thought* file copying would be faster, and quite the opposite happened because they mischaracterized a rare corner-case as being overly important. They again with Windows 7 claim multithreading will be faster, because they ditch ring 0 stuff, but who knows what the state of new hardware will bring to make perceived benefit evaporate and who knows what pain will happen. Will Windows 7 be any better than XP/Vista for the end-user, probably not. Will a compatibility layer be glitchy, with their history, probably so. Will Wine at that point be solid enough for most people to make the Linux platform of the day roughly comparable with Windows 7? Possibly.
Hardware vendors should want Linux (making a commodity of the software stack means healthier margins), businesses should want Linux (a level playing field means your software vendor can't aggravate you even a little bit without reprisal, MS can piss off customers and not sweat it). Software development companies should like Linux, they can't ask for a more transparent set of APIs. Home users probably in general don't care, except for the market of ~100 dollar systems that are made possible by lack of MS tax. It seems the market is ripe to take a big 'screw you' like this and jump ship given the frustration anyway..
RS232 is 'good enough' for text and therefore has remained the console of choice in the datacenter for many servers and any remotely serious networking equipment.
Any decent admin has to have at least a half-dozen serial cables and adapters to plug from arbitrary DB9, RJ45, RJ11, Mini-USB, and who knows what else form factors carrying nothing more than the RS232 signals in various random pinouts. Yes, I've even seen a USB form-factor that wasn't used for USB signalling.
It's a matter of tradeoffs generally. Take even a modern Linux distribution, with full default desktop, and try to run it on a system from 1998 (approximate 200 mhz, 32 MB of ram). I'd wager the live desktop that Ubuntu uses for install wouldn't even work. Sure, you can use alternate install and select packages enough so you just have blackbox and basic apps, but the overall experience won't be appreciably better than linux distributions of 10 years ago. I remember back in 1999-2000 the enlightenment people doing efm with some of the 'neat' effects that recommended at least a PII-400 or so, and people were up in arms. Now effects of those class are commonplace. In any event, as hardware advances, software gets to try things that they couldn't do before. Full-text search becomes more ubiquitous as disk space and io capacity allow for storing and reasonable maintenance of an index, as memory increases, applications use more to be more responsive live, as the number of applications a general system can run increases, so does typical usage and process schedulers change to accomodate that, the overhead of Virtualization is now considered reasonable, and the list goes on.
My problem with Vista is it seems to have little actual substance to justify the increase. MS jumped the shark as of Windows 2000. 2000 was followed by ME, and then XP. XP wasn't too horribly bad ultimately, but to this day I don't see the justification of it as a platform over 2000 other than the artificial support/maintenance drop of 2000. It feels like a forced update from MS. It wasn't significantly different under the covers, it pretty much acted like Win2000 with a goofy default theme. Now comes Vista, with mind-numbingly bad behavior with little payoff. The whole networking/audio interaction is a ludicrous hack, and shouldn't be remotely necessary on any decent kernel with sane scheduling. They moved 'direct'sound to userspace and suddenly this occurs. The file copy, despite all the apologists pointing to a MS guy explaining *why* file copies were so bad, is a horrible thing to have to explain away. Sure, XP fibbed a bit and that should be corrected (never should have been that way in the first place), but MS's pursuit of a 'fix' was so convoluted that it bit them in the ass. They say 'file copying is harder than you think', but a lot of the difficulty from that article seemed self-imposed.
I focus on those two points because it indicates how sloppy MS's approach to the core bits of the OS is, while they try to justify the value through a new theme and shiny, useless visual effects (Apple's expose is useful, and compiz under linux provides a number of useful mechanisms that take advantage of the power of windows as textures, Vista on the other hand...).
1) I prefer the userland approach of PreLaunch. A couple of fatal problems with a pre-load of my 'entire' disk are the fact that my memory is limited relative to disk space, and even it if weren't, I'd probably start trying to use my system so soon after boot up, that it probably wouldn't have cached the data I wanted yet anyway. PreLaunch attempts to identify and prioritize (my understanding) what gets loaded, so that the first stuff to the disk cache is the most likely to be used.
2 & 3 make some degree of sense, but I wouldn't choose that tradeoff. Particularly as SSD technology improves and ultimately may render the point nearly moot (latencies will drop to a reasonable amount, not probably within an order of magnituted of system memory, but tons closer than spinning disks, and close enough that I would guess such esoteric measures as this extend beyond the point of diminishing returns.).
The analysis thankfully makes a comparison to the IO caching that happens nominally. The distinction seems to be that this 'innovation' makes calling 'sync' a lie. That just doesn't seem like a good thing. It seems a roundabout way to make sync a lie as well.
I put in 16 GB of ram in a system, and operations are quite snappy, the disk cache happily filling and draining, and it feels more or less like a ramdisk system, once the data has been read into memory the first time on read operations. Sure, sync takes an ungodly amount of time, but that only happens when something wants to make damn sure the system is ready to tolerate an unfortunate event after something important happens.
I'll put aside the inaccuracy of 'the SSL port', and assume you meant http SSL and/or imap SSL, etc. This I cannot think of a defense for.
In terms of third-party applications, they do have good reason for blocking software. Namely, most all users are in the mindset of 'hey, it's free', without reviewing the details of the licensing. At my work, lawyers review licenses of popular 'freeware' and often reject it due to legal liabilities. One *extremely* common thread is that all this 'free' software is 'free (for non-commercial use)'. Particularly among Windows closed-source freeware, the software is intended to genuinely aid and/or advertise to the home user and recover the costs through commercial usage. These vendors love their ubiquitous home product driving people to defy policy and in the end, often the company buys a large license rather than fight the tide. My experience is that companies have an existing contract to cover that type of application, but they have chosen one that has fallen behind the curve in competitiveness, so users are frustrated. Said company doesn't want to jump ship (costly and annoying to users) unless it's overwhelmingly clear that the fundamental functionality of their chosen product can't do the job anymore. The problem is, despite being annoying, sluggish, etc, generally underneath it still gets the same job done, just more annoying to users.
It seems to be more about torturing a developer to force them to know how to write scalable/portable applications than being an actual practical platform. Sure, 72 cores sounds cool, but being a merely respectible 72 gigaflops (each core is simply a gigaflop) it's bested by a dual-socket Core 2 based workstation with quad core 2.33 in each socket. Practically speaking, many cores is helpful, but the same amount of performance in fewer cores is more flexible. It is a bicycle with training wheels for developers to know the scaling weaknesses of their algorithms without having to piss away time on an expensive scale-out cluster.
Availability in many of the supercomputer deployments is measured in percentage of the participating servers that stay up, not by continuous uptime. Applications may be killed off, but the job scheduler restarts them either from the beggining or a checkpoint. In the end, an application has executed a clean run, but instances of that application might have died a horrible death along the way. For the sake of cost, supercomputing has been in the business of migrating redundancy up toward tolerant software rather than having expensive, relatively low volume redundant hardware designs.
One *could* implement that sort of strategy with a single system. Imagine every thing that you executed and cared about was submitted through anacron and anacron wouldn't give up until the program exited successfully. Yanking the system and restarting it would redo the application from the beginning, like supercomputing clusters. The granularity is so coarse you can't help but to notice, but at the core it wouldn't be much different from a server going down among the sea of systems that is a supercomputing cluster. Jobs on a supercomputing cluster are rarely directly interactive, so this sort of jerky behavior will go unnoticed, but if your webbrowser randomly disappeared and then reappeared, it would be jarring.
This is a high-end dual socket box that incorporates cooling that is probably quieter than equivalent air cooling. It has nothing to do with the visions of 'supercomputer' and the word supercomputer itself is always a relative term. In 1993, the top supercomputer had 60 gigaflops, with a theoretical of 131 gigaflops. This system has a theoretical of 102 gigaflops and probably can get 80-85 gigaflops measured, so it would manage to beat the number 1 supercomputer of 15 years ago.
Nowadays, the most recent list has the #500 supercomputer at nearly 6 teraflops (rpeak of 10 teraflops). Or, to quantify, the lowest of the top 500 is still 100 times more powerful than one of these boxes.
Supercomputer in your palm, supercomputer in the desk, as long as you get to pick the year by which you declare what a 'supercomputer' is, you can declare whatever you want.
Others have mentioned the accounting thing, I think that's a very good example, it's much easier to track what is going on when a definitive DHCPDISCOVER transaction appears. One could make the argument for DNS update requests to be a good indicator, but that's not nearly as to the point and not required to occur.
On a more purely technical note, how do I tell server176 boot firmware that it should be loading file 'deployimg.176', while telling server12 to be loading 'recordimg.5', or whatever? How do I tell one set of servers in a network to tftp from one server, while others in the same network to tftp from a different one? The problem with zeroconf/multicast dns as the answer to everything is that assumes quite a homogeneous network that is symmetric, and many many useful examples exist that would not be accommodated without something like DHCP that centrally deals with it. Could it be possible to make multicast dns solutions that are torturously convoluted to provide the flexibility, sure, but what did you gain from simply moving the problem from sets of established codebases to a different set of codebases?
But ultimately, the question is, what's the harm of DHCPv6? I don't see multicast DNS+routing advertisement daemons as *really* any less infrastructure to set up. An administrator simply *has* to make the basic data available one way or another. People down on DHCPv6 haven't convinced me why setting up radvd and the other stuff is really better than DHCP. DHCP only was a pain when you chose to micromange (which is merely optional, can opt not to do it if radvd would have been enough), and when having to deal with frustratingly small pool allocations (inherently rendered a moot point by the IPv6 address space).
First off, since when is a 'URL' considered a transport mechanism rather than syntax for specifying a transport mechanism and location? Is ftp://whatever.example.com/badcode/ not a URL because it's ftp now? That's a goofy statement.
And then, this isn't about ftp being hacked, just that bad software is being hosted using ftp as well as http (which I presume is what is meant by 'URL' or being emailed.
And, ftp is not merely an ancient, deprecated protocol. It's still widely used because it does what is intended for well and works under high load readily.
Slashdot Mirror
I think whatever it takes, MS will render the cost moot in this case to stave off such a scarily wide linux adoption. They must be aware that there is next to zero revenue opportunity to be had here, but they must subvert any potentially successful project that is explicitly a home user targetted product that is tied to Linux (i.e. eeepc). So I suspect the cost here would be either zero or a token low amount, but somehow it will be highly restricted.
In some ways, I believe XO aims to help countries without a significantly established computing market get one going. With this is mind, I do think inviting Microsoft and Adobe in as they are may be a mistake. If it acheives the success they plan, then establishing a market that is inherently set up for competitiveness would be ideal. With Linux, it's an open platform with a number of commercial companies packaging it up and selling the support. People are free to jump vendors when they demonstrate a lack of relevant vision (for me, Ubuntu's vision and execution came at a time when RH/Fedora's stopped matching mine, and I changed). With Flash, Adobe has a stranglehold on a significant portion of the platform the web runs on. By giving away the end-user portion for free, porting it to the three major OS players on x86, and in general not being intolerably bad given the scope, people complain less. However the fact remains there is not a competitive market without a standard to follow. Adobe has a stranglehold on the content creation piece which they make lucrative. If the OLPC project hopes to allow their target market to create as well as consume, then using Adobe flash could be a bad move. Of course, on a more realistic front, if OLPC doesn't become so big it can change the world, they would be left out in the cold, so I suppose it depends on how optimistic OLPC is about its success.
I'm not quite an open source fanatic, it's just that I see the software market today as very wrong relative to other markets from a business perspective. There are a number of compatible processor, video card, motherboard, chipset, etc vendors, and I'm not stuck to any one of them. When I go to buy a part for my car, there are inevitably a number of companies providing that part. When I buy a Ford, I don't have anything to lose when buying a Toyota, I'll still be able to drive all the same roads. No matter whose television I buy, I can watch the same shows. Nothing short of a platform like Linux with its business setup the way it is I see as a realistic path to getting out of the peculiarity of this market. Asking software developers to port to different APIs won't happen, it must be a number of OS providers implementing the same API that provides the basis of an open market. Unix might have provided a suitable ecosystem if Solaris, AIX, HP-UX, etc etc had targetted the desktop segment at the appropriate time, but they did not, and now Linux/x86 is probably the only market that has a chance to be ubiquitous (sad in a way since processor architecture lockdown is implicit, but at least there are multiple companies implementing x86)
For desktop LCDs this doesn't have to be a bad thing, if the screen mount will rotate. Then you can have a 5:8 display instead of 8:5.
The report was targeted toward the software industry. I'm wagering the report in general is a warning of what software companies need to prepare for, rather than an attempt to stop it. Any attempt to even basically understand the pervasiveness of open source software would lead someone to know the software development industry can't do something to stop it. There are definitely alarmist words used in the subject, but 'disruptive' has a particular connotation to it that is not positive or negative with this sort of analyst. Cars were a disruptive technology, for example. Disrputive simply means the industry is being transformed and business's catering to the needs being fulfilled by open source software need to adjust the scale of resources used in those endeavors. If not wanting to scale down, they have to figure out how to get the revenue in different ways. Before cars, there was a much higher demand for horeshoes. As cars came to dominate, there remained a market for horseshoes, but a lot of the market evaporated and they either had to focus on other metalworking markets (cars being a huge metalworking market) or leave the market. Either way, they had to retrain and move on, but analysts wouldn't say that cars were a bad thing, just a very different thing.
And yes, I managed to cram a car analogy in.
While some pieces of equipment will allow configuration of the transmit hash, many will not.
Yes, it works to the extent reasonable/feasible.
No, it isn't a robust scalable solution. To play nice with various standards and keep a given communication stream coherent, it has transmit hashes that pick the port to use based on packet criteria. If it tries to use criteria that would actually make the most level use of all member links, it would violate the aforementioned continuity criteria. I have seen all kinds of interesting behavior depending on the hashing algorithm employed. I have seen a place buy 500 servers from one vendor and have a 2 port aggregation to somewhere. The problem being, that vendor had all even mac addresses on the first ethernet port, and so one of the ports got to be virtually unused because it was a hash of the mac addresses mod the number of member ports. Since there were two ports, it was mod two and all evens went on one port, and only odds would have been the other.
I also agree with you on the sentiment of xdnd and cut and paste. As a user, I'm not seeing the problem. The only user issue I see is that the middle click paste sometimes confuses people, but I'd hate to see that go away. Nothing about that could be called an issue with the architecture regardless of the opinion.
X gets a lot of power from having abstractions that can be remote agnostic. I think the implementations have done a sufficient job of providing short-path optimizations for the local case without sacrificing the fundamental remote functionality. I think X's task of taking the network architecture and doing it locally fast has produced a smoother experience than the platforms that have had to do the opposite, and try to make their GUI cleanly remotely usable.
Sigh, RISC as a platform strategy is not dead. PA-RISC, yes, it was abandoned in favor of Itanium, but Power, SPARC, MIPS,and ARM continue. Apple is not *the* benchmark of relevant technology, despite what they would like everyone to believe. And if you do need Apple to use something to consider it relevant, look at Apple's ARM platform iPods and iPhone.
And, more to the point, there is no relevance to security in talking about PA-RISC, or any instruction set at all. Once you hop OS, you no longer readily run Windows-compiled code anyway. Malware is just as likely to call upon a scripting interpreter as being compiled (in this day and age, most take advantage of scripting features of browsers or some other facility anyway.
In terms of Linux v. OpenBSD on the antivirus front, it doesn't really matter. The same antivirus my company forces upon my linux workstation is avalable for OpenBSD as well:
http://www.f-prot.com/news/gen_news/080225_bsdrelease.html
I'm a linux user for various reasons, but claiming that a linux platform is better than OpenBSD for complying with both the spirit and letter of this policy is silly. Both platforms have the tools that fit the description, and OpenBSD is far less likely from a philosophical perspective to give up security for convenience. Many Linux distros will embrace a new strategy before the security implications are thoroughly worked out for the sake of a feature, while OpenBSD will wait. Though not popular anymore, I remember when a handful of linux distributions had only the 'root' login, because they thought it was easy and didn't want to burden users with privilege escalation, as an example.
In any event, if the nature of the breach is obviously in no way related to compromising a computer system and rather is a more traditional way, than I doubt the bank would try to make a claim of relevance.
I use linux very extensively and find a number of niceties (compiz has far more practical features than Vista and OSX, and a number of general benefits of running a platform that is comprised entirely of things I can examine transparently myself but also is a healthy competitive landscape from the commercial vendor perspective). Making the hardware consist of interchangeable commodity parts has done wonders for the pricing of components, and the similar phenomenon is even more pronounced in software. Every user including gamers should appreciate what that means. Especially as MS increasingly treats the customers as the enemy (embracing DRM, increasingly bold 'anti-piracy' measures).
That said there are certain approaches:
-Ignore Linux and gaming. The highly immediately pragmatic stand, probably what you would justify. The question here becomes are you forced up the upgrade trail by Vista? A weaker, yet not currently aggravating stance is to at least boycott Vista and tell microsoft you won't pay, and by extension boycotting games if they make DirectX 10 a requirement, hardware if they fail to provide XP drivers, etc.
-Use Linux and cave if Wine will run the game. Wine runs a surprisingly large number of games (Orange Box a popular example). This, of course, doesn't necessarily send the desired message, but it goes a ways. I have seen software patches and graphics drivers note Wine-specific issues, so some developers are seeing Wine as a valid demographic to target given the effort. This requires being vocal about your mode of usage, or else face game patches screwing up your experience by making Wine-incompatible design choices.
-Use Linux and refuse to buy any non-native games. There are some publishers that released native games. NeverWinter Nights (but not 2), id games, Savage 2. Reward them for publishing quality games for your platform, while being vocal about refusal to buy other titles. There are some decent Free games too, I was surprised how decent Nexuiz was (though I confess the artwork isn't as nice as other games, but the engine seems pretty good at its core).
I'm a hybrid of sorts. I'll check out a demo under wine if the game is overwhelmingly interesting (i.e. orange box) to see if I want it and would risk it, but will be much much more likely to buy a random game with a native linux binary. A lot of my gaming is reserved for console games, but FPS and RTS and the like I feel no console has an adequate interface (though metroid prime on wii was not too shabby). BTW, server-only binaries on linux aren't enough for me. I know it seems like being partly evangelical, but the reality is I want more out of my core platform experience and don't want to be beholden to a single corporate entity. The PC architecture is great for that, with multiple compatible vendors for practically every part except the OS platform, so long as MS is the dominant vendor. Making moves to change that is a good thing for consumers.
The difference being, OSX offered something intrinsically leaps and bounds better than their predecessor *and* Apple is a smaller software market anyway. It's easier to move a small, homogenous market to a new platform (the number of 'important' apps is small and were quickly ported). The market of people sticking with OS classic is uselessly small, so no one cared much about keeping them up to date. At the time of OSX, something with the sophistication of Unix marketed to the home user in a sane fashion was unprecedented. XP came out later based on the NT line and Linux was at the time hardly in a position to be that usable for the demographic in question.
Now Windows 7 is coming from a company that has not displayed itself as capable of meaningful innovation at the core of the platform for a while now. They promise doing things 'different' and claim it will be 'better', but they had the same thoughts and promises regarding a lot of the aspects of Vista that blew up in their face. They *thought* file copying would be faster, and quite the opposite happened because they mischaracterized a rare corner-case as being overly important. They again with Windows 7 claim multithreading will be faster, because they ditch ring 0 stuff, but who knows what the state of new hardware will bring to make perceived benefit evaporate and who knows what pain will happen. Will Windows 7 be any better than XP/Vista for the end-user, probably not. Will a compatibility layer be glitchy, with their history, probably so. Will Wine at that point be solid enough for most people to make the Linux platform of the day roughly comparable with Windows 7? Possibly.
Hardware vendors should want Linux (making a commodity of the software stack means healthier margins), businesses should want Linux (a level playing field means your software vendor can't aggravate you even a little bit without reprisal, MS can piss off customers and not sweat it). Software development companies should like Linux, they can't ask for a more transparent set of APIs. Home users probably in general don't care, except for the market of ~100 dollar systems that are made possible by lack of MS tax. It seems the market is ripe to take a big 'screw you' like this and jump ship given the frustration anyway..
RS232 is 'good enough' for text and therefore has remained the console of choice in the datacenter for many servers and any remotely serious networking equipment.
Any decent admin has to have at least a half-dozen serial cables and adapters to plug from arbitrary DB9, RJ45, RJ11, Mini-USB, and who knows what else form factors carrying nothing more than the RS232 signals in various random pinouts. Yes, I've even seen a USB form-factor that wasn't used for USB signalling.
That a 1968 article can in some ways be more accurate about technology in 2008 than the internet in 2008 can be about technology in 1968.
It's a matter of tradeoffs generally. Take even a modern Linux distribution, with full default desktop, and try to run it on a system from 1998 (approximate 200 mhz, 32 MB of ram). I'd wager the live desktop that Ubuntu uses for install wouldn't even work. Sure, you can use alternate install and select packages enough so you just have blackbox and basic apps, but the overall experience won't be appreciably better than linux distributions of 10 years ago. I remember back in 1999-2000 the enlightenment people doing efm with some of the 'neat' effects that recommended at least a PII-400 or so, and people were up in arms. Now effects of those class are commonplace. In any event, as hardware advances, software gets to try things that they couldn't do before. Full-text search becomes more ubiquitous as disk space and io capacity allow for storing and reasonable maintenance of an index, as memory increases, applications use more to be more responsive live, as the number of applications a general system can run increases, so does typical usage and process schedulers change to accomodate that, the overhead of Virtualization is now considered reasonable, and the list goes on.
My problem with Vista is it seems to have little actual substance to justify the increase. MS jumped the shark as of Windows 2000. 2000 was followed by ME, and then XP. XP wasn't too horribly bad ultimately, but to this day I don't see the justification of it as a platform over 2000 other than the artificial support/maintenance drop of 2000. It feels like a forced update from MS. It wasn't significantly different under the covers, it pretty much acted like Win2000 with a goofy default theme. Now comes Vista, with mind-numbingly bad behavior with little payoff. The whole networking/audio interaction is a ludicrous hack, and shouldn't be remotely necessary on any decent kernel with sane scheduling. They moved 'direct'sound to userspace and suddenly this occurs. The file copy, despite all the apologists pointing to a MS guy explaining *why* file copies were so bad, is a horrible thing to have to explain away. Sure, XP fibbed a bit and that should be corrected (never should have been that way in the first place), but MS's pursuit of a 'fix' was so convoluted that it bit them in the ass. They say 'file copying is harder than you think', but a lot of the difficulty from that article seemed self-imposed.
I focus on those two points because it indicates how sloppy MS's approach to the core bits of the OS is, while they try to justify the value through a new theme and shiny, useless visual effects (Apple's expose is useful, and compiz under linux provides a number of useful mechanisms that take advantage of the power of windows as textures, Vista on the other hand...).
1) I prefer the userland approach of PreLaunch. A couple of fatal problems with a pre-load of my 'entire' disk are the fact that my memory is limited relative to disk space, and even it if weren't, I'd probably start trying to use my system so soon after boot up, that it probably wouldn't have cached the data I wanted yet anyway. PreLaunch attempts to identify and prioritize (my understanding) what gets loaded, so that the first stuff to the disk cache is the most likely to be used.
2 & 3 make some degree of sense, but I wouldn't choose that tradeoff. Particularly as SSD technology improves and ultimately may render the point nearly moot (latencies will drop to a reasonable amount, not probably within an order of magnituted of system memory, but tons closer than spinning disks, and close enough that I would guess such esoteric measures as this extend beyond the point of diminishing returns.).
The analysis thankfully makes a comparison to the IO caching that happens nominally. The distinction seems to be that this 'innovation' makes calling 'sync' a lie. That just doesn't seem like a good thing. It seems a roundabout way to make sync a lie as well.
I put in 16 GB of ram in a system, and operations are quite snappy, the disk cache happily filling and draining, and it feels more or less like a ramdisk system, once the data has been read into memory the first time on read operations. Sure, sync takes an ungodly amount of time, but that only happens when something wants to make damn sure the system is ready to tolerate an unfortunate event after something important happens.
I'll put aside the inaccuracy of 'the SSL port', and assume you meant http SSL and/or imap SSL, etc. This I cannot think of a defense for.
In terms of third-party applications, they do have good reason for blocking software. Namely, most all users are in the mindset of 'hey, it's free', without reviewing the details of the licensing. At my work, lawyers review licenses of popular 'freeware' and often reject it due to legal liabilities. One *extremely* common thread is that all this 'free' software is 'free (for non-commercial use)'. Particularly among Windows closed-source freeware, the software is intended to genuinely aid and/or advertise to the home user and recover the costs through commercial usage. These vendors love their ubiquitous home product driving people to defy policy and in the end, often the company buys a large license rather than fight the tide. My experience is that companies have an existing contract to cover that type of application, but they have chosen one that has fallen behind the curve in competitiveness, so users are frustrated. Said company doesn't want to jump ship (costly and annoying to users) unless it's overwhelmingly clear that the fundamental functionality of their chosen product can't do the job anymore. The problem is, despite being annoying, sluggish, etc, generally underneath it still gets the same job done, just more annoying to users.
It seems to be more about torturing a developer to force them to know how to write scalable/portable applications than being an actual practical platform. Sure, 72 cores sounds cool, but being a merely respectible 72 gigaflops (each core is simply a gigaflop) it's bested by a dual-socket Core 2 based workstation with quad core 2.33 in each socket. Practically speaking, many cores is helpful, but the same amount of performance in fewer cores is more flexible. It is a bicycle with training wheels for developers to know the scaling weaknesses of their algorithms without having to piss away time on an expensive scale-out cluster.
Availability in many of the supercomputer deployments is measured in percentage of the participating servers that stay up, not by continuous uptime. Applications may be killed off, but the job scheduler restarts them either from the beggining or a checkpoint. In the end, an application has executed a clean run, but instances of that application might have died a horrible death along the way. For the sake of cost, supercomputing has been in the business of migrating redundancy up toward tolerant software rather than having expensive, relatively low volume redundant hardware designs.
One *could* implement that sort of strategy with a single system. Imagine every thing that you executed and cared about was submitted through anacron and anacron wouldn't give up until the program exited successfully. Yanking the system and restarting it would redo the application from the beginning, like supercomputing clusters. The granularity is so coarse you can't help but to notice, but at the core it wouldn't be much different from a server going down among the sea of systems that is a supercomputing cluster. Jobs on a supercomputing cluster are rarely directly interactive, so this sort of jerky behavior will go unnoticed, but if your webbrowser randomly disappeared and then reappeared, it would be jarring.
This is a high-end dual socket box that incorporates cooling that is probably quieter than equivalent air cooling. It has nothing to do with the visions of 'supercomputer' and the word supercomputer itself is always a relative term. In 1993, the top supercomputer had 60 gigaflops, with a theoretical of 131 gigaflops. This system has a theoretical of 102 gigaflops and probably can get 80-85 gigaflops measured, so it would manage to beat the number 1 supercomputer of 15 years ago.
Nowadays, the most recent list has the #500 supercomputer at nearly 6 teraflops (rpeak of 10 teraflops). Or, to quantify, the lowest of the top 500 is still 100 times more powerful than one of these boxes.
Supercomputer in your palm, supercomputer in the desk, as long as you get to pick the year by which you declare what a 'supercomputer' is, you can declare whatever you want.
Others have mentioned the accounting thing, I think that's a very good example, it's much easier to track what is going on when a definitive DHCPDISCOVER transaction appears. One could make the argument for DNS update requests to be a good indicator, but that's not nearly as to the point and not required to occur.
On a more purely technical note, how do I tell server176 boot firmware that it should be loading file 'deployimg.176', while telling server12 to be loading 'recordimg.5', or whatever? How do I tell one set of servers in a network to tftp from one server, while others in the same network to tftp from a different one? The problem with zeroconf/multicast dns as the answer to everything is that assumes quite a homogeneous network that is symmetric, and many many useful examples exist that would not be accommodated without something like DHCP that centrally deals with it. Could it be possible to make multicast dns solutions that are torturously convoluted to provide the flexibility, sure, but what did you gain from simply moving the problem from sets of established codebases to a different set of codebases?
But ultimately, the question is, what's the harm of DHCPv6? I don't see multicast DNS+routing advertisement daemons as *really* any less infrastructure to set up. An administrator simply *has* to make the basic data available one way or another. People down on DHCPv6 haven't convinced me why setting up radvd and the other stuff is really better than DHCP. DHCP only was a pain when you chose to micromange (which is merely optional, can opt not to do it if radvd would have been enough), and when having to deal with frustratingly small pool allocations (inherently rendered a moot point by the IPv6 address space).
First off, since when is a 'URL' considered a transport mechanism rather than syntax for specifying a transport mechanism and location? Is ftp://whatever.example.com/badcode/ not a URL because it's ftp now? That's a goofy statement.
And then, this isn't about ftp being hacked, just that bad software is being hosted using ftp as well as http (which I presume is what is meant by 'URL' or being emailed.
And, ftp is not merely an ancient, deprecated protocol. It's still widely used because it does what is intended for well and works under high load readily.
Flash 9 supports h264 video codec.
DVD playback contends with the DMCA, so patents going away would still preclude legal CSS decoding.
Thanks for the correction, that makes a lot more sense.