The "none of the above" option is called turning up at a voting station, getting your name crossed off, and not voting; last I checked, this was legal.
And failing that, take your voting slip, leave it blank, and put it in the voting booth. You've fulfilled your obligation to vote, without voting for any candidate. While I think this is incredibly stupid, you can do it, so what are you complaining about?
Correct, but interestingly enough, the Windows Server versions (definitely 2008 and on, possibly 2003) do not have it installed by default. In Windows Server 2008 and R2 it is one of many "Features" which you can choose to add to the server if you need it or as required as a dependency. It's unfortunate, as Windows Server 2008 and onwards has always seemed to be more "componentised" than its desktop counterpart, which takes more of a "install almost everything and remove stuff you don't want approach". I guess from Microsoft's view it's an ease of use argument but there are things in Windows Server 2008 that are not only not installed by default, but can't be removed at all on the desktop variant.
meticulously designed user-oriented design interface
.....are you in marketting?
Re:Only copyleft is "commie", BSD isn't.
on
OpenSolaris Or FreeBSD?
·
· Score: 3, Informative
While I agree with much of what you say, it doesn't exactly help your case when you layer your own post with fairly fanciful and stupid assertions, while rebutting the exact same in the GPs post. For one, the BSA aren't Microsoft's enforcers anymore than the RIAA are the Bee Gees' enforcers. They are a group that exists to enforce copyright and software licences, and while I don't agree with much of their policy or their actions in enforcing it, suggesting they are some puppet of Microsoft's is just absurd. Check the BSA membership, it's full of huge industry giants many of them direct competitors of Microsoft's; IBM, Apple, Dell, Adobe, Symantec, RSA, to name just a few. Further, military style raids might be a slight exaggeration, like calling the GPL communist or anti-capitalist for example.
But one point in particular I'd like to address is your assertions on the Interix system. Firstly, I think it's absurd to suggest that Interix was "created solely for the reason of destroying UNIX". Where's your proof? What leads you to this conclusion? Or does providing compatibility now (much like a huge number of other projects, like Wine) automatically entail an objective of destroying the target platform? Unix (and Unix-like) systems have always played and continue to play a major role in computing, and this is a good thing, surely some degree of compatibility with these systems at the API level is a good thing? This is a large part of what Interix does, it provides a POSIX implementation on Windows as well as a Unix-like environment for development and productivity. So you have the POSIX API, Csh/Korn shells, a large set of Unix utilities, compiler, libraries and headers, and a lot more. The idea is to provide a Unix environment on Windows for migration, compatibility and development.
Cygwin I suspect wasn't "fixed" by Microsoft for several reasons. One would be that Interix/Cygwin began development around the same time, another would be whether the developers would be receptive to development efforts by Microsoft, another might be legal concerns and all the usual licensing crap, but perhaps most of all, the way they accomplish their functionality is very different. Cygwin provides a POSIX implementation and Unix-like environment _ON TOP_ of the Win32 API. This is done through a DLL (cygwin1.dll) which translates POSIX calls into Win32 calls which in turn call into the NT Native API. Interix by contrast does not use Win32 at all, but runs directly on top of the POSIX subsystem, thus, Interix apps go POSIX Subsystem -> NT Native API. Of course, you still have to use the Win32 API as that's what the Windows OS is primarily built on, but the POSIX subsystem runs alongside it and Interix on top of it. This is indeed the point of the NT Native API and much of the NT design; the Native API is (as the name implies) the base API for the NT OS and environment subsystems run on top of it providing an API for client applications. The Windows API is one such subsystem and the one that 99% of people use, POSIX is another, Win16 is another (I think?), and in the past there has been a (fairly crippled) OS/2 subsystem, and possibly others.
This affords some unique functionality for Interix in that it can do things at the API level that the Win32 API doesn't really support, simple example: fork(). The Win32 API to my knowledge has no real fork() equivalent, however, this is supported by the POSIX subsystem. The reason is that the Native API does support fork() but does not expose it through Win32 (but does through POSIX). Clearly, the Cygwin developers have worked around this, although how they've done it I'm not sure. Perhaps they translate fork() calls to loose Win32 equivalents? Or they call directly into the Native API (possible, but strongly discouraged)? Whatever, my point is the implementations of these two environments are very different, and I suspect they offer varying functionality as well as differing in actual POSIX implementation. I gather there's quite a nice Interix community, and Microsoft has put a
FYI: Microsoft commits to support the version of IE that ships with "x" Windows release for as long as "x" Windows release is supported. For example, IE 6 was shipped with Windows XP and so will be supported until Windows XP ceases to be. What this means is IE 6 is guaranteed to at the very least receive security fixes and limited bugfixes until sometime in 2014 when Windows XP leaves support. Similarly, IE 7 was shipped with Vista and will be supported until Vista ceases to be; contrary to what others may say, this is likely to be a very long time, I'd wager a minimum of 1 decade from RTM.
That being said, XP users using IE 7 have upgraded to it either consciously or via Automatic Updates and Vista users I suspect are far more likely to have Automatic Updates enabled as the OS has the functionality baked-in from RTM and aggressively encourages the user to enable it. So, while it may be supported for a long time, its userbase may shrink rapidly in contrast to the glacial decline of IE 6.
The lack of the tiny telnet client binary in the default install is admittedly infuriating, not to mention that it takes forever to install through optional components, which I can't figure out.
Suggested solution: Just use PuTTY. It's small, free, and supports Telnet and various other protocols fine, despite the fact I suspect nearly everyone uses it purely for SSH.
And yet, Apple's default browser Safari has a pretty terrible security record, the latest OS X release contained a bug that nuked account data, and OS X consistently falls behind both Linux and Windows in defence-in-depth security mitigations. While Apple might like to boast about its operating system security, this doesn't appear to be due to any particular "hardened" design versus other mainstream operating systems and in fact lacks solid implementations of various security features that have been standard elsewhere for a long time, rather, it just doesn't seem to have had a lot of exposure to those who would exploit it. If you were posting from a OpenBSD box I might hesitate before replying, but OS X is just another mainstream OS with a broad audience and plenty of holes.
So, I'd suggest getting off your high horse. All operating systems have their bugs and security exploits, and ignorance of your systems security record and capabilities does not make it secure. Also, excessive smugness is not an endearing character attribute.
Minor correction:
This isn't necessarily limited to EOT fonts, but is a flaw in the font parsing code in the kernel in general. EOT fonts are just the exploit vector as specific to IE, but other font types can be used for less likely exploit vectors, such as TTF fonts in a Terminal Services setup. The point is this is a flaw in a kernel system call and IE's use of this system call + default settings makes it vulnerable to exploitation.
Anybody else think something is integrated with something else in a deeply, deeply wrong way here?
No, not really, at least, not in the way you're insinuating. The Win32k kernel mode driver is essentially the major component of the Windows kernel responsible for kernel-mode graphics related processing. Put more succinctly by MS from the MS09-065 security bulletin:
Win32k.sys is a kernel-mode device driver and is the kernel part of the Windows subsystem. It contains the window manager, which controls window displays; manages screen output; collects input from the keyboard, mouse, and other devices; and passes user messages to applications. It also contains the Graphics Device Interface (GDI), which is a library of functions for graphics output devices. Finally, it serves as a wrapper for DirectX support that is implemented in another driver (dxgkrnl.sys).
The handling of EOT (Embedded OpenType) fonts is apparently (at least partially) handled by the kernel and presumably a component of the GDI system. IE supports EOT fonts and presumably just hands them off to the kernel, after all, it is delegated the responsibility of handling them, so why re-implement it in IE? The flaw is not really in IE but in buggy code in the relevant processing. There is an argument to be made that IE really shouldn't be explicitly processing these fonts by default in an untrusted network (and this can be changed in the preferences, but is not the default), but the flaw itself is in the system call code itself; the latter is merely about reducing attack surface in the case of exploits such as this arising.
My point is, this isn't really a case of IE being "overly" coupled into the system (which isn't to say it isn't, just that I don't view this as an example of it). Whether it's sensible engineering to have the kernel handle this stuff is probably a far more interesting and valid argument. Protecting against system call vulnerabilities is pretty tough, as you do expect the kernel to be trusted, indeed, if you can't trust the kernel you have serious problems. A quick google seems to suggest Firefox doesn't support EOT fonts, and I'm not sure if any other browsers do either, but if they did, they may well have their own exploit situations as well.
There should be very little, particularly as the Windows kernel hasn't undergone any massive reworking, however, there are two particularly likely cases:
a) As another poster mentioned, poorly designed software which relies on API functionality that is subject to change. Seriously, Windows software does this all the time, and not just small-time developers, huge software companies (ala. IBM/Google/etc...) have in the past and I suspect continue to use Windows "features" that aren't meant to be used by anyone outside of Microsoft. This typically means using undocumented APIs or API calls that Microsoft does not expect anyone to use, and thus when they change them (which should be fine, no-one should be using them), things break horribly. The other obvious example is dumb assumptions (running as an Administrator is a classic example) but there are many other more subtle ones.
b) Software that installs stuff into the kernel is far more likely to be incompatible without an update or patches (e.g. hardware drivers/virus scanners, etc...). While it's fashionable around here to label Windows 7 as a rebadged Vista (and prior to this Vista SP2 until people realised that Vista was about to get a second SP), the Windows 7 kernel has undergone some significant changes. One was alluded to here just recently. For those who care, Mark Russinovich has written (several?) articles on the Windows 7 kernel changes and various video interviews are available (on Port 25?). While the Windows kernel driver framework hasn't undergone significant changes (which was the primary reason for the seriously crap driver situation on Vista for quite some time), there have been changes to it and many modifications to other parts as you'd expect.
I obviously can only guess on the reasons for iTunes/Google Toolbar being blocked during the upgrade process, but if I were to place a bet, the Google Toolbar might have compatibility issues with the version of IE in Win7. Even though Vista has IE8, it won't be identical to that in Win7 (even if it may be aesthetically), and this can have potential ramifications for browser plugins. As for iTunes, it's a bloated piece of crap that consumes insane amounts of resources (at least on Windows) and has been known to do bad things to the USB stack. It wasn't too long ago XP machines were blue screening due to a buggy iTunes driver (painfully ironic while Apple is playing ads poking at Windows stability, while actively contributing to its lack of) and just recently I found a nasty handle leak that resulted in iTunes consuming several thousand handles a day and not releasing them, I managed to get it to just shy of 30,000 within a week. Would I be surprised if iTunes were doing stupid things that would cause incompatibility during a Windows upgrade? Not even slightly.
Apparently I'm a troll, because my opinion differs from yours, but oh well:
a) The actual article doesn't in any way make it out to be "very little trouble" (the exact phrase used was "not a large obstacle"), and considering it's the very first grievance he points out, I think it should be obvious that it causes a non-trivial amount of trouble. I'm not arguing in favour of a stable kernel API mind you; I'm personally not strongly for or against, I've read insightful and convincing arguments from both sides of the debate. But pointing out that one of the biggest closed-source Linux drivers with a large team of dedicated/experienced driver developers who are paid for their work (and presumably quite well) and are are employed by a large company with significant resources don't find the unstable API to be a large obstacle doesn't exactly in my view prove anything, except that with sufficient resources the problem is manageable.
b) He says the architectural decisions are "quite sound", but at the same time says it's the area of Linux with the "largest opportunities". I'm going to play the Devil's advocate and suggest that he's probably somewhat biased with this kind of assessment, as if he loathed X, I doubt he'd be developing graphics drivers for it. Don't take this as invalidating his comments, I think they are correct, but I'd be more than surprised if he came out and called X a gigantic turd. He _does_ point out that it is highly flexible and extensible, which is to say, you can easily change its functionality and implementation, and others have pointed out, the Nvidia binary-drivers replace a fairly large chunk of the X code in order to work, which doesn't exactly lend to your assertion that X is entirely rosy.
I'll be honest and say I'm no fan of X, it's fairly close to my arch-nemesis on Linux, I just always to have bizarre/infuriating problems with it but that might just be that I'm unlucky/incompetent with it. But, I don't think it's wholly bad; it's been capable of various things for decades that Windows has only achieved in the last couple of years (and other it still can't). I'm just opposed to blanket labelling of opposing viewpoints as trolls.
I've been following this story since it began, and I've got to be honest, I think you've made completely the wrong move and have done potentially serious damage to Mozilla's public image among certain techies, and possibly worse, hindered enterprise adoption of Firefox (and helping to nuke the scourge that is IE6), which I'm sure you'd know is an area FF has struggled to really gain increasing marketshare in.
Getting the preliminary kneejerk stuff out of the way; Microsoft screwed up, bigtime. I don't know of anyone who is debating this. This add-on should never have been silently installed in Firefox at all, period. The best distribution mechanism would have been a manual and entirely separate download that can be installed/deployed en-masse by those who require its functionality.
This is also entirely irrelevant. The damage has been done, and calling Microsoft names or abusing them for their past actions does nothing to fix the current problem (I'm not accusing you of this, but others who've been contributing to this discussion). I can understand the principle behind your decision to add the add-on to the blocklist, but it has some serious issues that I'm astounded Mozilla decided to disregard:
1. It has no regard for patch level. This results in people having patched versions of the add-on (whether they use it or not isn't the point, there's no way you can determine this without consulting the individual user) disabled. You are literally automatically killing functionality in the browser that is NOT a security or stability risk. Worse, you present users with a dialog box which in the case of a patched system is telling an outright lie or serious misinformation to the user with respect to the status of their add-ons. I can't even begin to understand how Mozilla deems such a situation where a significant proportion of the userbase is potentially being fed misinformation by their browser acceptable.
2. This add-on is not to my knowledge under significant usage, but where it is used, it is mostly in the enterprise. Business doesn't take kindly to having programs that they rely on remotely disabled, it causes pain for sysadmins and I don't think I need to elaborate what other problems it can cause that are more serious. That Mozilla thought it a worthy trade-off to potentially protect some of their userbase at the cost of disabling functionality remotely that people may not merely use but rely on for important or even critical computer functions simply boggles my mind. I'm of the opinion it's generally not appropriate to remotely kill even vulnerable software the but I can understand how others would differ in opinion. But taking into account the fact that it kills non-vulnerable versions as well, and that people may depend on it, and that it's non-trivial to re-enable, and I can't understand the rationale.
Put simply, if you don't have the infrastructure in place to reliably differentiate between vulnerable and non-vulnerable versions of the add-on, don't block it at all, it's not worth the problems you're inevitably going to cause, be it ethical (remotely disabling perfectly working and secure/stable software even if not used) or the more practical (as before except actually in use). That, and ClickOnce is also not to my knowledge a popular exploit target at all; this may of course change, but I'd be surprised when there's plenty of other ripe and easily exploitable targets with a larger userbase. If you wanted to go for sheer attack surface reduction, I would have thought there are several versions of Flash that are obsolete with truck-sized security vulnerabilities that plenty of people are running and are actively being exploited right now, that are easily detectable by versioning. I'm not advocating this mind you, but it seems to me there are easier targets if beefing up security through add-on blocklisting is the idea.
Finally, you've re-iterated several times that Microsoft approved your decision. I don't see how this legitimises the decision? I often don't agree with M
I was about to bitch about the submitter/moderator not RTFA, but it turns out, the article doesn't mention it either, so I'll clarify instead: thirteen updates are being released which together address thirty-four security vulnerabilities of varying severity across varying products (ten of which are targetted at Windows). So, that's NOT thirteen flaws (plenty more actually), just thirteen updates, some of which (all?) address multiple flaws in the particular system they are targetted at. Of course, this is just the advance notification, so full details about how many vulnerabilities each update addresses and the general information on them won't be released until the patches are next Tuesday. I think it's also worth nothing (although the summary of course neglects to mention it) that the good aspect of these updates are both major zero-day exploits (targetting IIS & SMB 2.0) are patched with these updates.
And while I'm posting, why does Slashdot insist on linking to shitty tech magazine articles (poorly) summarising the raw and accurate data straight from Microsoft? Seriously, I'm not sure if it's some sort of aversion to linking to MS, but they're the ones doing the patching, so it follows that they have the best, newest, most accurate data on them, and they'll likely be the first to provide updates on their content. These articles are just summarising what Microsoft has published on their various web-sites, and being a summary, they provide a lot more information and raw data:
I completely agree with you that it's rubbish that Windows doesn't have out of the box support for virtual desktops. It should have been part of Windows a long time ago, at least a basic implementation of, allowing 3rd-party developers to offer more complex and powerful implementations at their own leisure (as is often the case with built-in Windows functionality). Another personal beef is the lack of multi-mon taskbar support, instead having to rely on UltraMon or similar applications.
My point was purely that the APIs to enable this support have been in place for a very long time, it's just Microsoft seems to have no interest presently in using them to create solid built-in support; but other 3rd-party apps use them to create the desired effect. As for your options, you might want to check out this old Ask Slashdot: Virtual Desktops on Windows? discussion; it has plenty of good recommendations.
In a similar vein to the old XP VDM PowerToy (which admittedly wasn't very good), Mark Russinovich has written a nice tool as part of Sysinternals Suite simply called Desktops. It differs a bit from many other virtual desktop apps, but the link explains it well. The result is it has some (possibly very significant) downsides, but there are some advantages as well. I've found it to be very fast personally and by nature it eliminates in my experience the compatibility problems you mentioned.
Proper built-in virtual desktop support really ought to be at the top of the MS's UI priority list, and I'd hope we don't have to wait till Windows 8 for it, but something tells me that'll probably be the case...
Since we, users of Unix desktops, have been using virtual desktops for ages, we don't need to cram tens of windows on each desktop.
What's wrong with both? I'm a Windows user and use virtual desktops, and tend to end up with virtual desktops that have applications that fit into a certain category. For example, programming related fun on one virtual desktop, recreation on another, and so forth... That doesn't mean I don't have a lot of windows on a virtual desktop, quite the contrary at times. Swapping constantly between virtual desktops purely to try and ensure that no single virtual desktop has enough windows to cram the taskbar is in itself just as unproductive, if not more so; I'm sure I've read studies that scientifically prove this point.
Simply, the new taskbar is quite a nice step forward from what I've seen, and just because your current paradigm makes crammed taskbars (or alike) less likely, that doesn't mean that an improved taskbar should be shunned for no express reason than the fact that the problem it addresses is less likely to be personally encountered by you. Add in the progression of Linux moving into the mainstream of desktop computing with distributions like Ubuntu, and you'll find that many of your target audience will be _very_ confused by the notion of multiple desktops, and an improved taskbar such as that in Windows 7 is a far more intuitive solution (for most typical users that I've seen) while still being effective.
Traditional Windows users don't like virtual desktops. I never understood why. Couldn't do without them myself.
I think it's not so much the "traditional Windows user" but more just the "average user" irrespective of OS. As mentioned above, it's conceptually a bit hard for typical users to grasp, or at least, that's been my experience. It complicates the usage of the computer for them, and I can understand this perspective. Also, I'd argue you really need to be using hotkeys for the full benefit of multiple desktops to rapidly switch between them, or the actual time saving from moving the mouse to whatever control you need to use to swap the desktop (system tray in the bottom right usually) and then finding your target window on the new desktop is going to be barely faster than finding it with a single click in a cluttered taskbar. Average users rarely care to learn more than a very minimal set of keryboard shortcuts.
Honestly, Unix users probably use them more simply because the average Unix user is far more knowledgeable about computers and their usage than the average Windows user. It's (although slowly changing) a computer geeks/hackers OS; Windows has a much broader demographic. I'd be interested to know what the picture is with OS X with respect to the above?
PS: The snipe about Unix users using multiple desktops for ages is unwarranted. NT (and 9x?) has supported multiple desktops since the dawn of time via the Windows API, but the OS has never included a built-in tool to harness them for the usage of multiple desktops. Multiple 3rd-party utilities exist to address this, and I've been using them for probably over a decade now, as do most other Windows "power-users" I know.
This guys particular tale of developing this software, patenting it, going to court against Microsoft over the (now overturned) infringement, and present day life was actually recently covered in an episode of Australian Story. I remember watching it and not coming away particularly impressed with Ric Richardson by the conclusion.
I'll be honest and state I haven't read the patent in its entirety, and so I could be entirely wrong about this, but the impression I got throughout the entire show was that it's just a fairly generic patent that covers what most today would refer to as "Online Product Activation". Microsoft has used such a scheme since Windows XP as most Slashdotters would be aware, but so have countless other software programs and associated corporations for protecting their proprietary applications. To be fair, he did develop this technology quite some time ago before OPA was in any way a standard or at least regular affair, but that doesn't in my view legitimise it. I can't support patenting abstract program technologies.
I'll withold judgement until I actually bother to read or learn about the real contents of the patent in its entirety, but if it is of the generic type, and I distinctly got this impression, then I have to say I'd probably come down on Microsoft's side. Which is tough, as they don't exactly have a pristine past on responsible and ethical usage of software patents, but that doesn't permit me to be hypocritical, and this guy is nothing more than a "patent troll" if the patent is as vague as I've been led to believe.
That, and if you watch the particular episode (I'm unsure if it's available for streaming outside of Australia), you may well find that you pick up a certain vibe about this guy that he is quite patent happy, but I might just be overly biased.
No, I take the view that's $40 million AUD that could have been spent on actually bringing the creators of genuine child pornography to justice, rather than a filter to stop people from viewing the end result of the real original sin. The hard reality is, people who want to view this material are always going to be able to access it if they really want to, filter or no filter, and this money does nothing to stop the problem at the source; just maybe a few people from seeing a video that shows the (in my opinion) far greater crime.
I agree with your post in principle, but I just thought I'd point out that the argument that guilt is not hereditary is often used in the wrong situations. An example from Australia would be the relatively recent apology to the Aboriginals (our indigenous population) for their mistreatment by past governments. The former Prime Minister, the (dis)-Honourable John Howard, used this exact argument for the over a decade he was in office, and somehow, completely missed the point of the argument for an apology in the first place. Nobody was claiming that he or anyone else was personally responsible for the mistreatment, but rather, that the apology would officially _recognise_ the past mistreatment. Our current Prime Minister, the (only slightly less dis)-Honourable Kevin Rudd
recognised this and made an official apology.
Thus, it is of historical importance, and by extension of moral importance. Until the apology was made, the government had never, ever, officially admitted their past wrong doing, and by doing so, they effectively go a long way to closing a past chapter of Australian history that is less than pleasant, so that the majority can move on. I'd suggest something similar is what is at work here, recognition of Alan Turing's mistreatment officially absolves him of any wrong doing. I'm not saying I think this is necessarily worthwhile, but I also don't believe the motive for doing so is in anyway some ill-conceived idea based off the notion that guilt is hereditary. Further, stating that an apology is only appropriate when you are personally responsible is simply not accurate. When someone tells me that a close friend has died, I'll tell them I'm sorry to hear that, but I'm in no way admitting I was responsible for their death. It's purely an indication of my sympathies; an apology for Turing is similar in concept. I really do find the notion many present that seems to me to indicate that apologising is either an admission of guilt or an admission of weakness (or both) very quaint at times, and says a lot about that person. Admitting something in the past was wrong that you have even a historical connection to, is in my view, a sign of strength and intellectual wellbeing.
Only just noticed you were replying to a (hidden) troll, which changes the tone of my reply a little, but the point about applicability of fuzzing tools is in my view still entirely valid. Sorry about my remark that you rushed out to change the conversation.
Hey man, you did "adobe xml vulnerability" twice!! Admittedly, their security record is appalling, particularly as of late, but still, play fair;)
More seriously, an article comes out about multiple XML vulnerabilities in multiple open-source XML libraries and your immediate reaction is to rush out and try and shine the light on XML vulnerabilities in closed-source code?! How about you first wait to find out the severity of the exploits in the open-source software, and equally importantly, how long they have been in the source first, before you try and divert the conversation? Further, the exploits weren't found by the project authors, but by a security vendor who applied protocol fuzzing tools. Fuzzing tools operate on the binaries, and thus, the source code is irrelevant, you can run these tools on any software irrespective of the source-code ideology behind it. Where the open-source aspect may come into play is largely in patch response times, but the argument that they may have been found quicker in closed-source software is in this case unsubstantiated, and especially tenuous considering the mechanism that found them is equally applicable.
Of course, they might turn out to be entirely mundane, as the specifics of the vulnerabilities have not been disclosed, and security vendors tend to exaggerate the severity of any given vulnerability they find. But still, have you considered fixing your own house before immediately running out to abuse entirely unrelated software? It might not be long before someone is wondering about variousvulnerabilities inopen-source software. Some restraint is useful considering the complete lack of solid information.
Without a legal means to enforce that the code remains in the open (ie. open-source), how do you intend to ensure that this remains the case? What's stopping someone from just taking it, improving it, marketting it, selling it, and never releasing the source changes back to the public? There's no legal deterrent, or, any legalalese that says he can't, so why not? The license is irrelevant here, if it's an open-source license, you need a means to ensure that it is enforced; that's copyright. And if you want to place any sort of restriction at all on your code, no matter how mundane, you need a license; even some of the most permissive licenses (e.g. BSD) still have restrictions, for example, credit where credit is due in the example of the latter.
Okay, so I'm on XP at the moment... Just what incentive is there for me to upgrade, exactly?
I have to admit, I'm getting really tired of people asking this often rhetorical question about Windows releases, as it only indicates one of the following things:
* The poster is incapable of doing their own research to find the answers to incredibly basic questions
* The poster has found the answer but feels the need to post the question regardless probably to elicit a certain response
Seriously, you want to know what the incentive is to upgrade? You get all of the features new to Windows Vista and all of the features new to Windows 7. Now, if you can read all of that and legitimately tell me that you find no real compelling reason to upgrade, then that's fine, I disagree but I'll accept your view, and more importantly, you've answered your own question.
Realistically, many people will get extremely enthusiastic over the latest Ubuntu release despite the fact it's only 8 or so months since the last release, and while it provides some useful new functionality, the overall changes are a fraction of the massive overhaul that Vista received and that Windows 7 incrementally improves. Mind you, I have no problem with this either, but it does boggle my mind that someone can either be so ignorant of what a new Windows release contains or so inept as to be unable to find this out.
The rest of your complaints are really just an assortment of mundane issues and unrealistic expectations, I can't be bothered addressing them all, but a few picks:
1. If your PC only just qualifies to run Windows 7 then it's probably pretty old (I link to the Vista reqs as 7 reqs are not yet finalized, but are rumoured to be the same, and the general consensus seems to be it is both snappier and less resource intensive than Vista anyway). None of these requirements are exhorbitant, and while it's a favourite past-time of many Slashdot posters to insinuate that Vista needs an absolute beast to run smoothly, this is far from the truth. What it NEEDS is a relatively modern machine, your XP machine purchased in 2002 is not modern. I wouldn't expect to run the latest Ubuntu smoothly on 2002 era hardware, if at all, and similarly, I don't hold Windows to a different standard.
2. Upgrading 98 to XP is not as big a task as you'd think. Yes, you're moving from a 9x system to an NT system, but keep in mind that much of the codebase was shared to an extent (e.g. IE/DirectX/WMP), etc..., and the release of XP and 98 was only about 3 years apart assuming you were using the first edition of 98; if you are using the second, you're down to about two years. In contrast, an upgrade to Windows 7 from XP is not only EIGHT years newer, but a massive overhaul of the underlying NT system. And honestly, as many have stated in this thread, you shouldn't rely on major OS upgrades without a fresh install to be reliable or even stable. You're welcome to give it a shot, but you should not expect everything to go right, and a clean install will almost always deliver better results in the long run, even if it requires more effort to be invested initially.
3. What interface tweaks do you lose that you can't duplicate on 7? Do you use every feature in XP? Do you realistically expect to use every feature you gain in any given OS upgrade? Is it really that hard to backup all of your programs and data? For christs sakes, take some initiative and figure these things out for yourself, and if it isn't worth the effort, then don't upgrade, no-one is forcing you to.
Is it really that hard to do a little research rather than run to Slashdot to have people answer things for you?
Slashdot Mirror
The "none of the above" option is called turning up at a voting station, getting your name crossed off, and not voting; last I checked, this was legal.
And failing that, take your voting slip, leave it blank, and put it in the voting booth. You've fulfilled your obligation to vote, without voting for any candidate. While I think this is incredibly stupid, you can do it, so what are you complaining about?
I'm pretty sure IIS is factored into the cost of the licences of the versions of Windows that contain it (whether you use it or not) ;)
Correct, but interestingly enough, the Windows Server versions (definitely 2008 and on, possibly 2003) do not have it installed by default. In Windows Server 2008 and R2 it is one of many "Features" which you can choose to add to the server if you need it or as required as a dependency. It's unfortunate, as Windows Server 2008 and onwards has always seemed to be more "componentised" than its desktop counterpart, which takes more of a "install almost everything and remove stuff you don't want approach". I guess from Microsoft's view it's an ease of use argument but there are things in Windows Server 2008 that are not only not installed by default, but can't be removed at all on the desktop variant.
meticulously designed user-oriented design interface
.....are you in marketting?
While I agree with much of what you say, it doesn't exactly help your case when you layer your own post with fairly fanciful and stupid assertions, while rebutting the exact same in the GPs post. For one, the BSA aren't Microsoft's enforcers anymore than the RIAA are the Bee Gees' enforcers. They are a group that exists to enforce copyright and software licences, and while I don't agree with much of their policy or their actions in enforcing it, suggesting they are some puppet of Microsoft's is just absurd. Check the BSA membership, it's full of huge industry giants many of them direct competitors of Microsoft's; IBM, Apple, Dell, Adobe, Symantec, RSA, to name just a few. Further, military style raids might be a slight exaggeration, like calling the GPL communist or anti-capitalist for example.
But one point in particular I'd like to address is your assertions on the Interix system. Firstly, I think it's absurd to suggest that Interix was "created solely for the reason of destroying UNIX". Where's your proof? What leads you to this conclusion? Or does providing compatibility now (much like a huge number of other projects, like Wine) automatically entail an objective of destroying the target platform? Unix (and Unix-like) systems have always played and continue to play a major role in computing, and this is a good thing, surely some degree of compatibility with these systems at the API level is a good thing? This is a large part of what Interix does, it provides a POSIX implementation on Windows as well as a Unix-like environment for development and productivity. So you have the POSIX API, Csh/Korn shells, a large set of Unix utilities, compiler, libraries and headers, and a lot more. The idea is to provide a Unix environment on Windows for migration, compatibility and development.
Cygwin I suspect wasn't "fixed" by Microsoft for several reasons. One would be that Interix/Cygwin began development around the same time, another would be whether the developers would be receptive to development efforts by Microsoft, another might be legal concerns and all the usual licensing crap, but perhaps most of all, the way they accomplish their functionality is very different. Cygwin provides a POSIX implementation and Unix-like environment _ON TOP_ of the Win32 API. This is done through a DLL (cygwin1.dll) which translates POSIX calls into Win32 calls which in turn call into the NT Native API. Interix by contrast does not use Win32 at all, but runs directly on top of the POSIX subsystem, thus, Interix apps go POSIX Subsystem -> NT Native API. Of course, you still have to use the Win32 API as that's what the Windows OS is primarily built on, but the POSIX subsystem runs alongside it and Interix on top of it. This is indeed the point of the NT Native API and much of the NT design; the Native API is (as the name implies) the base API for the NT OS and environment subsystems run on top of it providing an API for client applications. The Windows API is one such subsystem and the one that 99% of people use, POSIX is another, Win16 is another (I think?), and in the past there has been a (fairly crippled) OS/2 subsystem, and possibly others.
This affords some unique functionality for Interix in that it can do things at the API level that the Win32 API doesn't really support, simple example: fork(). The Win32 API to my knowledge has no real fork() equivalent, however, this is supported by the POSIX subsystem. The reason is that the Native API does support fork() but does not expose it through Win32 (but does through POSIX). Clearly, the Cygwin developers have worked around this, although how they've done it I'm not sure. Perhaps they translate fork() calls to loose Win32 equivalents? Or they call directly into the Native API (possible, but strongly discouraged)? Whatever, my point is the implementations of these two environments are very different, and I suspect they offer varying functionality as well as differing in actual POSIX implementation. I gather there's quite a nice Interix community, and Microsoft has put a
FYI: Microsoft commits to support the version of IE that ships with "x" Windows release for as long as "x" Windows release is supported. For example, IE 6 was shipped with Windows XP and so will be supported until Windows XP ceases to be. What this means is IE 6 is guaranteed to at the very least receive security fixes and limited bugfixes until sometime in 2014 when Windows XP leaves support. Similarly, IE 7 was shipped with Vista and will be supported until Vista ceases to be; contrary to what others may say, this is likely to be a very long time, I'd wager a minimum of 1 decade from RTM.
That being said, XP users using IE 7 have upgraded to it either consciously or via Automatic Updates and Vista users I suspect are far more likely to have Automatic Updates enabled as the OS has the functionality baked-in from RTM and aggressively encourages the user to enable it. So, while it may be supported for a long time, its userbase may shrink rapidly in contrast to the glacial decline of IE 6.
The lack of the tiny telnet client binary in the default install is admittedly infuriating, not to mention that it takes forever to install through optional components, which I can't figure out.
Suggested solution: Just use PuTTY. It's small, free, and supports Telnet and various other protocols fine, despite the fact I suspect nearly everyone uses it purely for SSH.
Did you read my original post?
Whether it's sensible engineering to have the kernel handle this stuff is probably a far more interesting and valid argument.
And yet, Apple's default browser Safari has a pretty terrible security record, the latest OS X release contained a bug that nuked account data, and OS X consistently falls behind both Linux and Windows in defence-in-depth security mitigations. While Apple might like to boast about its operating system security, this doesn't appear to be due to any particular "hardened" design versus other mainstream operating systems and in fact lacks solid implementations of various security features that have been standard elsewhere for a long time, rather, it just doesn't seem to have had a lot of exposure to those who would exploit it. If you were posting from a OpenBSD box I might hesitate before replying, but OS X is just another mainstream OS with a broad audience and plenty of holes.
So, I'd suggest getting off your high horse. All operating systems have their bugs and security exploits, and ignorance of your systems security record and capabilities does not make it secure. Also, excessive smugness is not an endearing character attribute.
Minor correction:
This isn't necessarily limited to EOT fonts, but is a flaw in the font parsing code in the kernel in general. EOT fonts are just the exploit vector as specific to IE, but other font types can be used for less likely exploit vectors, such as TTF fonts in a Terminal Services setup. The point is this is a flaw in a kernel system call and IE's use of this system call + default settings makes it vulnerable to exploitation.
Anybody else think something is integrated with something else in a deeply, deeply wrong way here?
No, not really, at least, not in the way you're insinuating. The Win32k kernel mode driver is essentially the major component of the Windows kernel responsible for kernel-mode graphics related processing. Put more succinctly by MS from the MS09-065 security bulletin:
Win32k.sys is a kernel-mode device driver and is the kernel part of the Windows subsystem. It contains the window manager, which controls window displays; manages screen output; collects input from the keyboard, mouse, and other devices; and passes user messages to applications. It also contains the Graphics Device Interface (GDI), which is a library of functions for graphics output devices. Finally, it serves as a wrapper for DirectX support that is implemented in another driver (dxgkrnl.sys).
The handling of EOT (Embedded OpenType) fonts is apparently (at least partially) handled by the kernel and presumably a component of the GDI system. IE supports EOT fonts and presumably just hands them off to the kernel, after all, it is delegated the responsibility of handling them, so why re-implement it in IE? The flaw is not really in IE but in buggy code in the relevant processing. There is an argument to be made that IE really shouldn't be explicitly processing these fonts by default in an untrusted network (and this can be changed in the preferences, but is not the default), but the flaw itself is in the system call code itself; the latter is merely about reducing attack surface in the case of exploits such as this arising.
My point is, this isn't really a case of IE being "overly" coupled into the system (which isn't to say it isn't, just that I don't view this as an example of it). Whether it's sensible engineering to have the kernel handle this stuff is probably a far more interesting and valid argument. Protecting against system call vulnerabilities is pretty tough, as you do expect the kernel to be trusted, indeed, if you can't trust the kernel you have serious problems. A quick google seems to suggest Firefox doesn't support EOT fonts, and I'm not sure if any other browsers do either, but if they did, they may well have their own exploit situations as well.
There should be very little, particularly as the Windows kernel hasn't undergone any massive reworking, however, there are two particularly likely cases:
a) As another poster mentioned, poorly designed software which relies on API functionality that is subject to change. Seriously, Windows software does this all the time, and not just small-time developers, huge software companies (ala. IBM/Google/etc...) have in the past and I suspect continue to use Windows "features" that aren't meant to be used by anyone outside of Microsoft. This typically means using undocumented APIs or API calls that Microsoft does not expect anyone to use, and thus when they change them (which should be fine, no-one should be using them), things break horribly. The other obvious example is dumb assumptions (running as an Administrator is a classic example) but there are many other more subtle ones.
b) Software that installs stuff into the kernel is far more likely to be incompatible without an update or patches (e.g. hardware drivers/virus scanners, etc...). While it's fashionable around here to label Windows 7 as a rebadged Vista (and prior to this Vista SP2 until people realised that Vista was about to get a second SP), the Windows 7 kernel has undergone some significant changes. One was alluded to here just recently. For those who care, Mark Russinovich has written (several?) articles on the Windows 7 kernel changes and various video interviews are available (on Port 25?). While the Windows kernel driver framework hasn't undergone significant changes (which was the primary reason for the seriously crap driver situation on Vista for quite some time), there have been changes to it and many modifications to other parts as you'd expect.
I obviously can only guess on the reasons for iTunes/Google Toolbar being blocked during the upgrade process, but if I were to place a bet, the Google Toolbar might have compatibility issues with the version of IE in Win7. Even though Vista has IE8, it won't be identical to that in Win7 (even if it may be aesthetically), and this can have potential ramifications for browser plugins. As for iTunes, it's a bloated piece of crap that consumes insane amounts of resources (at least on Windows) and has been known to do bad things to the USB stack. It wasn't too long ago XP machines were blue screening due to a buggy iTunes driver (painfully ironic while Apple is playing ads poking at Windows stability, while actively contributing to its lack of) and just recently I found a nasty handle leak that resulted in iTunes consuming several thousand handles a day and not releasing them, I managed to get it to just shy of 30,000 within a week. Would I be surprised if iTunes were doing stupid things that would cause incompatibility during a Windows upgrade? Not even slightly.
Apparently I'm a troll, because my opinion differs from yours, but oh well:
a) The actual article doesn't in any way make it out to be "very little trouble" (the exact phrase used was "not a large obstacle"), and considering it's the very first grievance he points out, I think it should be obvious that it causes a non-trivial amount of trouble. I'm not arguing in favour of a stable kernel API mind you; I'm personally not strongly for or against, I've read insightful and convincing arguments from both sides of the debate. But pointing out that one of the biggest closed-source Linux drivers with a large team of dedicated/experienced driver developers who are paid for their work (and presumably quite well) and are are employed by a large company with significant resources don't find the unstable API to be a large obstacle doesn't exactly in my view prove anything, except that with sufficient resources the problem is manageable.
b) He says the architectural decisions are "quite sound", but at the same time says it's the area of Linux with the "largest opportunities". I'm going to play the Devil's advocate and suggest that he's probably somewhat biased with this kind of assessment, as if he loathed X, I doubt he'd be developing graphics drivers for it. Don't take this as invalidating his comments, I think they are correct, but I'd be more than surprised if he came out and called X a gigantic turd. He _does_ point out that it is highly flexible and extensible, which is to say, you can easily change its functionality and implementation, and others have pointed out, the Nvidia binary-drivers replace a fairly large chunk of the X code in order to work, which doesn't exactly lend to your assertion that X is entirely rosy.
I'll be honest and say I'm no fan of X, it's fairly close to my arch-nemesis on Linux, I just always to have bizarre/infuriating problems with it but that might just be that I'm unlucky/incompetent with it. But, I don't think it's wholly bad; it's been capable of various things for decades that Windows has only achieved in the last couple of years (and other it still can't). I'm just opposed to blanket labelling of opposing viewpoints as trolls.
I've been following this story since it began, and I've got to be honest, I think you've made completely the wrong move and have done potentially serious damage to Mozilla's public image among certain techies, and possibly worse, hindered enterprise adoption of Firefox (and helping to nuke the scourge that is IE6), which I'm sure you'd know is an area FF has struggled to really gain increasing marketshare in.
Getting the preliminary kneejerk stuff out of the way; Microsoft screwed up, bigtime. I don't know of anyone who is debating this. This add-on should never have been silently installed in Firefox at all, period. The best distribution mechanism would have been a manual and entirely separate download that can be installed/deployed en-masse by those who require its functionality.
This is also entirely irrelevant. The damage has been done, and calling Microsoft names or abusing them for their past actions does nothing to fix the current problem (I'm not accusing you of this, but others who've been contributing to this discussion). I can understand the principle behind your decision to add the add-on to the blocklist, but it has some serious issues that I'm astounded Mozilla decided to disregard:
1. It has no regard for patch level. This results in people having patched versions of the add-on (whether they use it or not isn't the point, there's no way you can determine this without consulting the individual user) disabled. You are literally automatically killing functionality in the browser that is NOT a security or stability risk. Worse, you present users with a dialog box which in the case of a patched system is telling an outright lie or serious misinformation to the user with respect to the status of their add-ons. I can't even begin to understand how Mozilla deems such a situation where a significant proportion of the userbase is potentially being fed misinformation by their browser acceptable.
2. This add-on is not to my knowledge under significant usage, but where it is used, it is mostly in the enterprise. Business doesn't take kindly to having programs that they rely on remotely disabled, it causes pain for sysadmins and I don't think I need to elaborate what other problems it can cause that are more serious. That Mozilla thought it a worthy trade-off to potentially protect some of their userbase at the cost of disabling functionality remotely that people may not merely use but rely on for important or even critical computer functions simply boggles my mind. I'm of the opinion it's generally not appropriate to remotely kill even vulnerable software the but I can understand how others would differ in opinion. But taking into account the fact that it kills non-vulnerable versions as well, and that people may depend on it, and that it's non-trivial to re-enable, and I can't understand the rationale.
Put simply, if you don't have the infrastructure in place to reliably differentiate between vulnerable and non-vulnerable versions of the add-on, don't block it at all, it's not worth the problems you're inevitably going to cause, be it ethical (remotely disabling perfectly working and secure/stable software even if not used) or the more practical (as before except actually in use). That, and ClickOnce is also not to my knowledge a popular exploit target at all; this may of course change, but I'd be surprised when there's plenty of other ripe and easily exploitable targets with a larger userbase. If you wanted to go for sheer attack surface reduction, I would have thought there are several versions of Flash that are obsolete with truck-sized security vulnerabilities that plenty of people are running and are actively being exploited right now, that are easily detectable by versioning. I'm not advocating this mind you, but it seems to me there are easier targets if beefing up security through add-on blocklisting is the idea.
Finally, you've re-iterated several times that Microsoft approved your decision. I don't see how this legitimises the decision? I often don't agree with M
I was about to bitch about the submitter/moderator not RTFA, but it turns out, the article doesn't mention it either, so I'll clarify instead: thirteen updates are being released which together address thirty-four security vulnerabilities of varying severity across varying products (ten of which are targetted at Windows). So, that's NOT thirteen flaws (plenty more actually), just thirteen updates, some of which (all?) address multiple flaws in the particular system they are targetted at. Of course, this is just the advance notification, so full details about how many vulnerabilities each update addresses and the general information on them won't be released until the patches are next Tuesday. I think it's also worth nothing (although the summary of course neglects to mention it) that the good aspect of these updates are both major zero-day exploits (targetting IIS & SMB 2.0) are patched with these updates.
And while I'm posting, why does Slashdot insist on linking to shitty tech magazine articles (poorly) summarising the raw and accurate data straight from Microsoft? Seriously, I'm not sure if it's some sort of aversion to linking to MS, but they're the ones doing the patching, so it follows that they have the best, newest, most accurate data on them, and they'll likely be the first to provide updates on their content. These articles are just summarising what Microsoft has published on their various web-sites, and being a summary, they provide a lot more information and raw data:
Microsoft Security Bulletin Advance Notification for October 2009
October 2009 Bulletin Release Advance Notification
I completely agree with you that it's rubbish that Windows doesn't have out of the box support for virtual desktops. It should have been part of Windows a long time ago, at least a basic implementation of, allowing 3rd-party developers to offer more complex and powerful implementations at their own leisure (as is often the case with built-in Windows functionality). Another personal beef is the lack of multi-mon taskbar support, instead having to rely on UltraMon or similar applications.
My point was purely that the APIs to enable this support have been in place for a very long time, it's just Microsoft seems to have no interest presently in using them to create solid built-in support; but other 3rd-party apps use them to create the desired effect. As for your options, you might want to check out this old Ask Slashdot: Virtual Desktops on Windows? discussion; it has plenty of good recommendations.
In a similar vein to the old XP VDM PowerToy (which admittedly wasn't very good), Mark Russinovich has written a nice tool as part of Sysinternals Suite simply called Desktops. It differs a bit from many other virtual desktop apps, but the link explains it well. The result is it has some (possibly very significant) downsides, but there are some advantages as well. I've found it to be very fast personally and by nature it eliminates in my experience the compatibility problems you mentioned.
Proper built-in virtual desktop support really ought to be at the top of the MS's UI priority list, and I'd hope we don't have to wait till Windows 8 for it, but something tells me that'll probably be the case...
Since we, users of Unix desktops, have been using virtual desktops for ages, we don't need to cram tens of windows on each desktop.
What's wrong with both? I'm a Windows user and use virtual desktops, and tend to end up with virtual desktops that have applications that fit into a certain category. For example, programming related fun on one virtual desktop, recreation on another, and so forth... That doesn't mean I don't have a lot of windows on a virtual desktop, quite the contrary at times. Swapping constantly between virtual desktops purely to try and ensure that no single virtual desktop has enough windows to cram the taskbar is in itself just as unproductive, if not more so; I'm sure I've read studies that scientifically prove this point.
Simply, the new taskbar is quite a nice step forward from what I've seen, and just because your current paradigm makes crammed taskbars (or alike) less likely, that doesn't mean that an improved taskbar should be shunned for no express reason than the fact that the problem it addresses is less likely to be personally encountered by you. Add in the progression of Linux moving into the mainstream of desktop computing with distributions like Ubuntu, and you'll find that many of your target audience will be _very_ confused by the notion of multiple desktops, and an improved taskbar such as that in Windows 7 is a far more intuitive solution (for most typical users that I've seen) while still being effective.
Traditional Windows users don't like virtual desktops. I never understood why. Couldn't do without them myself.
I think it's not so much the "traditional Windows user" but more just the "average user" irrespective of OS. As mentioned above, it's conceptually a bit hard for typical users to grasp, or at least, that's been my experience. It complicates the usage of the computer for them, and I can understand this perspective. Also, I'd argue you really need to be using hotkeys for the full benefit of multiple desktops to rapidly switch between them, or the actual time saving from moving the mouse to whatever control you need to use to swap the desktop (system tray in the bottom right usually) and then finding your target window on the new desktop is going to be barely faster than finding it with a single click in a cluttered taskbar. Average users rarely care to learn more than a very minimal set of keryboard shortcuts.
Honestly, Unix users probably use them more simply because the average Unix user is far more knowledgeable about computers and their usage than the average Windows user. It's (although slowly changing) a computer geeks/hackers OS; Windows has a much broader demographic. I'd be interested to know what the picture is with OS X with respect to the above?
PS: The snipe about Unix users using multiple desktops for ages is unwarranted. NT (and 9x?) has supported multiple desktops since the dawn of time via the Windows API, but the OS has never included a built-in tool to harness them for the usage of multiple desktops. Multiple 3rd-party utilities exist to address this, and I've been using them for probably over a decade now, as do most other Windows "power-users" I know.
This guys particular tale of developing this software, patenting it, going to court against Microsoft over the (now overturned) infringement, and present day life was actually recently covered in an episode of Australian Story. I remember watching it and not coming away particularly impressed with Ric Richardson by the conclusion.
I'll be honest and state I haven't read the patent in its entirety, and so I could be entirely wrong about this, but the impression I got throughout the entire show was that it's just a fairly generic patent that covers what most today would refer to as "Online Product Activation". Microsoft has used such a scheme since Windows XP as most Slashdotters would be aware, but so have countless other software programs and associated corporations for protecting their proprietary applications. To be fair, he did develop this technology quite some time ago before OPA was in any way a standard or at least regular affair, but that doesn't in my view legitimise it. I can't support patenting abstract program technologies.
I'll withold judgement until I actually bother to read or learn about the real contents of the patent in its entirety, but if it is of the generic type, and I distinctly got this impression, then I have to say I'd probably come down on Microsoft's side. Which is tough, as they don't exactly have a pristine past on responsible and ethical usage of software patents, but that doesn't permit me to be hypocritical, and this guy is nothing more than a "patent troll" if the patent is as vague as I've been led to believe.
That, and if you watch the particular episode (I'm unsure if it's available for streaming outside of Australia), you may well find that you pick up a certain vibe about this guy that he is quite patent happy, but I might just be overly biased.
No, I take the view that's $40 million AUD that could have been spent on actually bringing the creators of genuine child pornography to justice, rather than a filter to stop people from viewing the end result of the real original sin. The hard reality is, people who want to view this material are always going to be able to access it if they really want to, filter or no filter, and this money does nothing to stop the problem at the source; just maybe a few people from seeing a video that shows the (in my opinion) far greater crime.
.
I agree with your post in principle, but I just thought I'd point out that the argument that guilt is not hereditary is often used in the wrong situations. An example from Australia would be the relatively recent apology to the Aboriginals (our indigenous population) for their mistreatment by past governments. The former Prime Minister, the (dis)-Honourable John Howard, used this exact argument for the over a decade he was in office, and somehow, completely missed the point of the argument for an apology in the first place. Nobody was claiming that he or anyone else was personally responsible for the mistreatment, but rather, that the apology would officially _recognise_ the past mistreatment. Our current Prime Minister, the (only slightly less dis)-Honourable Kevin Rudd
recognised this and made an official apology.
Thus, it is of historical importance, and by extension of moral importance. Until the apology was made, the government had never, ever, officially admitted their past wrong doing, and by doing so, they effectively go a long way to closing a past chapter of Australian history that is less than pleasant, so that the majority can move on. I'd suggest something similar is what is at work here, recognition of Alan Turing's mistreatment officially absolves him of any wrong doing. I'm not saying I think this is necessarily worthwhile, but I also don't believe the motive for doing so is in anyway some ill-conceived idea based off the notion that guilt is hereditary. Further, stating that an apology is only appropriate when you are personally responsible is simply not accurate. When someone tells me that a close friend has died, I'll tell them I'm sorry to hear that, but I'm in no way admitting I was responsible for their death. It's purely an indication of my sympathies; an apology for Turing is similar in concept. I really do find the notion many present that seems to me to indicate that apologising is either an admission of guilt or an admission of weakness (or both) very quaint at times, and says a lot about that person. Admitting something in the past was wrong that you have even a historical connection to, is in my view, a sign of strength and intellectual wellbeing.
Only just noticed you were replying to a (hidden) troll, which changes the tone of my reply a little, but the point about applicability of fuzzing tools is in my view still entirely valid. Sorry about my remark that you rushed out to change the conversation.
Hey man, you did "adobe xml vulnerability" twice!! Admittedly, their security record is appalling, particularly as of late, but still, play fair ;)
More seriously, an article comes out about multiple XML vulnerabilities in multiple open-source XML libraries and your immediate reaction is to rush out and try and shine the light on XML vulnerabilities in closed-source code?! How about you first wait to find out the severity of the exploits in the open-source software, and equally importantly, how long they have been in the source first, before you try and divert the conversation? Further, the exploits weren't found by the project authors, but by a security vendor who applied protocol fuzzing tools. Fuzzing tools operate on the binaries, and thus, the source code is irrelevant, you can run these tools on any software irrespective of the source-code ideology behind it. Where the open-source aspect may come into play is largely in patch response times, but the argument that they may have been found quicker in closed-source software is in this case unsubstantiated, and especially tenuous considering the mechanism that found them is equally applicable.
Of course, they might turn out to be entirely mundane, as the specifics of the vulnerabilities have not been disclosed, and security vendors tend to exaggerate the severity of any given vulnerability they find. But still, have you considered fixing your own house before immediately running out to abuse entirely unrelated software? It might not be long before someone is wondering about various vulnerabilities in open-source software. Some restraint is useful considering the complete lack of solid information.
Without a legal means to enforce that the code remains in the open (ie. open-source), how do you intend to ensure that this remains the case? What's stopping someone from just taking it, improving it, marketting it, selling it, and never releasing the source changes back to the public? There's no legal deterrent, or, any legalalese that says he can't, so why not? The license is irrelevant here, if it's an open-source license, you need a means to ensure that it is enforced; that's copyright. And if you want to place any sort of restriction at all on your code, no matter how mundane, you need a license; even some of the most permissive licenses (e.g. BSD) still have restrictions, for example, credit where credit is due in the example of the latter.
Despite being present in the preview, the hyperlinks were stripped for the new Vista/7 features when I submitted, so here they are again:
Features new to Windows Vista
Features new to Windows 7
Okay, so I'm on XP at the moment... Just what incentive is there for me to upgrade, exactly?
I have to admit, I'm getting really tired of people asking this often rhetorical question about Windows releases, as it only indicates one of the following things:
* The poster is incapable of doing their own research to find the answers to incredibly basic questions
* The poster has found the answer but feels the need to post the question regardless probably to elicit a certain response
Seriously, you want to know what the incentive is to upgrade? You get all of the features new to Windows Vista and all of the features new to Windows 7. Now, if you can read all of that and legitimately tell me that you find no real compelling reason to upgrade, then that's fine, I disagree but I'll accept your view, and more importantly, you've answered your own question.
Realistically, many people will get extremely enthusiastic over the latest Ubuntu release despite the fact it's only 8 or so months since the last release, and while it provides some useful new functionality, the overall changes are a fraction of the massive overhaul that Vista received and that Windows 7 incrementally improves. Mind you, I have no problem with this either, but it does boggle my mind that someone can either be so ignorant of what a new Windows release contains or so inept as to be unable to find this out.
The rest of your complaints are really just an assortment of mundane issues and unrealistic expectations, I can't be bothered addressing them all, but a few picks:
1. If your PC only just qualifies to run Windows 7 then it's probably pretty old (I link to the Vista reqs as 7 reqs are not yet finalized, but are rumoured to be the same, and the general consensus seems to be it is both snappier and less resource intensive than Vista anyway). None of these requirements are exhorbitant, and while it's a favourite past-time of many Slashdot posters to insinuate that Vista needs an absolute beast to run smoothly, this is far from the truth. What it NEEDS is a relatively modern machine, your XP machine purchased in 2002 is not modern. I wouldn't expect to run the latest Ubuntu smoothly on 2002 era hardware, if at all, and similarly, I don't hold Windows to a different standard.
2. Upgrading 98 to XP is not as big a task as you'd think. Yes, you're moving from a 9x system to an NT system, but keep in mind that much of the codebase was shared to an extent (e.g. IE/DirectX/WMP), etc..., and the release of XP and 98 was only about 3 years apart assuming you were using the first edition of 98; if you are using the second, you're down to about two years. In contrast, an upgrade to Windows 7 from XP is not only EIGHT years newer, but a massive overhaul of the underlying NT system. And honestly, as many have stated in this thread, you shouldn't rely on major OS upgrades without a fresh install to be reliable or even stable. You're welcome to give it a shot, but you should not expect everything to go right, and a clean install will almost always deliver better results in the long run, even if it requires more effort to be invested initially.
3. What interface tweaks do you lose that you can't duplicate on 7? Do you use every feature in XP? Do you realistically expect to use every feature you gain in any given OS upgrade? Is it really that hard to backup all of your programs and data? For christs sakes, take some initiative and figure these things out for yourself, and if it isn't worth the effort, then don't upgrade, no-one is forcing you to.
Is it really that hard to do a little research rather than run to Slashdot to have people answer things for you?