Now I run a separate hard drive with Vista (because I just can't afford to use it as my primary OS, it's still too crippled in too many ways), but I need >4GB of RAM for my work This I keep seeing, but keep wondering, didn't the 32 bit windows offer PAE? I know you were still left with a per-process memory limit, and that PAE imposed some penalty, but in the aggregate I hear that per-process limts aren't the concern, and wonder really how much a penalty PAE was compared to the general issues with Vista people keep reporting. It looks like a/PAE switch in boot.ini, but I can't really check that from linux systems.
If you have a choice in the first place of not having a smartphone at all, or having one, then you should have a more full range of choice, and be able to use that to your best advantage professionally, but at the same time having the discipline or backbone (whichever is applicable to the person) to shut it down/ignore it as if you didn't have it at all when appropriate.
I think some people get too wrapped up in their work and absolutely need to know how to cut out and enjoy the rest of their lives. But even for them, a smartphone/constant access can be a good thing, depending on how overboard they are. Take for example on guy at work with a family I know. He feels he absolutely *must* be there, and will work from 8 am to 11 pm *frequently* (and is salaried). His wife will call and complain to him, and he says he just can't pull himself away. For someone like him, maybe he'd be working all hours of the day still, but at least be at home. He is someone who at least outwardly expresses he wants not to be at work, though who knows if that is his reality...
Others are at risk who normally leave work, but don't have much backbone. If they have a *hard* excuse (I'm in a bus and can't possibly reach what you are talking about) they can get out of being overused. However, if they could easily get in from a technical standpoint, and they are left without a hard, physical fact to preclude them from doing the job, they can't say no.
Personally, I feel I have a good balance down. I leave work no more than 10-15 minutes late, with the *rare* exception of an hour if something is really bad. I work from home in off hours maybe 2-4 hours over the course of a month, with no more than twice a year logging in on Saturday to do something in full. But I know when to disconnect and not look at all, knowing if something was so critical, a *human* will somehow find a way to call me, which happens rarely, and that rare occasion is when I can triage it and still either take no action or redirect to someone else if I so choose. Anything else I don't know about can always wait until my next business day.
Of course, I don't have a data plan at all, but I don't think I'd be using a smartphone form factor to do my job to any significant extent, it's just not a job feasible for that usage. And most of the time I have full internet access throw my laptop somewhere anyway, and when I don't I'm probably either driving, eating, in a theater, or some other place where I couldn't possibly be productive, so I couldn't do anything anyway, so I can confidently say a smartphone wouldn't change my work habits one iota
In modern terms, I think not having X11 as the primary rendering platform goes against the current perception of 'Unix', though not technically. I think the common usage/higher level apis is as important as the mere core Unix behavior dictated by the Unix certification. In the past days of NeWS and such, etc, there was no immediate winner, but there was no established thing to compete with, so nothing would seem 'un-Unixy' at the time. Now it's been nearly two decades with X11 as the clear GUI implementation of AIX, Solaris, Irix, HP-UX, et. al., as well as not-quite official FreeBSD/NetBSD/OpenBSD, and the universally accepted unix-like Linux platforms. With the X11 layer, they can run applications relatively nicely, but the end-user experience is degraded by having two concurrent, vastly different usage experiences set before them, with the NeXT inspired applications taking front seat. If you are remotely serious about the OSX platform, you will produce a 'real' port using Cocoa. I would consider a Unix-y app to be equally at home in FreeBSD, Linux, and Solaris, whereas in OSX, an application with a mere recompile won't look right.
Of course, the whole 'Unix certification' thing is overrated. OSX is a good platform and benefits well from the Unix kernel/libc underpinnings, but the precise certification versus 'close enough' is of nearly no value to end-users or developers like. It let Apple rapidly get a mature modern core to build on, but other than that it's kind of a moot point. Just something for pedantic geeks to hash to death.
horribly designed and whose implementations were buggy and broken, X11, I don't know, I think while during the XFree86 reign, progress was impaired to make the state of X11 seem artificially stunted. When XFree86 changed the license and that leadership officially became relavent, I think the Xorg project has shown exactly to what extent X's extension architecture could be used to correct long standing criticisms. Now high-level APIs and facilities exist to give equitable features and performance, all the while maintaining the ability to forward transparently over the network, something that Aqua/Quartz didn't implement. Though displaypdf, like displayps before it, certainly makes printing a bit more trivial.
I do agree that particularly sense higher level graphical APIs are not part of the Unix status, shooting for mere Unix compliance isn't as constructive as it once might have been. I'm not sure I can concur on the accusations of horribly inconsistent and fundamentally broken aspects, as I don't really see it. As the quote goes "Those who fail to understand Unix are doomed to reinvent it, poorly".
I can think of a couple, but the same is true in the reverse. Both OS X and Vista have features that have not made it into Linux distros yet.
That's true. Were it not, this debate would not be possible.
Linux package managers lack the ability to handle Web and Bittorrent downloads or software registration, so commercial entities buy installer systems that do handle those instead. Commercial software is not only not kept up to date on Linux, but installation generally requires you to run a random binary and uninstallation is a mess.
Well, first there is the distinction between 'package management' (managing what owns what and what needs what, but not downloads and repository management (the ability to track versions of aforementioned packages). I've seen commercial linux software provide rpms with license acceptance programs/registrations that must be done before the application will start (it will warn you when you try to use the software, in addition to steps taken during %post). I haven't seen an rpm go interactive yet, but I know for a fact the.deb packages can get interactive with a user, and present questions in a way that's abstract. Good examples of commercial software packaged is most stuff from IBM, notably GPFS. If it isn't an rpm and branded IBM, it's probably a branding of a third party package.
In terms of downloads and such, absolutely they handle web downloads (kind of the whole point of repository management), even supporting authenticated downloads (I've installed commercial software that required a valid account to get at the repository). I don't think I've seen bittorrent support in the repository manager, but I've also yet to see the likes of InstallAnywhere do such a thing either. The point is, the framework of yum/apt is actually adaptable to commercial use complete with license acceptance and authentication restricted repositories, it's just most companies don't understand it and end up abusing the situation, sadly. Though not restricted, Adobe provides a yum repository for flash plugin. Now, I know AIX package manegement takes licensing to the utmost extreme (won't install a package unless the package stated license has been agreed to by the administrator for some package or another), but generally speaking, you can control license acceptence/registration through an authenticated repository or by run-time interlock (lot's of IBM packages demand acceptance of a license under linux when you try to run it). Unfortunately you are right, the reality is that the bulk of the commercial linux world doesn't adopt the repository management for some reason or another, but at least the underlying distribution provides such a feature, so the blame can solely be placed on the application vendor rather than the underlying platform.
I sometimes fear Linux will never make any large improvement again, simply because there is no one who can make a decision to make a big change.
The great thing is, 'Linux' doesn't have to do anything. Canonical, or RedHat, or Novell, or whoever, they are all communities that can change things without every other Linux platform adopting, and the free market can decide. Yellow Dog came up with yum, and Debian with apt, and they propogated from there. They continue to compete (because RedHat refused to adopt apt-rpm for some reason), but they have emerged as the overwhelmingly dominant package managers that serve >90% of users default repository management, and the remainder (i.e. gentoo) can use either of the two in a more manual fashion or their own wrappers.
In any event, Apple and Microsoft don't provide any facility for repository management, so they receive the blame rather than the software vendors.
Whaaa?!? Umm, the only things that require an installer and can't be drag and drop are things that install kernel modules. Even MS Office is drag and drop. Some software does use installers, but mostly so they can install DRM or manag
Xerox established the beginnings of the technology, and the concept of using multiple panes of information on the screen to simulate paper. They by no means developed any metaphor; the interfaces on the Alto computers were horrendous works in progress at best. Apple created the desktop metaphor in its fullness. But the rub comes when you declare the metaphor to be 'full'. In truth, things have been evolving and playing out. OSX looks marketedly different from the Lisa interface, and conventions have been tweeked by everyone to different ends. Just because the Xerox interface was different (i.e. horrid by today's standards), doesn't mean the step to Apple's was the definitive end of horridness.
if we limit ourselves to the selection of applications that are native to each respective desktop environment, our selection drops to dramatically fewer applications than are available for commercial platforms. Though many people don't bother to track, if you consciously look at things, making a distribution that completely ignores things that don't fit into the Gnome environment is not as restrictive as one might guess. The practicality of such an endeavor is questionable, however, because the world at large have proved that even without meticulous adherence to an incredibly specific HIG, people just aren't so stupid as to be confused by the minutia, though consistent file dialogs and menu hierarchy conventions are useful things at the more coarse level a HIG provides.
"We're doing it too" isn't good enough. You have to be doing it as well, or better. Linux based desktops do not succeed when tested on the general public. Most end-users are completely lost even after extended use. What studies and what environments back it up? Anecdotely, I'm aware of numbers of cases of a grandparent being given a live CD by someone fed up with supporting their Windows install, and not having to worry so much anymore. Granted, the benefit there is a customized environment they can't screw up to the point a reboot won't fix, but they don't find it overly daunting. Windows isn't fundamentally more straightforward (though people are by now acclimated to it's pecularities), and it does fine in the market.
Centralized package management is a pretty minor concern. A user installs what a user wants, whether they have to navigate through an "install wizard", drag and drop and appfolder, or figure out how exactly Synaptic works, and what all those interesting Debian package names really mean for their desire to organize their photos. Well designed apps will check for updates, poorly designed apps won't. I don't think I use a single Mac program that doesn't check for updates on launch at this point. I must absolutely disagree on this point. Some things are more service oriented, therefore checking only at startup may not make sense. On the other end of the spectrum, some applications are opened very frequently, and thus a simple approach would hammer the update server. Without a standard platform method of accomodating this, each company must re-invent the wheel and figure out these tradeoffs all over again As you say, a well designed application will, whatever it takes, provide an update mechanism, but the problem is the platform not providing a consistent method and interface is a problem not to be ignored. For example, on a random Windows box I had to help with, things were a mess. As I manually updated a number of applications that had no facilities, I noted that Steam, Apple, Microsoft, Java, and a couple of others *all* had update managers running in the background, and all of them interacted with the user in different ways and independently demanded the user's attention. For all the fuss made over the need for a highly precise HIG, the state of software update management goes against those goes without a flexible, central update manager with third party hooks.
WAY too much bloat for features most never use. Real men use dash (if you *must* have a program that's a shell and only a shell) or if you don't mind something a bit more versatile to save disk space at potentially the risk of slightly higher memory consumption when all you have is a shell, you use a symlink to busybox for your shell. But not with that glibc cruft mind you, uClibc is the only path to efficiency.
Also, you don't use init, you have the kernel run the aforementioned shell directly instead. Who needs all the cruft of startup services and a well set up tty, after all.
The author, as such, appears to have slept through the last 30 years, in which the original Macintosh established the desktop metaphors Microsoft poorly reimplemented and Linux re-re-implemented many many times over.
By that reasoning, nothing is as good as what Xerox has, because they established the fundamental metaphor first. Nevermind they didn't take that project out of the prototype phase themselves, they must know better than Apple because they did something with a mouse first. It's simply not accurate to say ideas cannot be built upon and improved by anyone other than the first. The first one to establish something doesn't *necessarily* follow the most prudent evolution of the ideas. What the state of things 30, 20, 10, or even 5 years ago isn't automatically overriding of the situation of *today* (though certainly heritage influences the current, hence Microsoft being able to moderately screw up and lag in innovation and still maintain a lead).
As to the statement that there exists no meaningful HIGs in the *nix desktop world, that's just not true. Gnome and KDE both have their own HIGs, and if you stick to that software, the HIG is consistently obeyed. Ubuntu by default presents a pure Gnome environment, and generally you have to pick something out special to deviate. OSX and Windows are not immune to this. In OSX, if running an X11 app, it sticks out like a sore thumb and almost certainly doesn't follow the Apple HIG. Even without X11, some companies like Lotus release software that doesn't follow the HIGs (Notes looks equally hideous and out of place on all platforms). The point being, you can't fault a wide architecture for giving choice, and compare it against a specific implementation. You must compare a distribution to OSX. If you said Apple lays a better framework than Gentoo for a coherent HIG, then I'd have to admit it. Among the various Ubuntu flavors, each has picked and preferred a HIG. OSX, Windows, and Linux platforms can all be subject to misfit applications that refuse to obey HIGs or even use the most common toolkit. The following behind HIGs in the Linux desktop world is not so small as to be counted out.
Try not to state subjective experiences like snap-to-screen-edge or focus-follows-mouse being far more efficient when this clearly can only be true for you.
Obviously, it can be true for more than one person, but I think you must have misspoken, that sentence didn't parse to my eyes. The power to do these things in a relatively standardized way is not a bad thing, however you slice it. Windows can do focus-follows-mouse, and no one accuses them of trashing the user experience because of it, and subtle edge-resistance isn't going to hopelessly confuse someone not expecting it, and certainly a non-default option of it won't.
Ubuntu just as good? No. Free software just isn't there yet. If it were, Dell, HP and Acer would have dumped Microsoft quite some time ago in the home market. People want cheap and easy. Not necessarily good, just cheap and easy. Linux doesn't even qualify as that yet - the market has spoken as always.
By your logic, OSX 'just isn't there yet' either, because the market en masse hasn't ditched Windows entirely. The market reality is that an intrinsically better platform is *not* going to automatically win over the market magically. The market reality is one of a great deal of maintaining the status quo. Microsoft from a business perspective got their product out there in the most accessible form early on, and because so many people use windows, so many people will continue to use Windows, even if you can claim it to be worse than the competition. Application developers are in the same boat, they target the platform that is popular, helping to contribute to a deadlock of microsoft. Microsoft's technical work in the mid 90s was on par with the Mac experience, and the Linux experience was no where to be seen. By the time OSX and Linux could be argued as being superio
I agree that he knows not what he says when referring to the technical details of the aspects of OSX that make it Unix (the core c library, various APIs, the startup process behind the scenes, all the underpinnings that the Quartz system really needs to get going, and more).
However, I would say I wouldn't expect anyone to figure out OSX is a Unix without being explicitly being told so from a few minutes of using the platform. You have to observe how the startup process works underneath the pretty graphics (which is non-obvious by Apple design), you have to see the header files documenting the library calls. You must observe details of the filesystem hierarchy that are obscured/altered to Apple's best efforts as they perceive more mainstream Unix structure as confusing. Even if you start developing, the documentation is pretty Cocoa-layer specific, rather than discussing at length the more core Unix apis. The fact that by default you can start a *nix looking shell is a good hint, but without further detail, that could either accurately reflect it being a Unix or Unix-like system, or it could reflect bringing a Unix style interface to a non-Unix (i.e. Cygwin would not make Windows Unix or even Unix-like, and in fact cygwin sees the filesystem in a way that does not map well to the 'real' filesystem layout, so no matter how Unixy it looks from the shell, you can't easily be sure it's not just a trick).
Technically speaking, X is not Unix. Practically speaking, outside of the Mac/NeXT world, *no* Unix platform has a GUI that *isn't* an implementation of X11. With the exception of GNUstep, those APIs simply do not exist in modern *nix systems outside of OSX, and GNUstep is a rarity application developers simply do not risk requiring (with exceptions that specifically want to recreate NeXT intrinsically, and not use it as a means to an end). When targetting NeXT, Cocoa, Carbon, or *even* GNUstep APIs, the 'Unix' aspect of it is not the primary concern. They consider themselves to be OSX/NeXT/GNUstep applications, without caring what lies beneath. A good many of them remain Motif based, ugly as that is, because even GTK/QT they don't consider ubiquitous enough (and it's cheaper not to bother for old codebases).
Yes, an X application can run on a remote X server, but the platform executing the binary still *must* have the X libraries, so the distinction is moot to this discussion. Before bundling/having X11, Apple had no X server nor libraries in terms of first-party support. Considering the overwhelming majority of Unix applications that people specifically care about require X11 *and* are not Step derived, the lack of X11 server/libraries was a very practical obstacle to being usefully Unix, as opposed to being technically a Unix.
Though I think being 'UNIX-based' literally is overrated, you can't claim to be based on something that you didn't actually build upon. Just because a window manager theme looks like Windows XP, doesn't mean it's 'Windows-based'. You can say UNIX-like, or Unix-inspired, but Unix-based is totally inaccurate.
For linux, technically speaking, you are right, it isn't derived from any code that can be called 'Unix' and carries none of the certifications, and probably wouldn't pass the certifications as is. Pratically speaking, the linux kernel+GNU userspace is clearly Unix inspired and architected such that a Unix user is certainly familiar with the situation. GNU particularly makes clear the distinction (GNU's not Unix after all). Unix-inspired may be a more precise term.
OSX is to an extent the exact opposite. Technically speaking, it derives from BSD code (actual Unix code). Technically speaking, it implements the appropriate APIs and can run a program that runs on Unix. I want to say even before X11, Apple legitimately got the Unix moniker to describe their platform, but I recall there being confusing around this point. The addition of X11 out of the box makes it more complete, and less of a technicality. However, the fact of the matter is the extensive use of a non-X based graphical architecture and the almost universal situation is that NeXT derived APIs are used and required, and the underlying pieces that are true to a Unix heritage are nearly moot. A user accustomed to Unix will find OSX fundamentally different.
Technically speaking, OSX has a valid claim to being Unix, but could be accused of not necessarily being true to the 'spirit' of Unix. Linux is absolutely not a Unix, but on the other hand, people can certainly fairly claim Linux to being true to the spirit of Unix.
Why of course, so you can post a comment on slashdot saying "told you so", duh.
But more seriously (as a almost pure user of *nix architected systems now), he never said that the transition will be made any less painful as time passes, or that it's necessarily that painful to be on Linux now despite the market situation of Microsoft. Depending on your usage patterns, running a Linux platform may not be painful at all right now. Specifically, apart from the commercial game scene, most home usage is well served by a modern Linux distribution now. Whatever pain there is to be endured in the future, he endured that pain already, and his experience probably lacks pain today. Meanwhile, (also speaking as someone forced to use Windows on occasion), the Windows experience can be painful once familiar with the power and flexibility a Linux distro can provide, depending on the type of user you are. So you can be glad to be away from the whole mess and be an observer for those who endure it. *Particularly* if his prediction is right and the market moves to a non-MS solution, you know it will only because the market is painfully forced too, and microsoft users would suffer the most by not being prepared for such a switch. Not saying his prediction is accurate, but that's the implication that would be the case were it true.
The thing that's really troublesome here is, I don't think the person writing the article would care to mention that detail, at least not outside the ports IIS serve users on, which are the only ones he thinks matters. On the externally available ports that should be publicly available, there is *zero* applicability for stateful rules, particularly when you have external parties already tracking obvious DoS for you. For other ports (for example a port out of the IANA range), I wouldn't be surprised to find out they do have stateful inspection to allow traffic associated with an outbound connection in. The problem being their networking equipment might make it a transparent default. Of course, if they are running 100% microsoft software bottom to top, they may never even need to contact an external update server and forgo that entirely, something >90% of the world can't do, and is still a moot point with respect to how 'bulletproof' their server setup is.
In order to apply the 'ACLs' they describe, they *have* to inspect the packets, by definition. They may only compare a relatively small number of fields (src ip, dst ip, make sure it is a TCP packet *and* the destination port is 80). They might not make use of any logging or stateful inspection (then again, stateful may add next to nothing, so long as they don't need to contact external servers for any updates), but that doesn't mean they can get away with saying 'look, no firewall!' All he's saying is that port 80 (and maybe a few other hand selected ones) are 'wide open' (except something else blocks DoS for them even on those ports). Honestly, I doubt you'll find many public web services that puts a more restrictive 'firewall' than MS just confessed to having in an article where they declare 'no firewall!'
Router ACLs are in place to block unnecessary ports Cisco Guards for DoS detection and automated response In other words, they don't use firewalling where you have administrator defined rules to control traffic flow, they use networking equipment that accept administrator defined rules to control traffic flow.... totally different..
What in the world do *you* perceive the difference being between a 'firewall' and a router blocking ports based on source and destination being compared with a set of rules (aka ACLs)? Generally, firewall rules *can* get more complex than that, but mere port blocking by an intermediate router has been considered a firewall, even if it doesn't log violating or accepted packets, even if it doesn't have complex rules about connection state. Even if it doesn't have the word 'firewall' emblazened on the chassis somewhere.
are going to start realizing that you simply cannot make a flawed architecture run any better by adding more duct tape to it. I dunno, some of the 'problems' described sound like maybe, to some extent, MS was attempting to go beyond duct tape with respect to their atrocious security situation, where if you have an account on a system, you can alter entirely too much about it. The problem with doing that is applications that designed themselves with that (and they hit the same sort of breakage in a coarser way when people were moved from the 9x architecture to XP, for certain account setups, which is why to this day most users give up on running a normal account without administrator priveleges). When XP rolled out, many developers were in the habit of writing things saved by the user to it's 'program files' directory.
Now it sounds that they are accustomed to having a program run by the user manipulate things at a higher level directly, and that somehow Vista disallows that, ostensibly to mitigate the risk of the very malware anti-virus targets. One wonders whether the best long-term idea for the end-user is for Vista to relax their default security policies, or for companies to handle privilege escalation in a more secure fashion. *nix programs have dealt with this situation since inception, and haven't had to fundamentally revisit program designs in order to accomodate any radical security overhaul attempts. In recent history, things like AppArmor and SELinux have *certainly* caused a lot of grief to admininstrators trying to use it for the first time, but both are about allowing common applications to do *precisely* what they are expected to, and everything that they are expected to without redesign, but nothing more. Occasionally while tweaking such policies, developers realize a boneheaded security move they made and tweak it in an update. Quite frequently, administrators have to put more work in to setting the contexts correctly on, for example, files for a web server to serve, or directories for webapps to write to. But the fact remains, the *nix world security enhancements have always been able to perfectly allow 'legacy' applications to work just fine, because the model was never fundamentally broken.
Of course, it does little to change the default resource consumption/perception that inhibits Vista adoption. However, above all, the biggest gate to Vista adoption is no one sees the point of shelling out money when it isn't going to let them do anything new compared to Vista. If Microsoft follows through on the threat of decreased support of XP in favor of Vista without making the transition seamless, they risk pushing customers to alternative platforms. I wouldn't underestimate microsoft, and they always have the XP product that is thoroughly entrenched. They had ME and the consumer world ran 98SE until XP came out. Now they have Vista, and maybe they'll make it successful, or maybe they'll bring to XP the 'goodies' they were trying to bring people to Vista with (i.e. DirectX 10), and stall for another attempt. For the most part, the *common* person's reasons for not going to Vista are the exact same reasons they wouldn't jump platforms, except maybe milder (applications may not run, unfamiliar environment, what they have today suits them fine). I can't imagine any remotely reasonable set of company leadership officially ditching XP until they have absolute confidence that Vista has been successfully adopted, regardless of what roadmaps declare today.
that taking action, in this context *specifically* action against Iraq, was 'consistent' with necessary actions against terrorists/terrorist organizations, specifically referencing those responsible for 9/11. Government speak doesn't get much more blatant than that. It's clearly *strongly* suggesting that action against Iraq is justified in *part* because of 9/11 (in such a relationship, that's only possible *if* the Iraq government colluded with Al Queda specifically with respect to 9/11, and that just simply has not been shown to be a claim based on any real evidence). At least, the links are no more substantive than Bush's links to Osama bin Laden, or to Saddam's regime for that matter. Should we revolt against George W. because he associates with bin Laden family members? Should we execute Rumsfield for shaking Saddam's hand?
I'm not saying Saddam was an innocent guy or that Iraq was particularly good on the whole human rights thing, and therefore deserved to be left alone. However, you don't take a country to war and get the soldiers killed for unsubstantiated claims of WMD and terrorism, that the UN *was* investigating. Before the war, WMD was declared the reason, with mumblings of Al-Queda. When those claims eroded under scrutiny when the effort was underway, they said 'oh, we are freeing the Iraqis then!'. Great, how about those many other nations that have genocide/ethnic cleansings that are ignored? When you take away the terrorist link (they *knew* there wasn't a strong case there), the WMD (they also knew they had insufficient evidence), the only thing separating Iraq from a half-dozen other similarly screwed countries is that Iraq had oil to exploit and maybe made our buddies in Saudi Arabia a tad nervous.
To play devils advocate, the editing person put 'some say' in front of *other* people's statements that he disagreed with. He felt the statements were controversial, and should be somehow rewritten to indicate it isn't a universally accepted fact/provable fact. Now, with the clarification that he was absolutely *not* injecting his opinion, but rather trying to indicate that someone *else* had injected an unsourced opinion/theory he didn't like, he picked an option of softening the language. Generally, Weasel words are meant to get out of sourcing material, but in this case, the person editing didn't felt justified in removing it completely (which would have probably been more controversial), but took a milder step that still may be inappropriate, but not as nefarious.
The last few edits are certainly the wrong place to put the statements. Again, the editor saw text he felt inappropriate to the subject matter, didn't feel right removing it completely, and felt the correct place to debate was in the article text itself, which leaves the article text confusing and counterproductive.
I personally think while the editor clearly had an agenda/opinion that reflecting obviously in his edits (an opinion I think gives way too much credit/credibility to the current US administration), he at least wasn't as overzealous as to delete every thing he disagreed with that wasn't obviously and directly sourced.
Good to have pointed out, the very first part of the first edit in that link was appropriate, removing weasel wording. The second half of the first edit seems bitter and quite possibly blatantly incorrect.
I don't know what to make of the Powell statement deletion. It didn't seem offtopic, and did to some extent weaken the link the person editing obviously believed in, but it also was spun (as it was from a Bush administration person, after all) in a pro-war way, and far more damming, unqualified material is cited in the article than that.
Other than that, despite the effort to correct a deviation on the Weasel Word policy in the beginning, the bulk of the edit from there on out was injecting more weasel words to do just what you suggested.
Of course, if every random wikipedia edit was subject to a slashdot comment discussion, I'm sure a lot worse can be found.
They didn't suggest time actually slowed...
on
Can Time Slow Down?
·
· Score: 1
They suggested the logical thing, that in time of panic/crisis, our perception/thought processes speed up to make it possible to contemplate the situation and take possible action, therefore things that are normally too fast for our normal eyes/mind to process, might be capable of being processed when those systems 'overclock'. Like an adrenaline rush gives us more than typical use of our muscles, something similar may happen to the mind and associated sensory organs.
Their results suggest that during such an event, our minds/eyes don't actually speed up to perceive time more slowly, but rather the mind burns that memory in such that it feels longer.
To quantify with fresh-from-my-ass numbers focusing on visual experience only, presume the normal perception of a given person is about 30 frames per second. The thought was that just *maybe*, the systems boosted enough to perceive 45 frames per second, in the name of gleaning every possible usable detail of the environment before it's too late. The outcome suggests that is not the case. Rather, say we do perceive 30 frames per second, but in the medium/long term our brain records, say, 3 frames per second worth of low detail, as most of that information is useless to us (we just remember the Cliff's Notes version of our lives, and our brain doesn't even process more than that nominally beyond very basic stuff). However, after surviving a situation that felt like it could have been fatal, our brain retains, say, 15 frames per second at a more vivid level into a longer memory term, to remind us of everything that went wrong leading to that so that it may be avoided.
I wouldn't be surprised if a future study proved this one to be lacking and that some perceptual speed up at the moment of panic does happen, but I'm also not surprised if such a perceptual speedup simply does not exist. In the cases where this 'slow-mo' memory occurs, there would have been nothing you could have physically done with your body to leverage anything you normally would not perceive at all.
Defending ones country is defending for land and resources. France on the defense would never have been a war were it not for a foreign entity trying to invade to acquire land/resources. The crusades for the most part was using religious reasons to motivate people to fight to give those in power land. The crusades that weren't about invading were carried out without government/church leadership because the commoners had bought hard into the propaganda used for the other crusades. Note the crusades that were about ideology were rather pathetic and stomped out by the defenders, as the invaders had no power.
Terrorism is a complex issue, but however that debate would go, the fact remains that *usually* at the root of a significant conflict there is an issue of land/resources that is secular in nature.
The overall tone of all the edits were definitely partisan spin, without contributing any facts. However, reading the before and after also makes clear that there did already exist a somewhat opposing spin.
Probably, you can logically argue the injection of 'alleged' phrasing in any controversial point as making a statement more universally true rather than presenting it as true. However, the edit clearly demonstrated they only wanted to put alleged around points they didn't like, *and* wanted to remove the weakening 'alleged' term from a point they did like. Both the article pre-edit and post-edit seemed to be using alleged to weaken points that the editor didn't like.
The last bits didn't remove data, but read more like a debate that should be in the Talk section as to why a paragraph or two is irrelevant to the article. The post-edit seems confusing 'here is data point A, with respect to the invasion of Iraq. However, it had nothing to do with the invasion of Iraq'.
Particularly the first edit, though, points to some right-wing nut who happens to be in government, and not a conspiracy. I would imagine a conspiracy would have written more clean, less bitter sounding stuff.
Slashdot Mirror
If you have a choice in the first place of not having a smartphone at all, or having one, then you should have a more full range of choice, and be able to use that to your best advantage professionally, but at the same time having the discipline or backbone (whichever is applicable to the person) to shut it down/ignore it as if you didn't have it at all when appropriate.
I think some people get too wrapped up in their work and absolutely need to know how to cut out and enjoy the rest of their lives. But even for them, a smartphone/constant access can be a good thing, depending on how overboard they are. Take for example on guy at work with a family I know. He feels he absolutely *must* be there, and will work from 8 am to 11 pm *frequently* (and is salaried). His wife will call and complain to him, and he says he just can't pull himself away. For someone like him, maybe he'd be working all hours of the day still, but at least be at home. He is someone who at least outwardly expresses he wants not to be at work, though who knows if that is his reality...
Others are at risk who normally leave work, but don't have much backbone. If they have a *hard* excuse (I'm in a bus and can't possibly reach what you are talking about) they can get out of being overused. However, if they could easily get in from a technical standpoint, and they are left without a hard, physical fact to preclude them from doing the job, they can't say no.
Personally, I feel I have a good balance down. I leave work no more than 10-15 minutes late, with the *rare* exception of an hour if something is really bad. I work from home in off hours maybe 2-4 hours over the course of a month, with no more than twice a year logging in on Saturday to do something in full. But I know when to disconnect and not look at all, knowing if something was so critical, a *human* will somehow find a way to call me, which happens rarely, and that rare occasion is when I can triage it and still either take no action or redirect to someone else if I so choose. Anything else I don't know about can always wait until my next business day.
Of course, I don't have a data plan at all, but I don't think I'd be using a smartphone form factor to do my job to any significant extent, it's just not a job feasible for that usage. And most of the time I have full internet access throw my laptop somewhere anyway, and when I don't I'm probably either driving, eating, in a theater, or some other place where I couldn't possibly be productive, so I couldn't do anything anyway, so I can confidently say a smartphone wouldn't change my work habits one iota
In modern terms, I think not having X11 as the primary rendering platform goes against the current perception of 'Unix', though not technically. I think the common usage/higher level apis is as important as the mere core Unix behavior dictated by the Unix certification. In the past days of NeWS and such, etc, there was no immediate winner, but there was no established thing to compete with, so nothing would seem 'un-Unixy' at the time. Now it's been nearly two decades with X11 as the clear GUI implementation of AIX, Solaris, Irix, HP-UX, et. al., as well as not-quite official FreeBSD/NetBSD/OpenBSD, and the universally accepted unix-like Linux platforms. With the X11 layer, they can run applications relatively nicely, but the end-user experience is degraded by having two concurrent, vastly different usage experiences set before them, with the NeXT inspired applications taking front seat. If you are remotely serious about the OSX platform, you will produce a 'real' port using Cocoa. I would consider a Unix-y app to be equally at home in FreeBSD, Linux, and Solaris, whereas in OSX, an application with a mere recompile won't look right.
Of course, the whole 'Unix certification' thing is overrated. OSX is a good platform and benefits well from the Unix kernel/libc underpinnings, but the precise certification versus 'close enough' is of nearly no value to end-users or developers like. It let Apple rapidly get a mature modern core to build on, but other than that it's kind of a moot point. Just something for pedantic geeks to hash to death.
I do agree that particularly sense higher level graphical APIs are not part of the Unix status, shooting for mere Unix compliance isn't as constructive as it once might have been. I'm not sure I can concur on the accusations of horribly inconsistent and fundamentally broken aspects, as I don't really see it. As the quote goes "Those who fail to understand Unix are doomed to reinvent it, poorly".
Could have fooled me... I just wanted to perpetuate the four yorkshiremen-style thread going on.
I can think of a couple, but the same is true in the reverse. Both OS X and Vista have features that have not made it into Linux distros yet.
That's true. Were it not, this debate would not be possible.
Linux package managers lack the ability to handle Web and Bittorrent downloads or software registration, so commercial entities buy installer systems that do handle those instead. Commercial software is not only not kept up to date on Linux, but installation generally requires you to run a random binary and uninstallation is a mess.
Well, first there is the distinction between 'package management' (managing what owns what and what needs what, but not downloads and repository management (the ability to track versions of aforementioned packages). I've seen commercial linux software provide rpms with license acceptance programs/registrations that must be done before the application will start (it will warn you when you try to use the software, in addition to steps taken during %post). I haven't seen an rpm go interactive yet, but I know for a fact the .deb packages can get interactive with a user, and present questions in a way that's abstract. Good examples of commercial software packaged is most stuff from IBM, notably GPFS. If it isn't an rpm and branded IBM, it's probably a branding of a third party package.
In terms of downloads and such, absolutely they handle web downloads (kind of the whole point of repository management), even supporting authenticated downloads (I've installed commercial software that required a valid account to get at the repository). I don't think I've seen bittorrent support in the repository manager, but I've also yet to see the likes of InstallAnywhere do such a thing either. The point is, the framework of yum/apt is actually adaptable to commercial use complete with license acceptance and authentication restricted repositories, it's just most companies don't understand it and end up abusing the situation, sadly. Though not restricted, Adobe provides a yum repository for flash plugin. Now, I know AIX package manegement takes licensing to the utmost extreme (won't install a package unless the package stated license has been agreed to by the administrator for some package or another), but generally speaking, you can control license acceptence/registration through an authenticated repository or by run-time interlock (lot's of IBM packages demand acceptance of a license under linux when you try to run it). Unfortunately you are right, the reality is that the bulk of the commercial linux world doesn't adopt the repository management for some reason or another, but at least the underlying distribution provides such a feature, so the blame can solely be placed on the application vendor rather than the underlying platform.
I sometimes fear Linux will never make any large improvement again, simply because there is no one who can make a decision to make a big change.
The great thing is, 'Linux' doesn't have to do anything. Canonical, or RedHat, or Novell, or whoever, they are all communities that can change things without every other Linux platform adopting, and the free market can decide. Yellow Dog came up with yum, and Debian with apt, and they propogated from there. They continue to compete (because RedHat refused to adopt apt-rpm for some reason), but they have emerged as the overwhelmingly dominant package managers that serve >90% of users default repository management, and the remainder (i.e. gentoo) can use either of the two in a more manual fashion or their own wrappers.
In any event, Apple and Microsoft don't provide any facility for repository management, so they receive the blame rather than the software vendors.
Whaaa?!? Umm, the only things that require an installer and can't be drag and drop are things that install kernel modules. Even MS Office is drag and drop. Some software does use installers, but mostly so they can install DRM or manag
WAY too much bloat for features most never use. Real men use dash (if you *must* have a program that's a shell and only a shell) or if you don't mind something a bit more versatile to save disk space at potentially the risk of slightly higher memory consumption when all you have is a shell, you use a symlink to busybox for your shell. But not with that glibc cruft mind you, uClibc is the only path to efficiency.
Also, you don't use init, you have the kernel run the aforementioned shell directly instead. Who needs all the cruft of startup services and a well set up tty, after all.
The author, as such, appears to have slept through the last 30 years, in which the original Macintosh established the desktop metaphors Microsoft poorly reimplemented and Linux re-re-implemented many many times over.
By that reasoning, nothing is as good as what Xerox has, because they established the fundamental metaphor first. Nevermind they didn't take that project out of the prototype phase themselves, they must know better than Apple because they did something with a mouse first. It's simply not accurate to say ideas cannot be built upon and improved by anyone other than the first. The first one to establish something doesn't *necessarily* follow the most prudent evolution of the ideas. What the state of things 30, 20, 10, or even 5 years ago isn't automatically overriding of the situation of *today* (though certainly heritage influences the current, hence Microsoft being able to moderately screw up and lag in innovation and still maintain a lead).
As to the statement that there exists no meaningful HIGs in the *nix desktop world, that's just not true. Gnome and KDE both have their own HIGs, and if you stick to that software, the HIG is consistently obeyed. Ubuntu by default presents a pure Gnome environment, and generally you have to pick something out special to deviate. OSX and Windows are not immune to this. In OSX, if running an X11 app, it sticks out like a sore thumb and almost certainly doesn't follow the Apple HIG. Even without X11, some companies like Lotus release software that doesn't follow the HIGs (Notes looks equally hideous and out of place on all platforms). The point being, you can't fault a wide architecture for giving choice, and compare it against a specific implementation. You must compare a distribution to OSX. If you said Apple lays a better framework than Gentoo for a coherent HIG, then I'd have to admit it. Among the various Ubuntu flavors, each has picked and preferred a HIG. OSX, Windows, and Linux platforms can all be subject to misfit applications that refuse to obey HIGs or even use the most common toolkit. The following behind HIGs in the Linux desktop world is not so small as to be counted out.
Try not to state subjective experiences like snap-to-screen-edge or focus-follows-mouse being far more efficient when this clearly can only be true for you.
Obviously, it can be true for more than one person, but I think you must have misspoken, that sentence didn't parse to my eyes. The power to do these things in a relatively standardized way is not a bad thing, however you slice it. Windows can do focus-follows-mouse, and no one accuses them of trashing the user experience because of it, and subtle edge-resistance isn't going to hopelessly confuse someone not expecting it, and certainly a non-default option of it won't.
Ubuntu just as good? No. Free software just isn't there yet. If it were, Dell, HP and Acer would have dumped Microsoft quite some time ago in the home market. People want cheap and easy. Not necessarily good, just cheap and easy. Linux doesn't even qualify as that yet - the market has spoken as always.
By your logic, OSX 'just isn't there yet' either, because the market en masse hasn't ditched Windows entirely. The market reality is that an intrinsically better platform is *not* going to automatically win over the market magically. The market reality is one of a great deal of maintaining the status quo. Microsoft from a business perspective got their product out there in the most accessible form early on, and because so many people use windows, so many people will continue to use Windows, even if you can claim it to be worse than the competition. Application developers are in the same boat, they target the platform that is popular, helping to contribute to a deadlock of microsoft. Microsoft's technical work in the mid 90s was on par with the Mac experience, and the Linux experience was no where to be seen. By the time OSX and Linux could be argued as being superio
I agree that he knows not what he says when referring to the technical details of the aspects of OSX that make it Unix (the core c library, various APIs, the startup process behind the scenes, all the underpinnings that the Quartz system really needs to get going, and more).
However, I would say I wouldn't expect anyone to figure out OSX is a Unix without being explicitly being told so from a few minutes of using the platform. You have to observe how the startup process works underneath the pretty graphics (which is non-obvious by Apple design), you have to see the header files documenting the library calls. You must observe details of the filesystem hierarchy that are obscured/altered to Apple's best efforts as they perceive more mainstream Unix structure as confusing. Even if you start developing, the documentation is pretty Cocoa-layer specific, rather than discussing at length the more core Unix apis. The fact that by default you can start a *nix looking shell is a good hint, but without further detail, that could either accurately reflect it being a Unix or Unix-like system, or it could reflect bringing a Unix style interface to a non-Unix (i.e. Cygwin would not make Windows Unix or even Unix-like, and in fact cygwin sees the filesystem in a way that does not map well to the 'real' filesystem layout, so no matter how Unixy it looks from the shell, you can't easily be sure it's not just a trick).
Technically speaking, X is not Unix. Practically speaking, outside of the Mac/NeXT world, *no* Unix platform has a GUI that *isn't* an implementation of X11. With the exception of GNUstep, those APIs simply do not exist in modern *nix systems outside of OSX, and GNUstep is a rarity application developers simply do not risk requiring (with exceptions that specifically want to recreate NeXT intrinsically, and not use it as a means to an end). When targetting NeXT, Cocoa, Carbon, or *even* GNUstep APIs, the 'Unix' aspect of it is not the primary concern. They consider themselves to be OSX/NeXT/GNUstep applications, without caring what lies beneath. A good many of them remain Motif based, ugly as that is, because even GTK/QT they don't consider ubiquitous enough (and it's cheaper not to bother for old codebases).
Yes, an X application can run on a remote X server, but the platform executing the binary still *must* have the X libraries, so the distinction is moot to this discussion. Before bundling/having X11, Apple had no X server nor libraries in terms of first-party support. Considering the overwhelming majority of Unix applications that people specifically care about require X11 *and* are not Step derived, the lack of X11 server/libraries was a very practical obstacle to being usefully Unix, as opposed to being technically a Unix.
Though I think being 'UNIX-based' literally is overrated, you can't claim to be based on something that you didn't actually build upon. Just because a window manager theme looks like Windows XP, doesn't mean it's 'Windows-based'. You can say UNIX-like, or Unix-inspired, but Unix-based is totally inaccurate.
For linux, technically speaking, you are right, it isn't derived from any code that can be called 'Unix' and carries none of the certifications, and probably wouldn't pass the certifications as is. Pratically speaking, the linux kernel+GNU userspace is clearly Unix inspired and architected such that a Unix user is certainly familiar with the situation. GNU particularly makes clear the distinction (GNU's not Unix after all). Unix-inspired may be a more precise term.
OSX is to an extent the exact opposite. Technically speaking, it derives from BSD code (actual Unix code). Technically speaking, it implements the appropriate APIs and can run a program that runs on Unix. I want to say even before X11, Apple legitimately got the Unix moniker to describe their platform, but I recall there being confusing around this point. The addition of X11 out of the box makes it more complete, and less of a technicality. However, the fact of the matter is the extensive use of a non-X based graphical architecture and the almost universal situation is that NeXT derived APIs are used and required, and the underlying pieces that are true to a Unix heritage are nearly moot. A user accustomed to Unix will find OSX fundamentally different.
Technically speaking, OSX has a valid claim to being Unix, but could be accused of not necessarily being true to the 'spirit' of Unix. Linux is absolutely not a Unix, but on the other hand, people can certainly fairly claim Linux to being true to the spirit of Unix.
Why of course, so you can post a comment on slashdot saying "told you so", duh.
But more seriously (as a almost pure user of *nix architected systems now), he never said that the transition will be made any less painful as time passes, or that it's necessarily that painful to be on Linux now despite the market situation of Microsoft. Depending on your usage patterns, running a Linux platform may not be painful at all right now. Specifically, apart from the commercial game scene, most home usage is well served by a modern Linux distribution now. Whatever pain there is to be endured in the future, he endured that pain already, and his experience probably lacks pain today. Meanwhile, (also speaking as someone forced to use Windows on occasion), the Windows experience can be painful once familiar with the power and flexibility a Linux distro can provide, depending on the type of user you are. So you can be glad to be away from the whole mess and be an observer for those who endure it. *Particularly* if his prediction is right and the market moves to a non-MS solution, you know it will only because the market is painfully forced too, and microsoft users would suffer the most by not being prepared for such a switch. Not saying his prediction is accurate, but that's the implication that would be the case were it true.
The thing that's really troublesome here is, I don't think the person writing the article would care to mention that detail, at least not outside the ports IIS serve users on, which are the only ones he thinks matters. On the externally available ports that should be publicly available, there is *zero* applicability for stateful rules, particularly when you have external parties already tracking obvious DoS for you. For other ports (for example a port out of the IANA range), I wouldn't be surprised to find out they do have stateful inspection to allow traffic associated with an outbound connection in. The problem being their networking equipment might make it a transparent default. Of course, if they are running 100% microsoft software bottom to top, they may never even need to contact an external update server and forgo that entirely, something >90% of the world can't do, and is still a moot point with respect to how 'bulletproof' their server setup is.
In order to apply the 'ACLs' they describe, they *have* to inspect the packets, by definition. They may only compare a relatively small number of fields (src ip, dst ip, make sure it is a TCP packet *and* the destination port is 80). They might not make use of any logging or stateful inspection (then again, stateful may add next to nothing, so long as they don't need to contact external servers for any updates), but that doesn't mean they can get away with saying 'look, no firewall!' All he's saying is that port 80 (and maybe a few other hand selected ones) are 'wide open' (except something else blocks DoS for them even on those ports). Honestly, I doubt you'll find many public web services that puts a more restrictive 'firewall' than MS just confessed to having in an article where they declare 'no firewall!'
Cisco Guards for DoS detection and automated response In other words, they don't use firewalling where you have administrator defined rules to control traffic flow, they use networking equipment that accept administrator defined rules to control traffic flow
What in the world do *you* perceive the difference being between a 'firewall' and a router blocking ports based on source and destination being compared with a set of rules (aka ACLs)? Generally, firewall rules *can* get more complex than that, but mere port blocking by an intermediate router has been considered a firewall, even if it doesn't log violating or accepted packets, even if it doesn't have complex rules about connection state. Even if it doesn't have the word 'firewall' emblazened on the chassis somewhere.
Now it sounds that they are accustomed to having a program run by the user manipulate things at a higher level directly, and that somehow Vista disallows that, ostensibly to mitigate the risk of the very malware anti-virus targets. One wonders whether the best long-term idea for the end-user is for Vista to relax their default security policies, or for companies to handle privilege escalation in a more secure fashion. *nix programs have dealt with this situation since inception, and haven't had to fundamentally revisit program designs in order to accomodate any radical security overhaul attempts. In recent history, things like AppArmor and SELinux have *certainly* caused a lot of grief to admininstrators trying to use it for the first time, but both are about allowing common applications to do *precisely* what they are expected to, and everything that they are expected to without redesign, but nothing more. Occasionally while tweaking such policies, developers realize a boneheaded security move they made and tweak it in an update. Quite frequently, administrators have to put more work in to setting the contexts correctly on, for example, files for a web server to serve, or directories for webapps to write to. But the fact remains, the *nix world security enhancements have always been able to perfectly allow 'legacy' applications to work just fine, because the model was never fundamentally broken.
Of course, it does little to change the default resource consumption/perception that inhibits Vista adoption. However, above all, the biggest gate to Vista adoption is no one sees the point of shelling out money when it isn't going to let them do anything new compared to Vista. If Microsoft follows through on the threat of decreased support of XP in favor of Vista without making the transition seamless, they risk pushing customers to alternative platforms. I wouldn't underestimate microsoft, and they always have the XP product that is thoroughly entrenched. They had ME and the consumer world ran 98SE until XP came out. Now they have Vista, and maybe they'll make it successful, or maybe they'll bring to XP the 'goodies' they were trying to bring people to Vista with (i.e. DirectX 10), and stall for another attempt. For the most part, the *common* person's reasons for not going to Vista are the exact same reasons they wouldn't jump platforms, except maybe milder (applications may not run, unfamiliar environment, what they have today suits them fine). I can't imagine any remotely reasonable set of company leadership officially ditching XP until they have absolute confidence that Vista has been successfully adopted, regardless of what roadmaps declare today.
New recruits keep calling out 'SPISPOPD' and then running straight into walls for some reason...
spispopd would make an excellent tag, by the way.
that taking action, in this context *specifically* action against Iraq, was 'consistent' with necessary actions against terrorists/terrorist organizations, specifically referencing those responsible for 9/11. Government speak doesn't get much more blatant than that. It's clearly *strongly* suggesting that action against Iraq is justified in *part* because of 9/11 (in such a relationship, that's only possible *if* the Iraq government colluded with Al Queda specifically with respect to 9/11, and that just simply has not been shown to be a claim based on any real evidence). At least, the links are no more substantive than Bush's links to Osama bin Laden, or to Saddam's regime for that matter. Should we revolt against George W. because he associates with bin Laden family members? Should we execute Rumsfield for shaking Saddam's hand?
I'm not saying Saddam was an innocent guy or that Iraq was particularly good on the whole human rights thing, and therefore deserved to be left alone. However, you don't take a country to war and get the soldiers killed for unsubstantiated claims of WMD and terrorism, that the UN *was* investigating. Before the war, WMD was declared the reason, with mumblings of Al-Queda. When those claims eroded under scrutiny when the effort was underway, they said 'oh, we are freeing the Iraqis then!'. Great, how about those many other nations that have genocide/ethnic cleansings that are ignored? When you take away the terrorist link (they *knew* there wasn't a strong case there), the WMD (they also knew they had insufficient evidence), the only thing separating Iraq from a half-dozen other similarly screwed countries is that Iraq had oil to exploit and maybe made our buddies in Saudi Arabia a tad nervous.
To play devils advocate, the editing person put 'some say' in front of *other* people's statements that he disagreed with. He felt the statements were controversial, and should be somehow rewritten to indicate it isn't a universally accepted fact/provable fact. Now, with the clarification that he was absolutely *not* injecting his opinion, but rather trying to indicate that someone *else* had injected an unsourced opinion/theory he didn't like, he picked an option of softening the language. Generally, Weasel words are meant to get out of sourcing material, but in this case, the person editing didn't felt justified in removing it completely (which would have probably been more controversial), but took a milder step that still may be inappropriate, but not as nefarious.
The last few edits are certainly the wrong place to put the statements. Again, the editor saw text he felt inappropriate to the subject matter, didn't feel right removing it completely, and felt the correct place to debate was in the article text itself, which leaves the article text confusing and counterproductive.
I personally think while the editor clearly had an agenda/opinion that reflecting obviously in his edits (an opinion I think gives way too much credit/credibility to the current US administration), he at least wasn't as overzealous as to delete every thing he disagreed with that wasn't obviously and directly sourced.
Good to have pointed out, the very first part of the first edit in that link was appropriate, removing weasel wording. The second half of the first edit seems bitter and quite possibly blatantly incorrect.
I don't know what to make of the Powell statement deletion. It didn't seem offtopic, and did to some extent weaken the link the person editing obviously believed in, but it also was spun (as it was from a Bush administration person, after all) in a pro-war way, and far more damming, unqualified material is cited in the article than that.
Other than that, despite the effort to correct a deviation on the Weasel Word policy in the beginning, the bulk of the edit from there on out was injecting more weasel words to do just what you suggested.
Of course, if every random wikipedia edit was subject to a slashdot comment discussion, I'm sure a lot worse can be found.
They suggested the logical thing, that in time of panic/crisis, our perception/thought processes speed up to make it possible to contemplate the situation and take possible action, therefore things that are normally too fast for our normal eyes/mind to process, might be capable of being processed when those systems 'overclock'. Like an adrenaline rush gives us more than typical use of our muscles, something similar may happen to the mind and associated sensory organs.
Their results suggest that during such an event, our minds/eyes don't actually speed up to perceive time more slowly, but rather the mind burns that memory in such that it feels longer.
To quantify with fresh-from-my-ass numbers focusing on visual experience only, presume the normal perception of a given person is about 30 frames per second. The thought was that just *maybe*, the systems boosted enough to perceive 45 frames per second, in the name of gleaning every possible usable detail of the environment before it's too late. The outcome suggests that is not the case. Rather, say we do perceive 30 frames per second, but in the medium/long term our brain records, say, 3 frames per second worth of low detail, as most of that information is useless to us (we just remember the Cliff's Notes version of our lives, and our brain doesn't even process more than that nominally beyond very basic stuff). However, after surviving a situation that felt like it could have been fatal, our brain retains, say, 15 frames per second at a more vivid level into a longer memory term, to remind us of everything that went wrong leading to that so that it may be avoided.
I wouldn't be surprised if a future study proved this one to be lacking and that some perceptual speed up at the moment of panic does happen, but I'm also not surprised if such a perceptual speedup simply does not exist. In the cases where this 'slow-mo' memory occurs, there would have been nothing you could have physically done with your body to leverage anything you normally would not perceive at all.
Defending ones country is defending for land and resources. France on the defense would never have been a war were it not for a foreign entity trying to invade to acquire land/resources. The crusades for the most part was using religious reasons to motivate people to fight to give those in power land. The crusades that weren't about invading were carried out without government/church leadership because the commoners had bought hard into the propaganda used for the other crusades. Note the crusades that were about ideology were rather pathetic and stomped out by the defenders, as the invaders had no power.
Terrorism is a complex issue, but however that debate would go, the fact remains that *usually* at the root of a significant conflict there is an issue of land/resources that is secular in nature.
The overall tone of all the edits were definitely partisan spin, without contributing any facts. However, reading the before and after also makes clear that there did already exist a somewhat opposing spin.
Probably, you can logically argue the injection of 'alleged' phrasing in any controversial point as making a statement more universally true rather than presenting it as true. However, the edit clearly demonstrated they only wanted to put alleged around points they didn't like, *and* wanted to remove the weakening 'alleged' term from a point they did like. Both the article pre-edit and post-edit seemed to be using alleged to weaken points that the editor didn't like.
The last bits didn't remove data, but read more like a debate that should be in the Talk section as to why a paragraph or two is irrelevant to the article. The post-edit seems confusing 'here is data point A, with respect to the invasion of Iraq. However, it had nothing to do with the invasion of Iraq'.
Particularly the first edit, though, points to some right-wing nut who happens to be in government, and not a conspiracy. I would imagine a conspiracy would have written more clean, less bitter sounding stuff.