Those articles are still quite valid - and will remain so.
So long as a float is still 32 bits and a double 64, you'll get about that degree of precision. It's not that the hardware is inaccurate - they all do pretty much the best they can with the information provided.
Roundoff errors and other evils of floating point representations are here to stay.
However, you can't just automatically decide to punt and use fixed point arithmetic. There is a 'tension' between dynamic range and precision. If you want reliable precision, you can't have large dynamic ranges for your numbers and vice-versa.
The biggest and best improvement we've seen since the early '90s is that doing your work in double precision is much less of a penalty than it used to be (when compared to working in single precision or integers).
With 64 bit machines, we should expect that penalty to become yet smaller.
So if speed is an issue, modern machines can be more precise - but if speed was not an issue, machines of the early '90s were every bit as precise as the latest wizz-bang 64 bit CPU. IEEE math hasn't changed much (at all?) in that time.
> * Has anyone, besides SCO, looked at the Linux code and tried to determine what might have come from SCO, and what might have come from a common predecessor?
SCO's code is closed source - and they won't tell us which parts they claim are problematic.
> * FUD FUD FUD: Lawsuits can last years and SCO's, whatever its merits, may cause Fear, Uncertainty and Doubt, freezing many Linux customers and Linux contributors (who don't want to waste their time or be sued) for as long as it lasts. How can the FUD be countered?
In exactly the way slashdotters are countering it - but making it clear that these claims are laughable.
> * If SCO wins, what can be done? What will the consequences be?
Some people and/or companies get bitten - the rest of us code around the parts that SCO claim as theirs - since presumably they'd have to reveal them in court. Within a month, it's all over.
> * IBM will act in its own interests, of course, and not in the interests of the Linux community; what should we expect from them?
We expect them to have better and more well paid lawyers than SCO and a bottomless bucket of money with which to defend themselves. Under American law, that makes them innocent of whatever it was.
> * How time-consuming would it be to replace all SCO code (if it does exist)?
We assume it's going to be remarkably simple to replace code. However, if by some bizarre fluke it's a patent or something that was violated, then that might do some serious damage (eg if SMP support has to be removed). It's not going to happen though.
> Should it be done now, with all the code they claim regardless of merit, to preempt their case?
If they would only tell us what code was being discussed, I'm sure it would already have been rewritten just to shut them up.
> * Is including controlled technologies in Linux the equivalent of violating US export laws? That could have implications far beyond SCO's suit.
Yeah - that's kinda worrying. But Linux is (to a large degree) IMPORTED into the USA from Europe and elsewhere - it would be REALLY difficult to figure out where the banned technologies came from.
You miss the point. SCO is already dead. Linux has erased their market.
Realising this, the only way they could possibly survive is to attempt to leverage whatever they actually own in terms of rights to UNIX to sue IBM for a billion dollars.
It doesn't matter a damn to them what customers (both existing and potential) think of them because without this big chunk of change, they are already dead and with that much money, they can buy themselves back into favor. (Imagine "We've decided to donate $200,000,000 to OpenSource development", etc, etc)
If by some remarkable miracle, they pulled this off and walked away with a gigabuck - they'd go on to sue every Linux distributor and (ultimately) try to collect license fees from every Linux user. The ideal business model - big cash reserves, big income from licensing - no products, no product support.
They have NOTHING to lose - without this, they die. The effect of this on whatever customers they still have is of no concern to them.
> I wonder what the statistical liklihood of having similiar blocks of code > of some signifigant size that happen to be the same (excluding format and > variable differences). I mean there's only so many ways one can > _intelligently_ code a given function
I think the odds of this code "just happening" to be the same is vanishingly small.
How many different forms can a line of code take? A thousand maybe? (I'm sure it's a LOT more than that - but let's go with just 10 different C code statements that could be used at any given point in the code.)
Starting at any given line in the Linux source, the chances of the first line of the UNIX source being the same is 1:10, the chances of the first TWO lines being the same is 1:100, the chances of N lines of code matching is one in ten to the power N. For 80 lines to match, that's a one in 10^80 AGAINST chance (a VERY large number). If there are 3 million lines of code in Linux, then there are 3 million (or so) places where you could start your comparison - so the final odds of finding 80 lines of matching code by chance alone is something like 10^74 to one against.
When you also consider matching comments and variable names, the odds are lengthened considerably.
When you consider that many 80 line sequences are not legal C, the odds shorten some.
This isn't by any means a rigorous scientific measure of the improbability of an exact match coming up by chance - but the 'back-of-envelope' math makes it evident that the odds are overwhelming.
So: By any reasonable measure of doubt, even a dozen lines of identical code would be as close to a certainty that one was copied from the other as you could possibly imagine.
If there are indeed 80 contiguous lines of near identical code with identical comments - then I think we have to accept that the UNIX and Linux code came from the same place. That's too much to have come about by chance or parallel evolution. However, that doesn't make it an open-and-shut case for SCO:
1) Did the code indeed come from UNIX to Linux and not from some other common source such as BSD - or from Linux to UNIX. Given the lack of version control in early versions of UNIX, it's going to be hard to show *where* it came from.
2) Where is this code? If it's in the heart of the kernel then that's one thing - but if it's in some obscure utility or in a device driver, then it's quite possible that hardly anyone is using this code anyway.
3) You can bet that within an hour of SCO revealing the location of this code, there will be a replacement for it out there. So they'd only be able to claim royalties for past use...not off into the future.
4) Novell claim to own the copyrights and patents to UNIX. If that's true - then who cares about SCO's claims? Now, if Novell were to sue - that would be a completely different matter.
5) It's hard to see how SCO could claim to have been materially damaged by this. It's pretty darned obvious that if the Linux community had not had access to those 80 lines, we'd have written them ourselves...it's not like "Oh no, we don't know how to write that function - so we'll have to steal it from UNIX." Linux's and SCO's sales would not have been different in the slightest whether that code was copied or written from scratch.
We *NEED* more facts. What file and what range of line numbers are we talking about here? Why are SCO keeping that so secret?
Yeah - well, there are always a couple of idiots in any group of people!
The Geocaching.com web site specifically lists places like this as locations where geocaches are NOT allowed and will de-list caches that are reported to them as being in unsuitable locations.
If this ever became a serious problem, the security chiefs of these places could easily hop over to www.geocaching.com, type in their own lat/long and get a handy list of any caches placed close to their facility.
As it is, it was probably a useful exercise for their state of readiness.
Re:Grounds = Yet Another Phoney Terrorism Alert
on
Geocaching Crackdown?
·
· Score: 1
That's silly!
1) There is a COMPLETE database of all these so-called "false-positives" on
the www.geocaching.com web site!
2) Most Geocaches contain a standard spiel in a plastic baggie explaining that
this is a geocache and that you can go to the web site to find out all about
it.
If this causes our spies problems...well...words fail me!
Look at the geocaching site and count the number of visitors per year to each site - tha answer is about a couple of dozen. New sites tend to attract a flurry of interest - which fades to very low levels after a month or so.
Geocaching is a hobby that scales naturally. Most cache SEARCHERS also plant NEW caches. If the number of players doubles, so will the number of caches. So the number of visitors per cache will stay approximately constant. (In fact, it will gradually drop over time as each cacher plants more caches at time goes on - but typically visits fewer and fewer as they seek harder caches - and caches with complicated clues and pre-conditions.)
So - I don't see how we'll ever get to a situation where there are clearly beaten trails to every Geocache.
That's CERTAINLY not the case right now and I have the torn T-shirts and bramble wounds on my legs to prove it!
"Large numbers of people traipsing to the same point causes erosion"
Have you *looked* at the www.geocache.com site? Most caches are visted a couple of dozen times a year. I can't think of any location that's *that* fragile.
Note that geocaches are typically placed in locations where there are NOT a lot of 'muggles' (non-geocachers) around. It looks very odd to be hiding/finding a tupperware container (or, worse still, an ultra-suspicious ammo box) where a lot of people go.
Most parks in our area have either zero or one geocaches in them and probably about 10,000 pieces of actual trash. Put another way, within 100 miles of my home, there are 400 GeoCaches. How many items of trash are there within 100 miles?
So, if I remove ten pieces of trash, then add one geocache, the park is winning overall.
Even if you consider a geocache to be 'trash', it's an utterly negligable increment on the load of trash in most of the parks I've visited.
Then there is the 'cache in - trash out' initiative where geocachers go a-hunting with a large black bin bag and remove LARGE quantities of trash along with visiting the geocache.
Geocaching is at worst benign and at best a glorious way to find great new places to go. It's an ideal use of public land.
Blenders interface *is* a problem, but it's been shown time and time again that *SOME* people take to it like a duck to water - and others never get to grips with it no matter how hard they try.
If you happen to be one of the lucky people for whom blender 'clicks' you'll be unable to understand why on earth anyone else would be unable to understand it.
If you are one of the people who simply cannot cope with the interface (which pretty much everyone admits is 'unusual') then no amount of trying will enable you to become proficient in it.
That's a terrible, terrible shame - but I'm afraid its a fact of life.
Of course if you look at the 'blender community' you'll find that everyone is in the first group and people like pcbob will tell you that people in the second group just aren't trying hard enough.
I'm one of the second group - I've done the tutorials, I've read the book and I simply cannot become proficient in blender. OTOH, there is no other 3D modeller that I've tried that have given me significant learning difficulties. I wish I could like blender - and I even contributed $100 to the fund to 'free' it because I think it's an important piece of software.
I don't think we can rely on copyrights *ever* expiring. Law makers in the USA have decided that when the constitution says "limited duration" - it actually means "limited to a billion, trillion years" or something. Under pressure from all the usual MPAA/RIAA interests they are increasing the lifetime of copyright by an average of more than a year each year.
However, your point is well taken.
Re:Superconducting Super Collider (SSC)
on
Shuttle Politics
·
· Score: 3, Insightful
No - it doesn't prove that at all. He's a Texas politician - and the SSC was built in Waxahachi Texas. (I live just a few miles from the large *semi*-circular hole in the ground that is the remains of that project. Do you still wanna bet that he had no vested interests in the project?
Re:Soldiers aren't worth as much.
on
Shuttle Politics
·
· Score: 2, Interesting
> If you die, in service, your family might get enough for a funeral. > If you happen to be in an office building that is the target of a high > profile attack (Sept 11) your family will get millions.
If you die in service - you were a volunteer who knew (or should have known) that this could happen. You get paid good money for taking that risk. Your family know that this could happen - and you impose that risk on them when you choose to sign up.
If you work in a supposedly safe office job - or working in a restaurant or cleaning an office building, you do not expect to die that way. Your family has a reasonable expectation that this kind of thing won't happen.
And (struggling to get back on-topic) if you are an astronaut - you and your family should certainly be aware that there's a one in fifty-ish chance of you not surviving a mission.
There is a difference - I don't know if it's enough of a difference to explain this disparity - but you can't utterly discount it.
So long as there are astronauts.
on
Shuttle Politics
·
· Score: 2, Insightful
Fixing these craft to improve those odds of survival is an unending thing. It's like debugging a ten million line software application - you'll never get the last bug. Fixing THIS problem may well be a complete waste of time since it'll probably never happen this way again. Sure, other shuttles will crash if we continue to fly them - but I'd be very suprised if the exact same problem happened again. Hence, it's irrelevent whether you fix this problem or not - even designing an entire new manned space system may not dramatically improve people's odds of surviving a round trip to space.
But so long as the astronauts like those odds, there is no really good reason not to continue to fly the existing shuttle fleet. A 98% chance of survival is OK for quite a lot of people to get a once-in-a-lifetime chance to get into space. If any of them believed the shuttle fleet was anything like 100% safe, that thought must have been dispelled by the first shuttle accident.
A 2% chance of dying is not a good risk for (say) driving to work every day - but for a chance at doing something utterly amazing which you'll only get to do once or twice in an entire career - I don't think you'd find trouble getting volunteers.
Driving your car to work every day for a year gives you a one in 124 chance of dying or being seriously disabled. Driving to work every day of your life is MUCH more risky than taking a round trip to the ISS in a shuttle.
The actual capital cost of the shuttle fleet is significant - but if your only other plan is to ground them permenantly, you might as well fly them to destruction instead - either way, the cost of losing them (in purely monetary terms) is the same.
I'd bet good money that those astronauts who were sitting up in the ISS last week would have preferred to risk coming home in an un-fixed shuttle than coming home in that ratty old russian ship (which incidentally came close to killing them all as it was).
The trouble here seems to be that the law only says that if you have copied a copyrighted work under the special conditions of fair use, you won't be sued.
However, it doesn't guarantee that you physically *can* copy the copyrighted work in the first place.
That's the heart of the problem.
If DRM/DMCA prevents you from making the copy in the first place, the fair use provisions are simply inapplicable - you didn't make a copy - so you didn't violate the copyright law either with or without the fair use provision.
I completely agree that there SHOULD be a law that guarantees you the right to copy a work under certain circumstances - thereby making it illegal to prevent people from using the work in otherwise legal ways.
We need a law like that if only to allow things like search engines and library indexes to work - to allow quotation of one work within another - to allow criticism - for all manner of other reasons.
If we don't make that law then in a few centuries from now, historians are going to discover that in the period of mankinds most prolific production of music, art, literature and software, there is a great gaping black hole where NOTHING of our culture will be accessible. Games, music, movies and ebooks will be heavily encrypted and will only replay on machines with DRM hardware that stopped working centuries ago.
We'll have better understanding of the ancient Greeks than of 3rd millenium Americans because more of their achievements will be accessible still.
Sure Linux/UNIX software has exploits - but that's not what we were talking about. The question was about filtering email viruses. Whilst Sentmail isn't remotely secure, it can't be taken out by something as simple as sending a particular email to it.
I'd never claim that Linux is 100% secure - but I *do* claim that it's immune to email viruses...which is what the virus protection software that ships for Lindows claims to protect you against.
So, you are right - but you are answering the wrong question.
I have seen one guy erase his DOS hard drive this way.
He was a non-technical guy who was trying to install some kind of word processor and ran out of disk space. He phoned up one of us software geeks to ask for help and someone *jokingly* told him that he could always DELETE *.* to make some space! (with whatever recursive flags DOS has - I forget).
Of course about 10 minutes later we had another plaintive phone call "I tried what you said - but now my PC won't boot".
The car analogy can be employed here - but it has to be employed carefully.
In a car, there is a big difference between the tools you use when 'administering' it (things like wrenches and screwdrivers) and the tools you use to drive it (the steering wheel, brakes, accellerator and gear lever). Hence, it's not likely that you'll accidentally remove the wheel bolts while you are simply driving the car around town.
You *can* do your own 'administration' by picking up a wrench, opening the hood and fiddling with the mechanical bits. But if you don't know what you are doing, you can hand it over to a professional car-admin person. Opening the hood is approximately equivelent to entering 'root' mode in Linux. If you own the car, you *can* do it - but it's not something you can do by accident - and it's something that most people won't do unless they are 'car-geeks'.
So it should be with Linux - only more so. The 'normal' tools you use while driving your computer (mv, cp, rm, etc) are the exact same tools you use to swap out the engine, bleed the brakes and drain the transmission fluid. That makes it all the more important that 'mechanic' mode and 'driver' mode are clearly separated.
What Lindows does (in effect) is to place all the critical parts of the car within easy reach of the driver's seat and has you drive using a universal tool that can be used both to turn the steering AND to undo the engine mounting bolts. Since the steering wheel and the engine mounting bolts are quite close to each other, painted the same colour and accessible using the same tools, the chances of this happening by accident are noticably higher than they would be if the engine bolts were under the hood and you had to operate a very special lever in order to open it.
The reason viruses don't exist/spread is because Linux mailers don't treat data as code. Simply reading text files and HTML (sans Java/Javascript) cannot allow a virus to spread by the *simple* mechanisms that allow them to propagate in the Windoze world.
There is also the diversity argument. Under Windoze, there is essentially only one mailer in common use. If you hack a virus to work with that, it'll spread like wildfire because every mail it sends out to replicate itself has a 99% chance of hitting another machine that'll replicate it. In the Linux world, even if all those outgoing mails reach other Linux boxen, the chances are that most of the people it reaches will be running some other mailer and the virus will stop right there. That DRASTICALLY slows down the growth rate of the virus - so even if one were possible, it would spread at a snail's pace and be easy to contain.
I don't think it has anything to do with root access.
However, I regard the idea of running Lindows in root 100% of the time as sheer lunacy. There is such a thing as protecting a user from himself. "rm -R/" should NOT work! If it were both safe and convenient to run in root all the time, most Linux desktop users would do so - however we don't - an overwhelming number of people will voluntarily give up a small measure of convenience in order to gain a measure of protection-from-self-induced-screwups.
> if you run an LCD projector for 4000 hours, it deteriorates... of course, if you're staring at a projecter 8 hours a day, for 500 straight days, maybe you should go outside;)
But there are plenty of applications for these things where the display is permenantly turned on - think of a store display - or an airport information system - or high end adverts. In those cases, running 24 hours a day is very likely - and having the damned thing fail after a mere 166 days would suck badly!
It would have been nice to see the lifetime of large plasma panels in the survey too.
Slashdot Mirror
Those articles are still quite valid - and will remain so.
So long as a float is still 32 bits and a double 64, you'll get about that degree of precision. It's not that the hardware is inaccurate - they all do pretty much the best they can with the information provided.
Roundoff errors and other evils of floating point representations are here to stay.
However, you can't just automatically decide to punt and use fixed point arithmetic. There is a 'tension' between dynamic range and precision. If you want reliable precision, you can't have large dynamic ranges for your numbers and vice-versa.
The biggest and best improvement we've seen since the early '90s is that doing your work in double precision is much less of a penalty than it used to be (when compared to working in single precision or integers).
With 64 bit machines, we should expect that penalty to become yet smaller.
So if speed is an issue, modern machines can be more precise - but if speed was not an issue, machines of the early '90s were every bit as precise as the latest wizz-bang 64 bit CPU. IEEE math hasn't changed much (at all?) in that time.
> * Has anyone, besides SCO, looked at the Linux code and tried to determine what might have come from SCO, and what might have come from a common predecessor?
SCO's code is closed source - and they won't tell us which parts they claim are problematic.
> * FUD FUD FUD: Lawsuits can last years and SCO's, whatever its merits, may cause Fear, Uncertainty and Doubt, freezing many Linux customers and Linux contributors (who don't want to waste their time or be sued) for as long as it lasts. How can the FUD be countered?
In exactly the way slashdotters are countering it - but making it clear that these claims are laughable.
> * If SCO wins, what can be done? What will the consequences be?
Some people and/or companies get bitten - the rest of us code around the parts that SCO claim as theirs - since presumably they'd have to reveal them in court.
Within a month, it's all over.
> * IBM will act in its own interests, of course, and not in the interests of the Linux community; what should we expect from them?
We expect them to have better and more well paid lawyers than SCO and a bottomless bucket of money with which to defend themselves. Under American law, that makes them innocent of whatever it was.
> * How time-consuming would it be to replace all SCO code (if it does exist)?
We assume it's going to be remarkably simple to replace code. However, if by some bizarre fluke it's a patent or something that was violated, then that might do some serious damage (eg if SMP support has to be removed). It's not going to happen though.
> Should it be done now, with all the code they claim regardless of merit, to preempt their case?
If they would only tell us what code was being discussed, I'm sure it would already have been rewritten just to shut them up.
> * Is including controlled technologies in Linux the equivalent of violating US export laws? That could have implications far beyond SCO's suit.
Yeah - that's kinda worrying. But Linux is (to a large degree) IMPORTED into the USA from Europe and elsewhere - it would be REALLY difficult to figure out where the banned technologies came from.
You miss the point. SCO is already dead. Linux has erased their market.
Realising this, the only way they could possibly survive is to attempt to leverage whatever they actually own in terms of rights to UNIX to sue IBM for a billion dollars.
It doesn't matter a damn to them what customers (both existing and potential) think of them because without this big chunk of change, they are already dead and with that much money, they can buy themselves back into favor. (Imagine "We've decided to donate $200,000,000 to OpenSource development", etc, etc)
If by some remarkable miracle, they pulled this off and walked away with a gigabuck - they'd go on to sue every Linux distributor and (ultimately) try to collect license fees from every Linux user. The ideal business model - big cash reserves, big income from licensing - no products, no product support.
They have NOTHING to lose - without this, they die. The effect of this on whatever customers they still have is of no concern to them.
Yes - indeed. It would certainly have to be something pretty self-contained.
It's rare to find any 80 line stretch of code that could be incorporated without at least some significant changes.
> I wonder what the statistical liklihood of having similiar blocks of code
> of some signifigant size that happen to be the same (excluding format and
> variable differences). I mean there's only so many ways one can
> _intelligently_ code a given function
I think the odds of this code "just happening" to be the same is vanishingly
small.
How many different forms can a line of code take? A thousand maybe? (I'm
sure it's a LOT more than that - but let's go with just 10 different C code
statements that could be used at any given point in the code.)
Starting at any given line in the Linux source, the chances of the first line
of the UNIX source being the same is 1:10, the chances of the first TWO lines
being the same is 1:100, the chances of N lines of code matching is one
in ten to the power N. For 80 lines to match, that's a one in
10^80 AGAINST chance (a VERY large number). If there are 3 million lines
of code in Linux, then there are 3 million (or so) places where you could start
your comparison - so the final odds of finding 80 lines of matching code by
chance alone is something like 10^74 to one against.
When you also consider matching comments and variable names, the odds are
lengthened considerably.
When you consider that many 80 line sequences are not legal C, the odds shorten
some.
This isn't by any means a rigorous scientific measure of the improbability
of an exact match coming up by chance - but the 'back-of-envelope' math makes
it evident that the odds are overwhelming.
So: By any reasonable measure of doubt, even a dozen lines of identical code would be as close to a certainty that one was copied from the other as you could possibly imagine.
If there are indeed 80 contiguous lines of near identical code with identical comments - then I think we have to accept that the UNIX and Linux code came from the same place. That's too much to have come about by chance or parallel evolution. However, that doesn't make it an open-and-shut case for SCO:
1) Did the code indeed come from UNIX to Linux and not from some other common source such as BSD - or from Linux to UNIX. Given the lack of version control in early versions of UNIX, it's going to be hard to show *where* it came from.
2) Where is this code? If it's in the heart of the kernel then that's one thing - but if it's in some obscure utility or in a device driver, then it's quite possible that hardly anyone is using this code anyway.
3) You can bet that within an hour of SCO revealing the location of this code, there will be a replacement for it out there. So they'd only be able to claim royalties for past use...not off into the future.
4) Novell claim to own the copyrights and patents to UNIX. If that's true - then who cares about SCO's claims? Now, if Novell were to sue - that would be a completely different matter.
5) It's hard to see how SCO could claim to have been materially damaged by this. It's pretty darned obvious that if the Linux community had not had access to those 80 lines, we'd have written them ourselves...it's not like "Oh no, we don't know how to write that function - so we'll have to steal it from UNIX."
Linux's and SCO's sales would not have been different in the slightest whether that code was copied or written from scratch.
We *NEED* more facts. What file and what range of line numbers are we talking about here? Why are SCO keeping that so secret?
Yeah - well, there are always a couple of idiots in any group of people!
The Geocaching.com web site specifically lists places like this as locations where geocaches are NOT allowed and will de-list caches that are reported to them as being in unsuitable locations.
If this ever became a serious problem, the security chiefs of these places could easily hop over to www.geocaching.com, type in their own lat/long and get a handy list of any caches placed close to their facility.
As it is, it was probably a useful exercise for their state of readiness.
That's silly!
1) There is a COMPLETE database of all these so-called "false-positives" on
the www.geocaching.com web site!
2) Most Geocaches contain a standard spiel in a plastic baggie explaining that
this is a geocache and that you can go to the web site to find out all about
it.
If this causes our spies problems...well...words fail me!
Look at the geocaching site and count the number of visitors per year to each site - tha answer is about a couple of dozen. New sites tend to attract a flurry of interest - which fades to very low levels after a month or so.
Geocaching is a hobby that scales naturally. Most cache SEARCHERS also plant NEW caches. If the number of players doubles, so will the number of caches. So the number of visitors per cache will stay approximately constant. (In fact, it will gradually drop over time as each cacher plants more caches at time goes on - but typically visits fewer and fewer as they seek harder caches - and caches with complicated clues and pre-conditions.)
So - I don't see how we'll ever get to a situation where there are clearly beaten trails to every Geocache.
That's CERTAINLY not the case right now and I have the torn T-shirts and bramble wounds on my legs to prove it!
"Large numbers of people traipsing to the same point causes erosion"
Have you *looked* at the www.geocache.com site? Most caches are visted a couple of dozen times a year. I can't think of any location that's *that* fragile.
Note that geocaches are typically placed in locations where there are NOT a lot of 'muggles' (non-geocachers) around. It looks very odd to be hiding/finding a tupperware container (or, worse still, an ultra-suspicious ammo box) where a lot of people go.
Most parks in our area have either zero or one geocaches in them and probably about 10,000 pieces of actual trash. Put another way, within 100 miles of my home, there are 400 GeoCaches. How many items of trash are there within 100 miles?
So, if I remove ten pieces of trash, then add one geocache, the park is winning overall.
Even if you consider a geocache to be 'trash', it's an utterly negligable increment on the load of trash in most of the parks I've visited.
Then there is the 'cache in - trash out' initiative where geocachers go a-hunting with a large black bin bag and remove LARGE quantities of trash along with visiting the geocache.
Geocaching is at worst benign and at best a glorious way to find great new places to go. It's an ideal use of public land.
It's a really bad modeller though. Pretty useless for anything I would want to build.
Blenders interface *is* a problem, but it's been shown time and time again that *SOME* people take to it like a duck to water - and others never get to grips with it no matter how hard they try.
If you happen to be one of the lucky people for whom blender 'clicks' you'll be unable to understand why on earth anyone else would be unable to understand it.
If you are one of the people who simply cannot cope with the interface (which pretty much everyone admits is 'unusual') then no amount of trying will enable you to become proficient in it.
That's a terrible, terrible shame - but I'm afraid its a fact of life.
Of course if you look at the 'blender community' you'll find that everyone is in the first group and people like pcbob will tell you that people in the second group just aren't trying hard enough.
I'm one of the second group - I've done the tutorials, I've read the book and I simply cannot become proficient in blender. OTOH, there is no other 3D modeller that I've tried that have given me significant learning difficulties. I wish I could like blender - and I even contributed $100 to the fund to 'free' it because I think it's an important piece of software.
Not available for Linux.
I'd get AC3D - it runs on Windoze and Linux - it costs $40 per seat and it's so simple that my son learned to use it by himself at age 8.
I've used it to build simple 3D games - and whilst it has it's faults and is missing quite a few important features, it has a lot going for it.
There is of course a downloadable demo version.
I don't think we can rely on copyrights *ever* expiring. Law makers in the USA have decided that when the constitution says "limited duration" - it actually means "limited to a billion, trillion years" or something. Under pressure from all the usual MPAA/RIAA interests they are increasing the lifetime of copyright by an average of more than a year each year.
However, your point is well taken.
No - it doesn't prove that at all. He's a Texas politician - and the SSC was built in Waxahachi Texas. (I live just a few miles from the large *semi*-circular hole in the ground that is the remains of that project. Do you still wanna bet that he had no vested interests in the project?
> If you die, in service, your family might get enough for a funeral.
> If you happen to be in an office building that is the target of a high
> profile attack (Sept 11) your family will get millions.
If you die in service - you were a volunteer who knew (or should have known) that this could happen. You get paid good money for taking that risk. Your family know that this could happen - and you impose that risk on them when you choose to sign up.
If you work in a supposedly safe office job - or working in a restaurant or cleaning an office building, you do not expect to die that way. Your family has a reasonable expectation that this kind of thing won't happen.
And (struggling to get back on-topic) if you are an astronaut - you and your family should certainly be aware that there's a one in fifty-ish chance of you not surviving a mission.
There is a difference - I don't know if it's enough of a difference to explain this disparity - but you can't utterly discount it.
Fixing these craft to improve those odds of survival is an unending thing. It's like debugging a ten million line software application - you'll never get the last bug. Fixing THIS problem may well be a complete waste of time since it'll probably never happen this way again. Sure, other shuttles will crash if we continue to fly them - but I'd be very suprised if the exact same problem happened again. Hence, it's irrelevent whether you fix this problem or not - even designing an entire new manned space system may not dramatically improve people's odds of surviving a round trip to space.
But so long as the astronauts like those odds, there is no really good reason not to continue to fly the existing shuttle fleet. A 98% chance of survival is OK for quite a lot of people to get a once-in-a-lifetime chance to get into space. If any of them believed the shuttle fleet was anything like 100% safe, that thought must have been dispelled by the first shuttle accident.
A 2% chance of dying is not a good risk for (say) driving to work every day - but for a chance at doing something utterly amazing which you'll only get to do once or twice in an entire career - I don't think you'd find trouble getting volunteers.
Driving your car to work every day for a year gives you a one in 124 chance of dying or being seriously disabled. Driving to work every day of your life is MUCH more risky than taking a round trip to the ISS in a shuttle.
The actual capital cost of the shuttle fleet is significant - but if your only other plan is to ground them permenantly, you might as well fly them to destruction instead - either way, the cost of losing them (in purely monetary terms) is the same.
I'd bet good money that those astronauts who were sitting up in the ISS last week would have preferred to risk coming home in an un-fixed shuttle than coming home in that ratty old russian ship (which incidentally came close to killing them all as it was).
The trouble here seems to be that the law only says that if you have copied a copyrighted work under the special conditions of fair use, you won't be sued.
However, it doesn't guarantee that you physically *can* copy the copyrighted work in the first place.
That's the heart of the problem.
If DRM/DMCA prevents you from making the copy in the first place, the fair use provisions are simply inapplicable - you didn't make a copy - so you didn't violate the copyright law either with or without the fair use provision.
I completely agree that there SHOULD be a law that guarantees you the right to copy a work under certain circumstances - thereby making it illegal to prevent people from using the work in otherwise legal ways.
We need a law like that if only to allow things like search engines and library indexes to work - to allow quotation of one work within another - to allow criticism - for all manner of other reasons.
If we don't make that law then in a few centuries from now, historians are going to discover that in the period of mankinds most prolific production of music, art, literature and software, there is a great gaping black hole where NOTHING of our culture will be accessible. Games, music, movies and ebooks will be heavily encrypted and will only replay on machines with DRM hardware that stopped working centuries ago.
We'll have better understanding of the ancient Greeks than of 3rd millenium Americans because more of their achievements will be accessible still.
Sure Linux/UNIX software has exploits - but that's not what we were talking
about. The question was about filtering email viruses. Whilst Sentmail isn't remotely secure, it can't be taken out by something as simple as sending a particular email to it.
I'd never claim that Linux is 100% secure - but I *do* claim that it's immune to email viruses...which is what the virus protection software that ships for Lindows claims to protect you against.
So, you are right - but you are answering the wrong question.
I have seen one guy erase his DOS hard drive this way.
He was a non-technical guy who was trying to install some kind of word processor and ran out of disk space. He phoned up one of us software geeks to ask for help and someone *jokingly* told him that he could always DELETE *.* to make some space! (with whatever recursive flags DOS has - I forget).
Of course about 10 minutes later we had another plaintive phone call "I tried what you said - but now my PC won't boot".
Ack!
The car analogy can be employed here - but it has to be employed carefully.
In a car, there is a big difference between the tools you use when 'administering' it (things like wrenches and screwdrivers) and the tools you use to drive it (the steering wheel, brakes, accellerator and gear lever). Hence, it's not likely that you'll accidentally remove the wheel bolts while you are simply driving the car around town.
You *can* do your own 'administration' by picking up a wrench, opening the hood and fiddling with the mechanical bits. But if you don't know what you are doing, you can hand it over to a professional car-admin person. Opening the hood is approximately equivelent to entering 'root' mode in Linux. If you own the car, you *can* do it - but it's not something you can do by accident - and it's something that most people won't do unless they are 'car-geeks'.
So it should be with Linux - only more so. The 'normal' tools you use while driving your computer (mv, cp, rm, etc) are the exact same tools you use to swap out the engine, bleed the brakes and drain the transmission fluid. That makes it all the more important that 'mechanic' mode and 'driver' mode are clearly separated.
What Lindows does (in effect) is to place all the critical parts of the car within easy reach of the driver's seat and has you drive using a universal tool that can be used both to turn the steering AND to undo the engine mounting bolts. Since the steering wheel and the engine mounting bolts are quite close to each other, painted the same colour and accessible using the same tools, the chances of this happening by accident are noticably higher than they would be if the engine bolts were under the hood and you had to operate a very special lever in order to open it.
EH?
/" should NOT work! If it were both safe and convenient to run in root all the time, most Linux desktop users would do so - however we don't - an overwhelming number of people will voluntarily give up a small measure of convenience in order to gain a measure of protection-from-self-induced-screwups.
The reason viruses don't exist/spread is because Linux mailers don't treat data as code. Simply reading text files and HTML (sans Java/Javascript) cannot allow a virus to spread by the *simple* mechanisms that allow them to propagate in the Windoze world.
There is also the diversity argument. Under Windoze, there is essentially only one mailer in common use. If you hack a virus to work with that, it'll spread like wildfire because every mail it sends out to replicate itself has a 99% chance of hitting another machine that'll replicate it. In the Linux world, even if all those outgoing mails reach other Linux boxen, the chances are that most of the people it reaches will be running some other mailer and the virus will stop right there. That DRASTICALLY slows down the growth rate of the virus - so even if one were possible, it would spread at a snail's pace and be easy to contain.
I don't think it has anything to do with root access.
However, I regard the idea of running Lindows in root 100% of the time as sheer lunacy. There is such a thing as protecting a user from himself. "rm -R
> if you run an LCD projector for 4000 hours, it deteriorates... of course, if you're staring at a projecter 8 hours a day, for 500 straight days, maybe you should go outside ;)
But there are plenty of applications for these things where the display is permenantly turned on - think of a store display - or an airport information system - or high end adverts. In those cases, running 24 hours a day is very likely - and having the damned thing fail after a mere 166 days would suck badly!
It would have been nice to see the lifetime of large plasma panels in the survey too.