Maybe I've watched too much Babylon 5, but I just can't get read the phrase 'President Clark' without looking around for Nightwatch.
Didn't you get the memo? Someone decided that TIPS was a better name than Nightwatch.
But seriously, you can see the Democratic candidates' positions (in soundbite form) on "homeland security" at CNN. Nothing very concrete from Clark, but Howard Dean is listed as:
Against military tribunals, labeling of "enemy combatants"
Repeal parts of Patriot Act that restrict basic liberties
I for one would love to be able to vote from the comfort of my home/work/cafe without having to wait in lines.
I would love to be able to vote from the comfort of your home/work/cafe, too. At the moment I think that will be easiest to do with a worm that infects your computer to make a man-in-the-middle attack possible, but we'll have to see Verisign's implementation before anyone works out the actual details. Fortunately for people who are tired of that "one man, one vote" nonsense, it's impossible for Verisign to develop secure online voting because no matter how bulletproof their own software is, the systems will still be as insecure as the operating system, server, email client or gullible users they're connected to.
Try to look at it as a form of "weighted" democracy: those people who can't figure out that they need to fix their IIS/WinXP/sshd/whatever holes have their votes weighted by 0, those people who can figure out how to exploit those holes have their votes weighted by 1000s.
Because otherwise either you can only fire the engines on one stage at a time (which requires twice as much engine weight to give you the same thrust at liftoff) or the staging doesn't help you (as the "upper" stage runs out of fuel at the same time as the "lower" one).
Moving fuel across a juncture seems like a big risk.
Possibly. We've seen what happens when a juncture containing fuel (SRB connections) fails, although perhaps that's not a fair comparison since the TSTO fuel wouldn't actually be combusting inside its pipe.
0. Constrains you to a liquid fuel, solid boosters are disallowed.
If you want solid boosters, you might as well launch an expendible rocket, take months to set it up, and don't worry about reducing complexity with fewer stages. I think the TSTO would be advantagious as a reusable, quick turnaround design.
1. Must add mass in the form of pump equipment.
Not much mass. The rate of fuel flow in this design would only be 50% larger than in a more traditional rocket: for every kilogram of fuel moved from one rocket to the other, you've also got to transfer a kilogram to the engines of each rocket anyway.
2. Vehicle's mass over time is more complicated (shift from side to side), trajectory prediction is harder.
Somewhat more complicated, but that's what we've got computers for, and if you've got a VTVL design already then the engine throttling/gimbaling requirements during launch aren't any worse than the requirements for your landing.
3. The join-point where fuel passes from one rocket to another would be a nasty point for failure. (At least it doesn't have to be streamlined. By the time they split, air resistant is not a worry)
Horizontal separation would be earlier than you'd expect since the stages aren't efficiently asymmetrically sized like they are in most staged rockets. I seem to remember coming up with back-of-the-envelope numbers of roughly Mach 4, less than 100,000 feet up.
4. Burning from the bottom while siphoning from the top? Danger danger!
Please explain? You wouldn't want the pipe inlets to be at the top of either fuel tank.
NASA isn't building a Delta Clipper style SSTO because when they did fund an SSTO prototype they picked the one (X-33) with the most fancy untested technologies (linear aerospike engine, multilobed composite fuel tanks, lifting body VTHL design), and so it ran over budget and over schedule and failed to even produce a flying half scale prototype.
American aerospace companies aren't building a Delta Clipper style SSTO because mergers have left us with only two large firms, space launcher development is too expensive for any new competition to break into, and the existing companies are often working for "cost plus" contracts, a zany system in which your profit is a fixed percentage of your costs and so if you build a cheaper launcher you actually make a little less money instead of much more.
It also doesn't help that SSTO designs have paper thin weight margins, so not everyone agrees that getting one to orbit is possible even with modern materials. Personally, I'd like to see someone build a siamese TSTO (two nearly identical stages, mated horizontally, with one of them pumping fuel into the other during liftoff so the "upper stage" still has full fuel tanks when they separate) to mitigate that risk, and then if the finished product comes out light enough you can launch just one half of it alone to put smaller payloads in orbit or to fly suborbital.
That's certainly interesting, but guess what? Many scientists have done better (and much more expensive) measures, so we already know the speed of light quite well.
Damn - are you telling me Nature won't be publishing the paper I submitted?
There's also a great danger that Microsoft would take advantage of the situation, and try to create a new propritary mail protocol based on Palladium, for Windows users only = everyone not using Windows lose.
This wouldn't happen because Microsoft is not entirely stupid. This would be akin to Windows Media Player only playing WMA, or Internet Explorer only working with IIS sites.
It would also be akin to Windows supporting Win32 instead of POSIX applications, or to new versions of MS Office having new file formats that other suites can't read. The main difference between your examples and mine are that my two are Microsoft's cash cows, and two of the three programs in your list have to be given away free.
The idea of an open standard is an open interface (file format, API, etc.) that allows sw for various vendors to interoperate. This way you don't even need to see the source to write complementary or competing sw, you just need the spec.
I think it takes a little more than that. Win32 and the Excel functions are open standards by that definition, but that's not a huge help to the Wine and Gnumeric projects, who have had to do some reverse engineering to make sure their software conforms to the API as implemented by Windows and Excel where that implementation differs from or is a superset of the APIs as published by Microsoft. Even if Microsoft published absolutely everything and followed all it's own specs, they would still leave other vendors at a perpetual disadvantage, because Microsoft gets to see their own APIs and write software which uses them from the most preliminary design phase, whereas other vendors have to wait until Microsoft makes those APIs public, after enjoying a headstart of it's own choosing. For example, Excel has been cloned adequately, but AFAIK the closest thing to an independent Windows API implementation is Wine, which is now 10 years old and still in need of work.
From an economic standpoint, it's important not just that everyone has access to the standard, but that everyone has the same access. From a practical standpoint it's important not just that multiple conforming implementations are theoretically possible but that multiple conforming implementations (or at least free conforming implementations) actually exist.
it is understandable that Dr. Vinge (or his publisher) might have preferred for the book to be digitally protected.
Yes, it's very understandable, but it isn't going to happen. I wonder whether they're simply satisfied to make it harder for people to get at the cleartext, or whether some snakeoil salesman managed to convince them that they've got magic uncrackable "digital protection". Based on Vinge's net experience I'd guess the former.
Since that is unlikely to change anytime soon
Anyone want to put money on that?;-)
as digitally-protected e-book formats go, the PDM format is actually quite decent. Free reader software is available for the Palm, PocketPC, Macintosh, and Windows platforms (and the Windows version also runs flawlessly under WINE on Linux)
Translation: the most capable programmers might unobfuscate the cleartext after it's already been decrypted in/proc/1337/mem, but if you don't think you're up to that you can probably spy on the X datastream, compile a couple wrapper functions on top of the Wine font API, or simply write a screenshot->ocr script to grab it all.
I actually kind of like DRM when it's stuff like this which doesn't take away your control of your own hardware - it feels much less like an invasion of consumer rights and more like a fun hacker game. I worry about it backfiring on the creators, though - if the people who buy copyrighted products have to get cracked versions in order to have unhobbled access to the media they've already purchased, they're more likely in the future to just get the cracked version instead of a purchase rather than in addition to one.
It means that they can launch a vehicle on top of a commerical GEO booster, and that the vehicle can make its own way out of geostationary orbit into lunar orbit.
I don't think any launches will be done exactly this way - it's more efficient to use thrust deeper inside a gravity well, so you can get more deltaV from the same fuel by boosting into a highly elliptical orbit (e.g. a geosynchronous transfer orbit) and then do all your burns near perigee, which raises your apogee but keeps your perigee down at LEO altitudes until you finally hit escape velocity or a lunar capture trajectory.
The payload in the Apollo program was launched from a Saturn V, which can put nearly 120,000 kg in low orbit and so had enough oomph to put it's payload immediately into a lunar trajectory. The payload for this mission will be launched from an Ariane V, which can only put ~16,000 kg in low orbit, but at (IIRC) a tenth the price.
Hopefully they can perfect the ion drive, however through this to increase the speed and payload capacity.
The drive itself is pretty near perfect; the problem is that if you're going to kick out exhaust at such insane velocity that you don't need a whole lot reaction mass to get good deltaV, then you need a whole lot of energy to get good deltaV instead. And these guys are getting that energy from solar panels, which takes a while. If we had that anti-matter reactor you want (or cold fusion, or anything else providing lots of energy from little mass) we might eventually want something fancy like VASIMR, but in the short run we'd probably just plug the reactor in to bigger or more ion drives.
There's a difference to 0.02% of the web users in the world visiting your site over 1 year, and those 0.02% hitting your site in 24 hours.
Yes, there is. The difference is efficient communications, and if you have reason to believe that efficient communication between those people may exist (hint: it uses a world-spanning electronic data network) then you'll want to expect the visits to come within 24 hours.
Stop blindly sticking up for Slashdot
Is blindly a code word for "without my agreement"? The normal definitions of the word would suggest that I haven't presented reasoning behind my beliefs, and so would make your statement incorrect.
and spouting the bable that you've read here before.
Slashdot publishes hyperlinks to popular sites, as does nearly every other page on the WWW. You appear to be using the wrong network.
I don't say that sarcastically - I mean it. Specifically, I'm being an idiot because I have a cell phone plan which charges outrageously high fees for excess minutes and which makes it unnecessarily difficult to find out how close I am to using up the monthly minutes allowance and beginning to incur those costs.
Imagine you ran a hobby site on a 2Gb per month, $10 per extra 50Mb deal. You might only find out 6 hours later, by which time you'd been hit with a bill of $500 or something. Nice, eh?
My ego is slightly assuaged, however, by knowing that there are people even more foolish than I am, who would not only sign a contract that lets them be overbilled for excess use but would do so for a service in which that excess use can occur at any time, without their knowledge, as a consequence of unlikely but normal events. Aren't there a lot more web hosts to choose from than cell phone providers, as well? Wouldn't it make sense, if you can't afford to pay x*$100 for web hosting, to pick a provider that stopped serving your pages after (x-1)*$100 worth of bandwidth had been used?
There are over half a billion people on the internet now, and another million or so start using it every week. If you're gambling that your web page is interesting to any of those people but that it will never be interesting to more than 0.02% of them, you're not playing with very good odds.
The "We mostly rock" statement was referring to a different benchmark (the one in the story's second link), in which the scheduler performance on single processor machines more than tripled (and performance on 8-way machines went up ~50%) between 2.5.30 and 2.6.0-test5. The first link's benchmark isn't very impressive, like you point out, but it's also not the same program.
This is starting to become very notable in Texas, where everyone and their brother wants to swipe your TXDL while you're paying.
Where are you shopping? The only people in Austin who want to see my license are checking the photo and name against me and my credit card, and I've never seen them swipe it.
That's what the lack of a human-readable audit trail avoids: those pesky "ballots" that people might want to recheck for accuracy. The Diebold systems might not be any better than hanging chads, but you can be sure they'll seem better because there won't be any way to remeasure the results and get a different number.
You're comparing the operators of these services to spoiled children, when they've done more for the anti-spam cause than nearly everyone who will ever read your comment. What did they do to deserve that? If they are being selfish for giving up their efforts, doesn't that make you and I even more selfish for never making an effort in the first place?
Who wants to become a volunteer in a world where if your efforts fail you will be seen as a failure and if they succeed you will be seen as an entitlement?
Whether they intend to or not, I don't think they CAN file these kinds of suits.
They can file as baseless a lawsuit as they want; welcome to America!
For one thing, it will make them look horrible.
They already look horrible, and they don't care.
And MS and Sun, as investors in this scheme, will be made out in the press to be accomplices.
If the press hasn't made them out to be accomplices in SCO vs. IBM, I don't see why SCO vs. Burlington would make any reporters any smarter.
Most of all, they can't risk such a suit actually COMING TO TRIAL.
No, but they can make sure it doesn't come to trial for a long time, use the impending trial to step up their attempts at extortion of other users, use the legal actions as a source of new stock-pumping press releases, and if they're lucky get enough extortion payments from other users (or payola from MS and/or Sun) to keep their profit statements positive for long enough to let Darl get his stock options and start cashing in with the other top execs. SCO doesn't care about any long term viability anymore.
Also, HOW can SCO sue Linux end users BEFORE suing Linux resellers and developers?
By filing the appropriate paperwork. You're still focused on the question, "How can SCO do something so nonsensical?" when we have enough past history to answer, "With ease!"
Isn't a court going to be a little bit curious as to why they seem to be willing to let Linus and the rest of the kernel developers CONTINUE to produce and modify "their code" while only going after END USERS who have no expertise to know what code belongs to whom?
Yup. Courts will also be curious as to why SCO is publically trying to pass off public domain code and independent code from Berkeley specifications as their own property, curious as to why SCO is attempting to charge huge fees to users who have never bought any SCO/Caldera product, and curious as to why SCO has been ignoring the passages in IBM's contract that give IBM sole authority over all the code that IBM writes themselves, even if some of that code was at one time linked to SysV. What SCO's backers need to do is make sure that they get what they're looking for (Sun and MS: a year or two of anti-Linux FUD; SCO and Canopy executives: a market for previously worthless stock; Darl McBride: enough profits on paper for his own stock options to vest and be cashed) before they get any verdicts.
SCO wants the THREAT of lawsuits against users out there. They aren't going to file any.
The threat will be more plausible if they have pending lawsuits against other users. SCO doesn't want any lawsuits to be quickly adjudicated, of course, but if they can get one in the system that isn't scheduled to go up in front of a judge except in a slow timeframe like their IBM lawsuit, they'd love to do so.
Originally, SCO had no intention of suing anyone at all: According to McBride, "obviously Linux owes its heritage to UNIX, but not its code. We would not, nor will not, make such a claim."
But at the beginning of August: "The legal liability for Linux clearly rests with the end user."
McBride and company have never kept their story straight in the past - expecting them to do so now that they've made another statement we like would probably be overly optimistic.
Tell two of your friends about vreceipt, and have them tell two of their friends, etc. We need to have everybody asking their congressmen not only "Why are we implementing easily tampered with voting systems?", but "Why are we implementing them instead of mathematically verifiable alternatives?"
There's a lot to the white paper at that link, but here's the part that makes voting receipts possible: The receipts are given out and are identical to an entry in the published "first stage" election results, so you can verify that your vote was counted. The receipts have been repeatedly encrypted with different election officials' public keys, so nobody who wants to buy/blackmail your vote can tell who you voted for (but you can, by examining the original "2-ply" receipt which you pull apart before leaving the booth). Election officials scramble the order in which results are published after each decryption stage, so nobody can trace your vote from first stage to final cleartext results, but half of the published decryptions are randomly checked so any corruption on the part of the election officials will be caught. You still need to have poll watchers to make sure that a polling site doesn't report more votes than there were voters (since the vreceipt process protects against lost or altered votes, but not illegitimately added votes), but that's much easier than attempting to make sure that even an open source voting machine is doing it's job right.
The fact that temperature changes coincide with increasing levels of a known greenhouse forcing gas, is actually fairly pursuasive. Or did you mean 'mere coincidence.';)
The correlation between CO2 levels and temperature prehistorically looks far too close to be coincidence, but that doesn't necessarily prove which direction any causation went in.
The best competing theory I've seen to global warming is: solar fluctuations (or some other factor) cause the Earth's atmosphere's temperature to change dramatically. This temperature change heats or cools the oceans, which changes the solubility of CO2 in ocean water, which causes the oceans to release or absorb large amounts of the stuff. This explains the correlation between high temperatures and CO2 just as well as global warming does, but it has the added bonus of explaining how those levels were fluctuating wildly even before humanity became pyromaniac.
Granted, I haven't spent a whole lot of time looking into this. Is there evidence to the contrary that I haven't seen yet?
I agree that the headline of the Financial Times is grossly misleading, but for fewer reasons: simply because none of the quotes from Barrett even mention Linux, so there's no reason to believe he isn't just talking about the asian CPU plans.
Even if you didn't read the rest of the article, it's clear he's talking about "proprietary standards," which linux clearly is not.
Here, however, I'm not so sure. Just because something is "clearly" true to you, me, or anyone else capable of handling a dictionary and boolean logic doesn't mean it's necessarily clear to a business executive. Have you read Darl McBride's open letter? Jonathan Schwartz's eWeek interview? Perhaps Craig Barrett has also fallen into this expanding black hole from whence no rational thought can escape.
Many applications (i.e. the entire gamut of KDE applications EVEN AT VERSION 3.2) *still* don't come with adequate (or even *any*) documentation, for example.
Could you give an example? My installation (3.1.4) seems to have multi-chapter manuals for three or four dozen of the KDE programs.
Maybe I've watched too much Babylon 5, but I just can't get read the phrase 'President Clark' without looking around for Nightwatch.
Didn't you get the memo? Someone decided that TIPS was a better name than Nightwatch.
But seriously, you can see the Democratic candidates' positions (in soundbite form) on "homeland security" at CNN. Nothing very concrete from Clark, but Howard Dean is listed as:
Against military tribunals, labeling of "enemy combatants"
Repeal parts of Patriot Act that restrict basic liberties
Or do they have to come down as well?
These are all suborbital craft being tested, so yeah, they have to come down, but it's mostly due to Newton's rules rather than the XPrize's.
I for one would love to be able to vote from the comfort of my home/work/cafe without having to wait in lines.
I would love to be able to vote from the comfort of your home/work/cafe, too. At the moment I think that will be easiest to do with a worm that infects your computer to make a man-in-the-middle attack possible, but we'll have to see Verisign's implementation before anyone works out the actual details. Fortunately for people who are tired of that "one man, one vote" nonsense, it's impossible for Verisign to develop secure online voting because no matter how bulletproof their own software is, the systems will still be as insecure as the operating system, server, email client or gullible users they're connected to.
Try to look at it as a form of "weighted" democracy: those people who can't figure out that they need to fix their IIS/WinXP/sshd/whatever holes have their votes weighted by 0, those people who can figure out how to exploit those holes have their votes weighted by 1000s.
Why pump?
Because otherwise either you can only fire the engines on one stage at a time (which requires twice as much engine weight to give you the same thrust at liftoff) or the staging doesn't help you (as the "upper" stage runs out of fuel at the same time as the "lower" one).
Moving fuel across a juncture seems like a big risk.
Possibly. We've seen what happens when a juncture containing fuel (SRB connections) fails, although perhaps that's not a fair comparison since the TSTO fuel wouldn't actually be combusting inside its pipe.
0. Constrains you to a liquid fuel, solid boosters are disallowed.
If you want solid boosters, you might as well launch an expendible rocket, take months to set it up, and don't worry about reducing complexity with fewer stages. I think the TSTO would be advantagious as a reusable, quick turnaround design.
1. Must add mass in the form of pump equipment.
Not much mass. The rate of fuel flow in this design would only be 50% larger than in a more traditional rocket: for every kilogram of fuel moved from one rocket to the other, you've also got to transfer a kilogram to the engines of each rocket anyway.
2. Vehicle's mass over time is more complicated (shift from side to side), trajectory prediction is harder.
Somewhat more complicated, but that's what we've got computers for, and if you've got a VTVL design already then the engine throttling/gimbaling requirements during launch aren't any worse than the requirements for your landing.
3. The join-point where fuel passes from one rocket to another would be a nasty point for failure. (At least it doesn't have to be streamlined. By the time they split, air resistant is not a worry)
Horizontal separation would be earlier than you'd expect since the stages aren't efficiently asymmetrically sized like they are in most staged rockets. I seem to remember coming up with back-of-the-envelope numbers of roughly Mach 4, less than 100,000 feet up.
4. Burning from the bottom while siphoning from the top? Danger danger!
Please explain? You wouldn't want the pipe inlets to be at the top of either fuel tank.
NASA isn't building a Delta Clipper style SSTO because when they did fund an SSTO prototype they picked the one (X-33) with the most fancy untested technologies (linear aerospike engine, multilobed composite fuel tanks, lifting body VTHL design), and so it ran over budget and over schedule and failed to even produce a flying half scale prototype.
American aerospace companies aren't building a Delta Clipper style SSTO because mergers have left us with only two large firms, space launcher development is too expensive for any new competition to break into, and the existing companies are often working for "cost plus" contracts, a zany system in which your profit is a fixed percentage of your costs and so if you build a cheaper launcher you actually make a little less money instead of much more.
It also doesn't help that SSTO designs have paper thin weight margins, so not everyone agrees that getting one to orbit is possible even with modern materials. Personally, I'd like to see someone build a siamese TSTO (two nearly identical stages, mated horizontally, with one of them pumping fuel into the other during liftoff so the "upper stage" still has full fuel tanks when they separate) to mitigate that risk, and then if the finished product comes out light enough you can launch just one half of it alone to put smaller payloads in orbit or to fly suborbital.
That's certainly interesting, but guess what? Many scientists have done better (and much more expensive) measures, so we already know the speed of light quite well.
Damn - are you telling me Nature won't be publishing the paper I submitted?
This wouldn't happen because Microsoft is not entirely stupid. This would be akin to Windows Media Player only playing WMA, or Internet Explorer only working with IIS sites.
It would also be akin to Windows supporting Win32 instead of POSIX applications, or to new versions of MS Office having new file formats that other suites can't read. The main difference between your examples and mine are that my two are Microsoft's cash cows, and two of the three programs in your list have to be given away free.
The idea of an open standard is an open interface (file format, API, etc.) that allows sw for various vendors to interoperate. This way you don't even need to see the source to write complementary or competing sw, you just need the spec.
I think it takes a little more than that. Win32 and the Excel functions are open standards by that definition, but that's not a huge help to the Wine and Gnumeric projects, who have had to do some reverse engineering to make sure their software conforms to the API as implemented by Windows and Excel where that implementation differs from or is a superset of the APIs as published by Microsoft. Even if Microsoft published absolutely everything and followed all it's own specs, they would still leave other vendors at a perpetual disadvantage, because Microsoft gets to see their own APIs and write software which uses them from the most preliminary design phase, whereas other vendors have to wait until Microsoft makes those APIs public, after enjoying a headstart of it's own choosing. For example, Excel has been cloned adequately, but AFAIK the closest thing to an independent Windows API implementation is Wine, which is now 10 years old and still in need of work.
From an economic standpoint, it's important not just that everyone has access to the standard, but that everyone has the same access. From a practical standpoint it's important not just that multiple conforming implementations are theoretically possible but that multiple conforming implementations (or at least free conforming implementations) actually exist.
it is understandable that Dr. Vinge (or his publisher) might have preferred for the book to be digitally protected.
;-)
/proc/1337/mem, but if you don't think you're up to that you can probably spy on the X datastream, compile a couple wrapper functions on top of the Wine font API, or simply write a screenshot->ocr script to grab it all.
Yes, it's very understandable, but it isn't going to happen. I wonder whether they're simply satisfied to make it harder for people to get at the cleartext, or whether some snakeoil salesman managed to convince them that they've got magic uncrackable "digital protection". Based on Vinge's net experience I'd guess the former.
Since that is unlikely to change anytime soon
Anyone want to put money on that?
as digitally-protected e-book formats go, the PDM format is actually quite decent. Free reader software is available for the Palm, PocketPC, Macintosh, and Windows platforms (and the Windows version also runs flawlessly under WINE on Linux)
Translation: the most capable programmers might unobfuscate the cleartext after it's already been decrypted in
I actually kind of like DRM when it's stuff like this which doesn't take away your control of your own hardware - it feels much less like an invasion of consumer rights and more like a fun hacker game. I worry about it backfiring on the creators, though - if the people who buy copyrighted products have to get cracked versions in order to have unhobbled access to the media they've already purchased, they're more likely in the future to just get the cracked version instead of a purchase rather than in addition to one.
It means that they can launch a vehicle on top of a commerical GEO booster, and that the vehicle can make its own way out of geostationary orbit into lunar orbit.
I don't think any launches will be done exactly this way - it's more efficient to use thrust deeper inside a gravity well, so you can get more deltaV from the same fuel by boosting into a highly elliptical orbit (e.g. a geosynchronous transfer orbit) and then do all your burns near perigee, which raises your apogee but keeps your perigee down at LEO altitudes until you finally hit escape velocity or a lunar capture trajectory.
And the payload isn't really greater at all.
The payload in the Apollo program was launched from a Saturn V, which can put nearly 120,000 kg in low orbit and so had enough oomph to put it's payload immediately into a lunar trajectory. The payload for this mission will be launched from an Ariane V, which can only put ~16,000 kg in low orbit, but at (IIRC) a tenth the price.
Hopefully they can perfect the ion drive, however through this to increase the speed and payload capacity.
The drive itself is pretty near perfect; the problem is that if you're going to kick out exhaust at such insane velocity that you don't need a whole lot reaction mass to get good deltaV, then you need a whole lot of energy to get good deltaV instead. And these guys are getting that energy from solar panels, which takes a while. If we had that anti-matter reactor you want (or cold fusion, or anything else providing lots of energy from little mass) we might eventually want something fancy like VASIMR, but in the short run we'd probably just plug the reactor in to bigger or more ion drives.
There's a difference to 0.02% of the web users in the world visiting your site over 1 year, and those 0.02% hitting your site in 24 hours.
Yes, there is. The difference is efficient communications, and if you have reason to believe that efficient communication between those people may exist (hint: it uses a world-spanning electronic data network) then you'll want to expect the visits to come within 24 hours.
Stop blindly sticking up for Slashdot
Is blindly a code word for "without my agreement"? The normal definitions of the word would suggest that I haven't presented reasoning behind my beliefs, and so would make your statement incorrect.
and spouting the bable that you've read here before.
Slashdot publishes hyperlinks to popular sites, as does nearly every other page on the WWW. You appear to be using the wrong network.
I don't say that sarcastically - I mean it. Specifically, I'm being an idiot because I have a cell phone plan which charges outrageously high fees for excess minutes and which makes it unnecessarily difficult to find out how close I am to using up the monthly minutes allowance and beginning to incur those costs.
Imagine you ran a hobby site on a 2Gb per month, $10 per extra 50Mb deal. You might only find out 6 hours later, by which time you'd been hit with a bill of $500 or something. Nice, eh?
My ego is slightly assuaged, however, by knowing that there are people even more foolish than I am, who would not only sign a contract that lets them be overbilled for excess use but would do so for a service in which that excess use can occur at any time, without their knowledge, as a consequence of unlikely but normal events. Aren't there a lot more web hosts to choose from than cell phone providers, as well? Wouldn't it make sense, if you can't afford to pay x*$100 for web hosting, to pick a provider that stopped serving your pages after (x-1)*$100 worth of bandwidth had been used?
There are over half a billion people on the internet now, and another million or so start using it every week. If you're gambling that your web page is interesting to any of those people but that it will never be interesting to more than 0.02% of them, you're not playing with very good odds.
The "We mostly rock" statement was referring to a different benchmark (the one in the story's second link), in which the scheduler performance on single processor machines more than tripled (and performance on 8-way machines went up ~50%) between 2.5.30 and 2.6.0-test5. The first link's benchmark isn't very impressive, like you point out, but it's also not the same program.
This is starting to become very notable in Texas, where everyone and their brother wants to swipe your TXDL while you're paying.
Where are you shopping? The only people in Austin who want to see my license are checking the photo and name against me and my credit card, and I've never seen them swipe it.
That's what the lack of a human-readable audit trail avoids: those pesky "ballots" that people might want to recheck for accuracy. The Diebold systems might not be any better than hanging chads, but you can be sure they'll seem better because there won't be any way to remeasure the results and get a different number.
You're comparing the operators of these services to spoiled children, when they've done more for the anti-spam cause than nearly everyone who will ever read your comment. What did they do to deserve that? If they are being selfish for giving up their efforts, doesn't that make you and I even more selfish for never making an effort in the first place?
Who wants to become a volunteer in a world where if your efforts fail you will be seen as a failure and if they succeed you will be seen as an entitlement?
Whether they intend to or not, I don't think they CAN file these kinds of suits.
They can file as baseless a lawsuit as they want; welcome to America!
For one thing, it will make them look horrible.
They already look horrible, and they don't care.
And MS and Sun, as investors in this scheme, will be made out in the press to be accomplices.
If the press hasn't made them out to be accomplices in SCO vs. IBM, I don't see why SCO vs. Burlington would make any reporters any smarter.
Most of all, they can't risk such a suit actually COMING TO TRIAL.
No, but they can make sure it doesn't come to trial for a long time, use the impending trial to step up their attempts at extortion of other users, use the legal actions as a source of new stock-pumping press releases, and if they're lucky get enough extortion payments from other users (or payola from MS and/or Sun) to keep their profit statements positive for long enough to let Darl get his stock options and start cashing in with the other top execs. SCO doesn't care about any long term viability anymore.
Also, HOW can SCO sue Linux end users BEFORE suing Linux resellers and developers?
By filing the appropriate paperwork. You're still focused on the question, "How can SCO do something so nonsensical?" when we have enough past history to answer, "With ease!"
Isn't a court going to be a little bit curious as to why they seem to be willing to let Linus and the rest of the kernel developers CONTINUE to produce and modify "their code" while only going after END USERS who have no expertise to know what code belongs to whom?
Yup. Courts will also be curious as to why SCO is publically trying to pass off public domain code and independent code from Berkeley specifications as their own property, curious as to why SCO is attempting to charge huge fees to users who have never bought any SCO/Caldera product, and curious as to why SCO has been ignoring the passages in IBM's contract that give IBM sole authority over all the code that IBM writes themselves, even if some of that code was at one time linked to SysV. What SCO's backers need to do is make sure that they get what they're looking for (Sun and MS: a year or two of anti-Linux FUD; SCO and Canopy executives: a market for previously worthless stock; Darl McBride: enough profits on paper for his own stock options to vest and be cashed) before they get any verdicts.
SCO wants the THREAT of lawsuits against users out there. They aren't going to file any.
The threat will be more plausible if they have pending lawsuits against other users. SCO doesn't want any lawsuits to be quickly adjudicated, of course, but if they can get one in the system that isn't scheduled to go up in front of a judge except in a slow timeframe like their IBM lawsuit, they'd love to do so.
SCO has no intention to sue Linux end-users
Originally, SCO had no intention of suing anyone at all:
According to McBride, "obviously Linux owes its heritage to UNIX, but not its code. We would not, nor will not, make such a claim."
But at the beginning of August:
"The legal liability for Linux clearly rests with the end user."
"We have the ability to go to users with lawsuits and we will if we have to."
McBride and company have never kept their story straight in the past - expecting them to do so now that they've made another statement we like would probably be overly optimistic.
Tell two of your friends about vreceipt, and have them tell two of their friends, etc. We need to have everybody asking their congressmen not only "Why are we implementing easily tampered with voting systems?", but "Why are we implementing them instead of mathematically verifiable alternatives?"
There's a lot to the white paper at that link, but here's the part that makes voting receipts possible: The receipts are given out and are identical to an entry in the published "first stage" election results, so you can verify that your vote was counted. The receipts have been repeatedly encrypted with different election officials' public keys, so nobody who wants to buy/blackmail your vote can tell who you voted for (but you can, by examining the original "2-ply" receipt which you pull apart before leaving the booth). Election officials scramble the order in which results are published after each decryption stage, so nobody can trace your vote from first stage to final cleartext results, but half of the published decryptions are randomly checked so any corruption on the part of the election officials will be caught. You still need to have poll watchers to make sure that a polling site doesn't report more votes than there were voters (since the vreceipt process protects against lost or altered votes, but not illegitimately added votes), but that's much easier than attempting to make sure that even an open source voting machine is doing it's job right.
In case it's not obvious, I only intended to italicize that first paragraph I was quoting.
The fact that temperature changes coincide with increasing levels of a known greenhouse forcing gas, is actually fairly pursuasive. Or did you mean 'mere coincidence.' ;)
The correlation between CO2 levels and temperature prehistorically looks far too close to be coincidence, but that doesn't necessarily prove which direction any causation went in.
The best competing theory I've seen to global warming is: solar fluctuations (or some other factor) cause the Earth's atmosphere's temperature to change dramatically. This temperature change heats or cools the oceans, which changes the solubility of CO2 in ocean water, which causes the oceans to release or absorb large amounts of the stuff. This explains the correlation between high temperatures and CO2 just as well as global warming does, but it has the added bonus of explaining how those levels were fluctuating wildly even before humanity became pyromaniac.
Granted, I haven't spent a whole lot of time looking into this. Is there evidence to the contrary that I haven't seen yet?
I've taken boxes from 7.1 to 9 without rebooting.
How does that work? Do you just do an "rpm -F" on all the new version's packages? Start anaconda on a running system?
I agree that the headline of the Financial Times is grossly misleading, but for fewer reasons: simply because none of the quotes from Barrett even mention Linux, so there's no reason to believe he isn't just talking about the asian CPU plans.
Even if you didn't read the rest of the article, it's clear he's talking about "proprietary standards," which linux clearly is not.
Here, however, I'm not so sure. Just because something is "clearly" true to you, me, or anyone else capable of handling a dictionary and boolean logic doesn't mean it's necessarily clear to a business executive. Have you read Darl McBride's open letter? Jonathan Schwartz's eWeek interview? Perhaps Craig Barrett has also fallen into this expanding black hole from whence no rational thought can escape.
Many applications (i.e. the entire gamut of KDE applications EVEN AT VERSION 3.2) *still* don't come with adequate (or even *any*) documentation, for example.
Could you give an example? My installation (3.1.4) seems to have multi-chapter manuals for three or four dozen of the KDE programs.