Even if you don't have technical insights, you are clearly in a position to see more, know more and do more than 99.9999% of everyone on Slashdot. I don't know what information is classified or commercial confidential, but I imagine you'd be OK with writing up a bit about the launchsite, the recovery effort, etc. I'd be willing to bet that virtually everyone on Slashdot would salivate like a Pavlovian dog if you were to submit a piece - as a story or as a Slashdot journal entry.
The news stories are fine and all that, but they miss out on the facts. The science journals do the facts, but have no context. An intrepid Slashdottian Reporter, "on the scene", would be able to cover the sorts of things that just don't get reported. Because Slashdot journals are updated faster than news websites, there's a chance you could even get the scoop on what happens.
(I'm not pressing for a strict story, as it's so unpredictable as to what'll make it through the queue - unless CmdrTaco talls you to mail him the story direct - and I believe that if you can put something together, it'd be the most important news story on ANY tech/geek site.)
The shuttle is going at mach 26 at one point in the descent - I imagine it's going a lot faster at the start. The atmosphere is also very thin there - not much oxygen to scoop - which would complicate things.
On the other hand, if you put a lightweight scramjet with waverider airfoil in the shuttle payload bay, then flung that into a survivable re-entry trajectory, it might work. The waverider would simply glide until the engine ignited and would then resume gliding once the burn had finished.
In the end, this is what they'll be building to carry any cargo/people anyway, and modular testing only goes so far on a mechanical system.
This is the idea behind the class of Operating Systems the old DoD "Orange Book" listed as "B-class", but is implemented in other ways on other systems. B-class systems use Mandatory Access Controls (MACs) for all files, applications, ports, system calls, memory, packets, etc. Not all systems protected everything, and but a fair number protected a lot. I believe Trusted Irix required a special MAC-enabled memory controller, for example.
The advantage of the MAC system was that it created virtual systems per user per program (as the effective MAC had to be the intersection of the two sets of rights, as MAC prohibits someone from inheriting a right they wouldn't otherwise have) but requires very little overhead, as it's all managed in a single instance of the OS. There's no overhead from virtualization.
MAC has two drawbacks - to be thorough (and fast), you do need specialized hardware. It's also non-trivial to write thoroughly. SELinux, for example, is only a tiny subset of what would be needed even to reach the old B1 standard. As far as I know, there are NO patches or combinations thereof for Linux that meet that criteria, and I'm absolutely certain we're not going to see a B3-compliant Linux any time soon (that's when the standards get really strict).
Virtualization takes some of the load off MAC, but unless you're prepared to run a few hundred virtual machines, won't be able to sandbox on anything like the scale you'd want to get decent security. It does limit the need for some of the specialized hardware, though, which will make things easier.
The "ideal" is to get as close to EAL7 (Orange Book A1) standard, where there is mathematical evidence that the software is fully sandboxed, as possible. However, that isn't easy and would take a lot of VERY skilled mathematicians a LONG time to do well.
To get it perfect, you'd need to generate the complete OS formal specification, then rewrite Linux completely from scratch from that specification. It's doable, but I'm estimating you'd need 100,000+ mathematicians and another 10,000 coders to be able to re-engineer and re-code the kernel fast enough for it to still be relevent. When you add in thigns like GCC, Glibc, X11, KDE/Gnome, and all the other major pieces of software, you might easily be looking at a quarter of a million individuals needed - about 25 billion dollars a year.
The US Government could afford that, but I seriously doubt it could get hold of that much manpower. Not without crippling every industrialized country in the northern hemisphere in the process.
As perfection is not practical, then we should look at how close we can get there before it goes beyond the resources that exist. Virtualization will be a major part of that, MAC will be another, source validation (by as many means as possible) will be yet another.
If the observations are indeed correct AND the experiment is actually doing what the experimentors think it is doing, relativity is in serious trouble. You can't just ignore an error orders of magnitude larger than the predicted effect.
On the flip-side, relativity has been pretty safe the last hundred years and there is no reason to start by assuming it has fallen now. given a choice between a flaw in the experiment (or observation) and a flaw in relativity, the odds are stacked heavily in favour of relativity coming out shining.
This doesn't prove the experiment is flawed, it merely requires that the experiment is carefully proven to do what it's supposed to, then repeated by others independently to show that the data actually is valid. If (and only if) we see some independent confirmation does this really mean anything at all.
911 (999) is a service that really needs to have 100% access, 100% of the time. It's an extreme example, but let's say a chemical factory or nuke reactor catches fire - you really really REALLY want to get 911 right there, right then. Delay, in such circumstances, is beyond merely inconvenient.
Then, there's the matter of delays between the emergency number and the emergency services. Again, there are times when this isn't a big deal. On the other hand, 2 minutes without oxygen leads to irreversible brain damage - that can matter when the ambulance service is talking to someone calling on behalf of a heart attack victim.
Now, it's not entirely the emergency service's fault - a surprisingly large number of 911/999 calls are people calling to find out where to get pizza (seriously!) or other so wildly, blatantly, non-emergency reasons. Stupidity of this kind results in a low-grade, continual DDoS attack. Hoax calls (and there are plenty of those) also limit the ability to respond.
IMHO, all levels of emergency service need better staffing and better equiptment, but education (and penalties for misuse) over emergency services needs improving too.
Sendmail is a big program. It also has several components. This tells me that things like selinux and other mandatory access control systems MAY prevent the attack from taking over the PC. What impact there is on such systems depends on what component the failure is in and what rights that component must have.
There are also multiple ways of configuring sendmail when compiling it, which tells me that whilst an upgrade may be important, it may be much more important for some users than others.
Also, saying it doesn't affect Windows is unclear. Does it not affect Windows when you use some official.exe? When you compile it yourself? When compiled/run via Cygwin? If you run under Wine, do you see the bug or not? Are all versions of Windows safe, or would the bug be exposed under certain versions?
The report, as described, is about as useful as saying "we think we know a way by which under certain circumstances that we know, another may think they know a way by which you might have an increased chance of being struck by an asteroid". If you don't know what the way is, or what those circumstances might be, the information has little value. Sure, it has some in that they provide a bugfixed release, but we don't know how long the bug has existed and therefore have absolutely bugger all way of quantifying what the risk is that a server has already been compromised. It only prevents uncompromised servers from being attacked by this method in future.
Just because the press release is dated XYZ does not mean that every Black Hat under the sun hasn't got a CD-ROM filled with exploits for it and a list of backdoors on cracked sites from three years back. XYZ is merely the date the rest of us know about it. You don't maintain a secure system by assuming all crackers only know the exploits you've fixed. You maintain a secure system by assuming at least one cracker has the means to discover the exploits you've neither heard of nor have patches for - ie: by assuming you're running buggy software and taking the necessary steps to limit what those bugs can do.
Generally, that would be true if you were talking about a fixed base-station and a satellite that will only move (from an angular perspective, from the ground) very slowly. A rocket plunging to a firey death at mach 7 is going to be moving much faster (from an angular perspective), which means you can't afford to have either the transmitting or receiving station use an extremely directional antenna.
That's going to cost in a number of ways, but perhaps the most obvious is interference. The atmosphere has become very very noisy. This doesn't affect satellite communication much, precisely because you're working on a directional system. (You also don't have a sodding big scramjet blasting ionised gas out the back.) If you're having to collect any and every signal in the general direction of the engine, you're going to get a LOT more gunk, which is going to cap the speed well below what you could get under better conditions.
You'd fire the rocket straight up, carrying the scramjet and ramjet(s). (If you have the ramjet directly behind the scramjet, as if another rocket stage, you only need one.) Once the rocket's fuel is exhausted, you release the rocket. You let the scramjet/ramjet collection continue to glide upwards until the speed dropped to about 500 mph. (You can let the speed get down to 400, but I'm allowing a safety margin, as you'd want to be certain the ramjets fired.)
The ramjets fire at probably 32-34 Km (35 would be where the velocity drops to zero, so it has to be under that). As ramjets are inefficient in a thin atmosphere, you'd want them to alter the trajectory to keep at roughly the same height. You burn the ramjet(s) until the speed gets back to mach 5 - mach 6, then you tilt the assembly downwards. If your ramjets can go fast enough to ignite the scramjet, you only need enough gravity assist to maintain ignition velocity. You don't need to point downwards any more than that. If it's not quite fast enough, THEN you'd want to point down.
In both cases, the trajectory goes from straight up to straight across. In the first case, it finishes with an extremely elongated second half of a parabola. In the second case, the whole thing will look more like a square wave with rounded corners.
Sure, it'll never be used again. However, there are definitely things I'd have thought the engineers would want to know. For example, to what extent did the engine itself react with the atmosphere or fuel? The atmosphere isn't empty, but what impact (sorry!) will that have on the design? What happens when you turn a scramjet off, after a sustained burn?
On the other hand, building scramjets isn't cheap either. On the other hand, the more scramjets you need to get the same amount of data, the more expensive the research is, even if an individual experiment is cheaper. Ramjets aren't bad, pricewise (not much in them, although what there is has to be precisely engineered), they're not turbines. (Most ramjets in practical use are combinations of turbine and ramjet, because a pure ramjet won't function below 400 mph, so you can't go by what would be a standard cost.)
Two ramjets wouldn't be cheap, but it would cost a lot less than one scramjet plus rocket. So, if we assume the "next run" would also collect 4-6 seconds of data if it's on a purely parabolic orbit, then your ramjets might only need to add another 3-4 seconds of data to pay for themselves. Because the descent path would be very much stretched out (you now need gravity to sustain the engine's speed, not to accelerate it), it should be easy to add at least that much to the data collection time. Possibly more.
If you can add a whole 6 seconds to the actual scramjet burn time, you've eliminated the need for an entire run (as you've that much more data) and have data on how the engine alters over a longer period of time, which could avoid the sorts of design errors which have led to other scramjets failing to start at all. (NASA's first scramjet failed to ignite by the time it impacted, for example.)
But it'll be limited. They can get a bit more info than just speed & position - since hydrogen + oxygen = water, they could (not necessarily will) use microwave radar to see how the exhaust from the jet behaves, for example. Other than sensors on the engine itself, though, I can't see any way they could observe turbulance either on the outside or the interior of the engine - and that's going to be critical to understand.
(They can't necessarily get the internal info from a one second test in a wind tunnel and I can't see how they can get the external info at all by that method. Computational Fluid Dynamics is messy for turbulant flow, is very messy when you've a mix of hypersonic, supersonic, transsonic and subsonic airflows in the same system, and is a menace to the brain when you've no obvious way of knowing what the numbers are even supposed to look like.)
To give the engine a fast initial velocity, rather than use a parabolic orbit in which the engine essentially has a standing start at 35 Km up. The engineers presumably know what they're doing, so I guess they've thought all this through, but I'd have strapped a couple of standard ramjets either side of the scramjet. At peak altitude, it would then be possible to accelerate the scramjet to near-ignition point using the ramjets. You've then got virtually the entire 35Km descent to do the scramjet testing.
(Hydrogen-fuelled ramjets are useless above Mach 5, but that's about when the scramjet should ignite, so you really wouldn't need a whole lot of additional acceleration at that point. If they've got the ignition point within the limit, you could even switch directly from one to the other.)
The other thing I don't like is that this is destructive testing. It's inescapable, given the approach they're using, but that doesn't mean I have to like it. Their data collection has to be wireless, since no recording device is going to survive a mach 7 impact, but wireless is relatively slow. This means that they're going to be limited in what they can collect - what parameters, what accuracy, what resolution, etc.
Normally, this wouldn't matter a great deal. But we're talking mach 7 speeds in a far denser atmosphere than most existing hypersonic travel (such as the shuttle re-entry) have taken place in. I believe there have been two successful scramjet flights in the past, so we have a little information on what happens under those conditions, but it seems somewhat... brave... if they are assuming they can interpolate between the few data points they'll be able to collect -and- extrapolate beyond the six seconds of flight.
Again, I'm sure they have their reasons, but for novel engines under novel conditions, I'd have thought that getting as much data as humanly possible would be worth almost any additional effort.
Microsoft can afford to pay a registrar to shift unused sites over to Windows - it'll barely register even on a second-by-second cash flow. However, as others have noted, it'll do wonders for their stats on parked domains.
As far as Linux servers vs. Microsoft servers is concerned, that's a false premise as you are quite capable of running Apache, MySQL, Sendmail, BIND, etc, on a Windows platform. Linux per-thread costs are far better than Windows per-thread costs, but we're talking seldom-accessed parked sites that will be visited by the occasional webcrawler, portscanner and domain name buyer. They don't need to do much more than serve a static page.
In which case, you wouldn't need to run a server on Linux at all - you'd use Tux, which is extremely fast for static-only content. I think there was another accelerated system - I think it was X15 - but dunno what happened to that. Actually, you'd be better off running ExoPC and their Cheetah webserver, as you don't even really need a full OS for single-page static content.
Windows, though, would do fine in such an environment. The one risk Microsoft is, however, running is that competitors may be able to leverage this as a way of "proving" Microsoft can't do anything real, that it can ONLY do toy stuff. That could hurt it in the server market. Again, though, only if the competitors were to spin the move in this way.
And he is indeed correct. In 1770, there were people taken to court in England for theft for freeing slaves. The complaint was on the basis that the slaves were being taken between countries in which slavery was legal and that these should hold sway (making the freeing of slaves the deprivation of recognized property and therefore theft) even though England itself did not recognize slavery any longer.
It got to the House of Lords, where it was ruled that the laws of other nations were of no consequence in this matter and that the laws of England held sway for those on English soil, no matter what their status in other lands.
You cannot take this analogy much further, as Free Software is not a Constitutional or legal obligation in any country (yet) - but if it were, then "closed source" that passed through such lands could reasonably be Opened, and the argument that this is automatically "bad" or "evil" is clearly false.
However, it could be problematic in the longer-term. With anti-trust appeals in Europe and South Korea, it's going to be very hard for Microsoft to claim to be playing fair, if they're seen to be maliciously tampering with the approvals process. They don't even have to be tampering, and the ISO process doesn't have to have anything to do with existing cases. If Microsoft is believed to be acting in a willfully anti-competitive manner, the appeals judges are less likely to be sympathetic. This is really bad timing, on Microsoft's part.
But what about America? Microsoft has employees in Washington State, but it's not a major factor for Massechusetts. If Mass. residents are influenced, in the November elections - and it's a big if - then it'll be over cost savings (if significant). Other than that, there really won't be any noticable impact until after any decisions by ISO.
If ISO opts for Microsoft's format and the Government of the time is much more strict on anti-competitive actions, we might see some DOJ action, but not unless or until.
You'll be telling us next that we should go round to France and collectively punish the French pirate babes by spanking them, or something. You're weird.
You've got to concentrate on what is being described, not on what is being said. The students are not there to be secretaries - unless it's a secretarial class. However, pen and paper alone won't fix the problem, as the students will just transcribe that way.
In this day and age, the simplest thing would be to have the lecturer set up a webcam that can view the lecturn and blackboard/whiteboard, with a microphone to record what is said. The students could then be issued with a DVD of the lecture, which covers the notes angle. In order for the students to bother turning up - and stay awake - the lecture then has to become more interactive, with students actually solving problems (for example) for which they are graded.
The best way to learn is to do, the best notes are the ones NOT made in a rush in real-time, the best classes are the ones where students learn more than what is presented - but also where you are not penalized for not mind-reading what "more" you are "supposed" to learn.
Now now. Be nice. Windows Vista probably will be released - eventually. To be fair, you'd have to compare the other two with the release date for the advertised Vista (with all the enhancements they've dropped)
Emacs would be implemented as a filesystem, not a syscall. Screen would be a virtual framebuffer device. GCC would be an executor, in the same way we've "elf", "a.out" and "misc" at the moment.
Although I seriously doubt Microsoft is going to alter their campaign to fit, there is now a legal ruling to quote from. IANAL, but I believe that past rulings ("case law") shape all future rulings, which would suggest that future attacks on the GPL based on competitiveness have a higher chance of failing. This is a Good Thing.
My only concern is that it might inflame the Linux vs. Gnu/Linux wars, given that the judge implied that Gnu/Linux was indeed the correct form. It would not look good if a breakaway Linux group appealed the ruling on the grounds that Gnu/Linux sounds stupid.
Slashdot Mirror
The news stories are fine and all that, but they miss out on the facts. The science journals do the facts, but have no context. An intrepid Slashdottian Reporter, "on the scene", would be able to cover the sorts of things that just don't get reported. Because Slashdot journals are updated faster than news websites, there's a chance you could even get the scoop on what happens.
(I'm not pressing for a strict story, as it's so unpredictable as to what'll make it through the queue - unless CmdrTaco talls you to mail him the story direct - and I believe that if you can put something together, it'd be the most important news story on ANY tech/geek site.)
On the other hand, if you put a lightweight scramjet with waverider airfoil in the shuttle payload bay, then flung that into a survivable re-entry trajectory, it might work. The waverider would simply glide until the engine ignited and would then resume gliding once the burn had finished.
In the end, this is what they'll be building to carry any cargo/people anyway, and modular testing only goes so far on a mechanical system.
The advantage of the MAC system was that it created virtual systems per user per program (as the effective MAC had to be the intersection of the two sets of rights, as MAC prohibits someone from inheriting a right they wouldn't otherwise have) but requires very little overhead, as it's all managed in a single instance of the OS. There's no overhead from virtualization.
MAC has two drawbacks - to be thorough (and fast), you do need specialized hardware. It's also non-trivial to write thoroughly. SELinux, for example, is only a tiny subset of what would be needed even to reach the old B1 standard. As far as I know, there are NO patches or combinations thereof for Linux that meet that criteria, and I'm absolutely certain we're not going to see a B3-compliant Linux any time soon (that's when the standards get really strict).
Virtualization takes some of the load off MAC, but unless you're prepared to run a few hundred virtual machines, won't be able to sandbox on anything like the scale you'd want to get decent security. It does limit the need for some of the specialized hardware, though, which will make things easier.
The "ideal" is to get as close to EAL7 (Orange Book A1) standard, where there is mathematical evidence that the software is fully sandboxed, as possible. However, that isn't easy and would take a lot of VERY skilled mathematicians a LONG time to do well.
To get it perfect, you'd need to generate the complete OS formal specification, then rewrite Linux completely from scratch from that specification. It's doable, but I'm estimating you'd need 100,000+ mathematicians and another 10,000 coders to be able to re-engineer and re-code the kernel fast enough for it to still be relevent. When you add in thigns like GCC, Glibc, X11, KDE/Gnome, and all the other major pieces of software, you might easily be looking at a quarter of a million individuals needed - about 25 billion dollars a year.
The US Government could afford that, but I seriously doubt it could get hold of that much manpower. Not without crippling every industrialized country in the northern hemisphere in the process.
As perfection is not practical, then we should look at how close we can get there before it goes beyond the resources that exist. Virtualization will be a major part of that, MAC will be another, source validation (by as many means as possible) will be yet another.
On the flip-side, relativity has been pretty safe the last hundred years and there is no reason to start by assuming it has fallen now. given a choice between a flaw in the experiment (or observation) and a flaw in relativity, the odds are stacked heavily in favour of relativity coming out shining.
This doesn't prove the experiment is flawed, it merely requires that the experiment is carefully proven to do what it's supposed to, then repeated by others independently to show that the data actually is valid. If (and only if) we see some independent confirmation does this really mean anything at all.
...it uses SMTP-over-ultrasonics! And the admins are vampires. And it flies best after dark.
Then, there's the matter of delays between the emergency number and the emergency services. Again, there are times when this isn't a big deal. On the other hand, 2 minutes without oxygen leads to irreversible brain damage - that can matter when the ambulance service is talking to someone calling on behalf of a heart attack victim.
Now, it's not entirely the emergency service's fault - a surprisingly large number of 911/999 calls are people calling to find out where to get pizza (seriously!) or other so wildly, blatantly, non-emergency reasons. Stupidity of this kind results in a low-grade, continual DDoS attack. Hoax calls (and there are plenty of those) also limit the ability to respond.
IMHO, all levels of emergency service need better staffing and better equiptment, but education (and penalties for misuse) over emergency services needs improving too.
There are also multiple ways of configuring sendmail when compiling it, which tells me that whilst an upgrade may be important, it may be much more important for some users than others.
Also, saying it doesn't affect Windows is unclear. Does it not affect Windows when you use some official
The report, as described, is about as useful as saying "we think we know a way by which under certain circumstances that we know, another may think they know a way by which you might have an increased chance of being struck by an asteroid". If you don't know what the way is, or what those circumstances might be, the information has little value. Sure, it has some in that they provide a bugfixed release, but we don't know how long the bug has existed and therefore have absolutely bugger all way of quantifying what the risk is that a server has already been compromised. It only prevents uncompromised servers from being attacked by this method in future.
Just because the press release is dated XYZ does not mean that every Black Hat under the sun hasn't got a CD-ROM filled with exploits for it and a list of backdoors on cracked sites from three years back. XYZ is merely the date the rest of us know about it. You don't maintain a secure system by assuming all crackers only know the exploits you've fixed. You maintain a secure system by assuming at least one cracker has the means to discover the exploits you've neither heard of nor have patches for - ie: by assuming you're running buggy software and taking the necessary steps to limit what those bugs can do.
That's going to cost in a number of ways, but perhaps the most obvious is interference. The atmosphere has become very very noisy. This doesn't affect satellite communication much, precisely because you're working on a directional system. (You also don't have a sodding big scramjet blasting ionised gas out the back.) If you're having to collect any and every signal in the general direction of the engine, you're going to get a LOT more gunk, which is going to cap the speed well below what you could get under better conditions.
The ramjets fire at probably 32-34 Km (35 would be where the velocity drops to zero, so it has to be under that). As ramjets are inefficient in a thin atmosphere, you'd want them to alter the trajectory to keep at roughly the same height. You burn the ramjet(s) until the speed gets back to mach 5 - mach 6, then you tilt the assembly downwards. If your ramjets can go fast enough to ignite the scramjet, you only need enough gravity assist to maintain ignition velocity. You don't need to point downwards any more than that. If it's not quite fast enough, THEN you'd want to point down.
In both cases, the trajectory goes from straight up to straight across. In the first case, it finishes with an extremely elongated second half of a parabola. In the second case, the whole thing will look more like a square wave with rounded corners.
Sure, it'll never be used again. However, there are definitely things I'd have thought the engineers would want to know. For example, to what extent did the engine itself react with the atmosphere or fuel? The atmosphere isn't empty, but what impact (sorry!) will that have on the design? What happens when you turn a scramjet off, after a sustained burn?
Two ramjets wouldn't be cheap, but it would cost a lot less than one scramjet plus rocket. So, if we assume the "next run" would also collect 4-6 seconds of data if it's on a purely parabolic orbit, then your ramjets might only need to add another 3-4 seconds of data to pay for themselves. Because the descent path would be very much stretched out (you now need gravity to sustain the engine's speed, not to accelerate it), it should be easy to add at least that much to the data collection time. Possibly more.
If you can add a whole 6 seconds to the actual scramjet burn time, you've eliminated the need for an entire run (as you've that much more data) and have data on how the engine alters over a longer period of time, which could avoid the sorts of design errors which have led to other scramjets failing to start at all. (NASA's first scramjet failed to ignite by the time it impacted, for example.)
(They can't necessarily get the internal info from a one second test in a wind tunnel and I can't see how they can get the external info at all by that method. Computational Fluid Dynamics is messy for turbulant flow, is very messy when you've a mix of hypersonic, supersonic, transsonic and subsonic airflows in the same system, and is a menace to the brain when you've no obvious way of knowing what the numbers are even supposed to look like.)
(Hydrogen-fuelled ramjets are useless above Mach 5, but that's about when the scramjet should ignite, so you really wouldn't need a whole lot of additional acceleration at that point. If they've got the ignition point within the limit, you could even switch directly from one to the other.)
The other thing I don't like is that this is destructive testing. It's inescapable, given the approach they're using, but that doesn't mean I have to like it. Their data collection has to be wireless, since no recording device is going to survive a mach 7 impact, but wireless is relatively slow. This means that they're going to be limited in what they can collect - what parameters, what accuracy, what resolution, etc.
Normally, this wouldn't matter a great deal. But we're talking mach 7 speeds in a far denser atmosphere than most existing hypersonic travel (such as the shuttle re-entry) have taken place in. I believe there have been two successful scramjet flights in the past, so we have a little information on what happens under those conditions, but it seems somewhat... brave... if they are assuming they can interpolate between the few data points they'll be able to collect -and- extrapolate beyond the six seconds of flight.
Again, I'm sure they have their reasons, but for novel engines under novel conditions, I'd have thought that getting as much data as humanly possible would be worth almost any additional effort.
...the article uses "adult" and "hardcore" in the same sentance?
As far as Linux servers vs. Microsoft servers is concerned, that's a false premise as you are quite capable of running Apache, MySQL, Sendmail, BIND, etc, on a Windows platform. Linux per-thread costs are far better than Windows per-thread costs, but we're talking seldom-accessed parked sites that will be visited by the occasional webcrawler, portscanner and domain name buyer. They don't need to do much more than serve a static page.
In which case, you wouldn't need to run a server on Linux at all - you'd use Tux, which is extremely fast for static-only content. I think there was another accelerated system - I think it was X15 - but dunno what happened to that. Actually, you'd be better off running ExoPC and their Cheetah webserver, as you don't even really need a full OS for single-page static content.
Windows, though, would do fine in such an environment. The one risk Microsoft is, however, running is that competitors may be able to leverage this as a way of "proving" Microsoft can't do anything real, that it can ONLY do toy stuff. That could hurt it in the server market. Again, though, only if the competitors were to spin the move in this way.
(Hint hint...)
Most of the other servers hold xxx% of the Internet, and the remaining 5 hold the tech/geek content.
It got to the House of Lords, where it was ruled that the laws of other nations were of no consequence in this matter and that the laws of England held sway for those on English soil, no matter what their status in other lands.
You cannot take this analogy much further, as Free Software is not a Constitutional or legal obligation in any country (yet) - but if it were, then "closed source" that passed through such lands could reasonably be Opened, and the argument that this is automatically "bad" or "evil" is clearly false.
But what about America? Microsoft has employees in Washington State, but it's not a major factor for Massechusetts. If Mass. residents are influenced, in the November elections - and it's a big if - then it'll be over cost savings (if significant). Other than that, there really won't be any noticable impact until after any decisions by ISO.
If ISO opts for Microsoft's format and the Government of the time is much more strict on anti-competitive actions, we might see some DOJ action, but not unless or until.
You'll be telling us next that we should go round to France and collectively punish the French pirate babes by spanking them, or something. You're weird.
I dunno. Open University, in the UK, does very nicely and all of their lectures are on TV.
...but have you seen where the eyes are?
In this day and age, the simplest thing would be to have the lecturer set up a webcam that can view the lecturn and blackboard/whiteboard, with a microphone to record what is said. The students could then be issued with a DVD of the lecture, which covers the notes angle. In order for the students to bother turning up - and stay awake - the lecture then has to become more interactive, with students actually solving problems (for example) for which they are graded.
The best way to learn is to do, the best notes are the ones NOT made in a rush in real-time, the best classes are the ones where students learn more than what is presented - but also where you are not penalized for not mind-reading what "more" you are "supposed" to learn.
Now now. Be nice. Windows Vista probably will be released - eventually. To be fair, you'd have to compare the other two with the release date for the advertised Vista (with all the enhancements they've dropped)
Emacs would be implemented as a filesystem, not a syscall. Screen would be a virtual framebuffer device. GCC would be an executor, in the same way we've "elf", "a.out" and "misc" at the moment.
My only concern is that it might inflame the Linux vs. Gnu/Linux wars, given that the judge implied that Gnu/Linux was indeed the correct form. It would not look good if a breakaway Linux group appealed the ruling on the grounds that Gnu/Linux sounds stupid.
Emacs with WYSIWYG LaTeX support, but basically yeah.