And some of us know how to take care of our teeth without two or more visits to the dentist every year, and know how to keep up a good, fresh diet without a refrigerator.
Not to say that I actually do, but I do know how.
The world is always a mixed bag. One upside I can see to all this tech is that it allows us to have discussions about what is important with lots more people than we ever could before.
My sister totaled my favorite car in a little three-way argument with the sun and a cow. (The cow lost that argument, and the rancher was not happy. My sister was a bit shaken, but otherwise, okay.)
The insurance company covered it for replacement cost, estimated at buying a similar car used., because we had chosen that kind of coverage.
I drove that car for at least ten years after that.
And we didn't even have to put a new engine in it. I think we replaced the radiator and some of the steering chain. The same insurance company that had called the car totaled inspected our repairs and called it insurable. It did cost a bit more than the coverage they gave us to fix it, so we were just being environment-conscious (and a little bit sentimental).
How's that for a car analogy? (I kind of thought my comments on a burned-out chassis addressed this point, but you insist on a car analogy.)
But that's a red herring. Let's change our point of view a bit.
You know it's not bricked, if only you had it in your hands.
I know it's not bricked, if only I had it in my hands.
The owner knows it's not really bricked, if only he/she had it in his/her hands where it belongs.
But the thief, in whose hands it is, likely does not know how to make it usable. Neither you nor I, nor the owner, are on hand to show the thief how to get past the barrier to use.
Unless the thief's fence or good buddy knows how to get past the barrier, it's unusable to the person who has possession of it. Thus, to the person who has physical access, in the mode case, it's effectively bricked.
Statistically, the thief tosses it in the nearest bin as more liability than it's worth to try to un-"brick" it.
Perhaps we should call it statistically half-bricked, since the probability it gets tossed rather than re-installed or brute-forced or whatever is somewhere above 33% and less than 100%.
As I said. It's a joke. Something of an inside joke, I suppose, but everyone here should know the joke, should understand that we aren't recommending depending on merely using an alternate OS to thumb your nose at all the potential thieves.
It's a joke with a point.
The point being that, the reasonable steps to protect your data will also, statistically speaking, make it harder for the thief to even use the hardware. At the bare minimum, proper security measures are going to cost the thief time and trouble.
Even inserting a system re-install CD is going to cost, time-wise, somewhat close to the value of the box on the black market.
Which should (at least partially) answer the desire that the author of the article had to get a bit of revenge on the theoretical thief.
You're confusing run-time checks with compile-time checks.
Go look at the code. The code contained one of those errors where the programer gets a pointer to a structure from a function, loads a field from the structure, and then after loading the field, checks whether the pointer was valid, in this case, non-NULL.
The compiler had aggressive optimizations on, saw the field being loaded, and assumed that meant the pointer must be valid, and assumed valid meant non-NULL, and deduced that the conditional code must therefore be dead.
And, yes, while the compiler can't see for NULL pointers at compile-time, it can see what happens to a pointer between the time it's set and the time it is tested. (And make, as in this case, potentially bad assumptions. Or, rather, follow the potentially bad assumptions the compiler writers made.)
It's a bit of a joke, but it's also a bit of a comment on the tragedy of monoculture.
Some things are relative to your physical state, some things are relative to your emotional state, some things are relative to how good you are with computers.
Yeah, there are thieves who are technically savvy. There are a lot more who aren't.
Bricked, in the sense of being made unusable, may mean being fried by lightening to one person, and, to another person, it may mean presenting a login screen. And there's a whole range of thresholds for a whole range of people in between.
Shoot. Some people have the time and money to fix a computer that has been burned by lightening. Depending on whether the pulse came through the power or the network cabling, or through the air, it may not even be that expensive or that time consuming. Some people even get a sense of satisfaction out of taking a burned out chassis, cleaning up the insides, sending the hard disk to a recovery service, installing new P/S, motherboard, etc., etc., and showing their friends a re-al scorchin' mo-cheen.
Some people are completely frustrated when you change the wallpaper on them, unless you hold their hand and reassure them that nothing will break while they re-establish their relationship with the machine.
So, maybe not bricked for you just by installing an OS outside the monoculture, but likely bricked for many, if not most of the petty thieves.
You can look elsewhere under this article for not a small amount of discussion of how technically savvy the people who steal notebooks generally are (or are not).
Hopefully, when you were installing the alternate OS, you took care of that "hidden" partition. You didn't skip the partitioning step, did you?
Or are you saying that current netbooks have firmware capable of hiding a disk partition from the install CD's partitioning software?
(And I'm guessing these netbooks are not running their OSses from flash drives, if there's room for an install partition.
Hmm. This sounds like it could be fun. Install a live CD to an install partition. Blast your OS and use the re-install key combo to boot into something that can repair it.)
The mode for thieves is part-time. The clueful thief graduates from the dirty work, and goes into fencing, but even fencing is part-time.
Most commercial encryption stuff is actually not that hard to break. So encrypting a drive should be less effective than using a separate device for your data, but it is probably better than nothing.
The problem with separate devices for data is that even the alternative OSses tend to leak a little in the caches.
So, you use an alternative OS, and that means you can make it harder for the guy who does the dirty work stealing your box to take a joyride.
So, yeah, there's more to it. Maybe between my jest and your partial analysis (and many other posts of varying cluefulness under this article) more people will think a bit beyond relying on Microsoft to make everything easy for them.
It was intended (and, I think, understood) to be a partially clueful joke.
The real answers, decoy OSses, decoy easy logins, tripwire scripts, external devices for actual data, (thermite or high density caps where appropriate) are touched on elsewhere, although not nearly well enough. This was just intended as a nudge in the right direction.
I think they should have added three more zeros. At a hundred million, the RIAA might come calling. Not to pay the money, but to try to bargain and bluster the price down.
The offer I'd have given is to sue them for reading the site without permission.
Use the intelligent disk controller's intelligence for something?
Sure, it would require some significant modifications to the drive, but it ought to be possible. And, I guess, triggered by lack of signal rather than by signal.
As in, requires the receiver to "fix" the machine to use it. (In this case, an OS re-install is the way it would be fixed, but the average computer user doesn't really know for software or hardware.
Maybe you have intricate dependencies. They do exist. Maybe you are running thousands of Linux machines. That's great.
But it seems odd that you don't seem to realize that this particular bug is most likely not in any of the kernels running on any of those thousands of machines.
I think the compiler should have an "evil compiler flag combination" warning that would be triggered by attempts to optimize out null pointer checks when warnings against using a pointer before checking it are turned off.
Slashdot Mirror
And some of us know how to take care of our teeth without two or more visits to the dentist every year, and know how to keep up a good, fresh diet without a refrigerator.
Not to say that I actually do, but I do know how.
The world is always a mixed bag. One upside I can see to all this tech is that it allows us to have discussions about what is important with lots more people than we ever could before.
Short, simple, correct, and ambiguous.
Ambiguity does not mean incorrect, although it does kind of water down the meaning of "correct".
(Ambiguity shows up in questions like, "What is progress?", not to mention all the other assumptions flying around here.)
... too busy getting their stuff done or drinking beer.
I see a false dichotomy here.
So, should you get off the fence before you figure out which side to come down on?
Or are you saying you are inclined against both sides?
My sister totaled my favorite car in a little three-way argument with the sun and a cow. (The cow lost that argument, and the rancher was not happy. My sister was a bit shaken, but otherwise, okay.)
The insurance company covered it for replacement cost, estimated at buying a similar car used., because we had chosen that kind of coverage.
I drove that car for at least ten years after that.
And we didn't even have to put a new engine in it. I think we replaced the radiator and some of the steering chain. The same insurance company that had called the car totaled inspected our repairs and called it insurable. It did cost a bit more than the coverage they gave us to fix it, so we were just being environment-conscious (and a little bit sentimental).
How's that for a car analogy? (I kind of thought my comments on a burned-out chassis addressed this point, but you insist on a car analogy.)
But that's a red herring. Let's change our point of view a bit.
You know it's not bricked, if only you had it in your hands.
I know it's not bricked, if only I had it in my hands.
The owner knows it's not really bricked, if only he/she had it in his/her hands where it belongs.
But the thief, in whose hands it is, likely does not know how to make it usable. Neither you nor I, nor the owner, are on hand to show the thief how to get past the barrier to use.
Unless the thief's fence or good buddy knows how to get past the barrier, it's unusable to the person who has possession of it. Thus, to the person who has physical access, in the mode case, it's effectively bricked.
Statistically, the thief tosses it in the nearest bin as more liability than it's worth to try to un-"brick" it.
Perhaps we should call it statistically half-bricked, since the probability it gets tossed rather than re-installed or brute-forced or whatever is somewhere above 33% and less than 100%.
As I said. It's a joke. Something of an inside joke, I suppose, but everyone here should know the joke, should understand that we aren't recommending depending on merely using an alternate OS to thumb your nose at all the potential thieves.
It's a joke with a point.
The point being that, the reasonable steps to protect your data will also, statistically speaking, make it harder for the thief to even use the hardware. At the bare minimum, proper security measures are going to cost the thief time and trouble.
Even inserting a system re-install CD is going to cost, time-wise, somewhat close to the value of the box on the black market.
Which should (at least partially) answer the desire that the author of the article had to get a bit of revenge on the theoretical thief.
Okay? Can we quit talking around each other?
You're confusing run-time checks with compile-time checks.
Go look at the code. The code contained one of those errors where the programer gets a pointer to a structure from a function, loads a field from the structure, and then after loading the field, checks whether the pointer was valid, in this case, non-NULL.
The compiler had aggressive optimizations on, saw the field being loaded, and assumed that meant the pointer must be valid, and assumed valid meant non-NULL, and deduced that the conditional code must therefore be dead.
And, yes, while the compiler can't see for NULL pointers at compile-time, it can see what happens to a pointer between the time it's set and the time it is tested. (And make, as in this case, potentially bad assumptions. Or, rather, follow the potentially bad assumptions the compiler writers made.)
It's a bit of a joke, but it's also a bit of a comment on the tragedy of monoculture.
Some things are relative to your physical state, some things are relative to your emotional state, some things are relative to how good you are with computers.
Yeah, there are thieves who are technically savvy. There are a lot more who aren't.
Bricked, in the sense of being made unusable, may mean being fried by lightening to one person, and, to another person, it may mean presenting a login screen. And there's a whole range of thresholds for a whole range of people in between.
Shoot. Some people have the time and money to fix a computer that has been burned by lightening. Depending on whether the pulse came through the power or the network cabling, or through the air, it may not even be that expensive or that time consuming. Some people even get a sense of satisfaction out of taking a burned out chassis, cleaning up the insides, sending the hard disk to a recovery service, installing new P/S, motherboard, etc., etc., and showing their friends a re-al scorchin' mo-cheen.
Some people are completely frustrated when you change the wallpaper on them, unless you hold their hand and reassure them that nothing will break while they re-establish their relationship with the machine.
So, maybe not bricked for you just by installing an OS outside the monoculture, but likely bricked for many, if not most of the petty thieves.
You can look elsewhere under this article for not a small amount of discussion of how technically savvy the people who steal notebooks generally are (or are not).
Hopefully, when you were installing the alternate OS, you took care of that "hidden" partition. You didn't skip the partitioning step, did you?
Or are you saying that current netbooks have firmware capable of hiding a disk partition from the install CD's partitioning software?
(And I'm guessing these netbooks are not running their OSses from flash drives, if there's room for an install partition.
Hmm. This sounds like it could be fun. Install a live CD to an install partition. Blast your OS and use the re-install key combo to boot into something that can repair it.)
The mode for thieves is part-time. The clueful thief graduates from the dirty work, and goes into fencing, but even fencing is part-time.
Most commercial encryption stuff is actually not that hard to break. So encrypting a drive should be less effective than using a separate device for your data, but it is probably better than nothing.
The problem with separate devices for data is that even the alternative OSses tend to leak a little in the caches.
So, you use an alternative OS, and that means you can make it harder for the guy who does the dirty work stealing your box to take a joyride.
So, yeah, there's more to it. Maybe between my jest and your partial analysis (and many other posts of varying cluefulness under this article) more people will think a bit beyond relying on Microsoft to make everything easy for them.
Bricked can mean many things.
It was intended (and, I think, understood) to be a partially clueful joke.
The real answers, decoy OSses, decoy easy logins, tripwire scripts, external devices for actual data, (thermite or high density caps where appropriate) are touched on elsewhere, although not nearly well enough. This was just intended as a nudge in the right direction.
Well, you're right. May of the thieves these days, or the guys who receive the stolen goods, are somewhat clueful.
The real solution is to keep your sensitive data on your person, in something you can keep in a waste pouch under your shirt where it isn't obvious.
A cheap USB drive, encrypted, does that job, sort of. Not really well enough, but it's the best we have. I think we all realize that.
For the rest of it, putting a decoy or two on the netbook will help keep the thieves busy while we (or our scripts) recover and/or make our escape.
I think they should have added three more zeros. At a hundred million, the RIAA might come calling. Not to pay the money, but to try to bargain and bluster the price down.
The offer I'd have given is to sue them for reading the site without permission.
So, what you're saying is, "His business plan sucks and mine doesn't."?
Just kidding. Sort of. Loosen up. Competition makes the market larger for now.
This is probably the best solution for anyone not carrying trade secrets.
Use the intelligent disk controller's intelligence for something?
Sure, it would require some significant modifications to the drive, but it ought to be possible. And, I guess, triggered by lack of signal rather than by signal.
As in, requires the receiver to "fix" the machine to use it. (In this case, an OS re-install is the way it would be fixed, but the average computer user doesn't really know for software or hardware.
A number of people have suggested that the data is not important.
But what about cached credit card numbers or passwords?
To the average thief, and to the average receiver of a stolen netbook, if the netbook boots an alternative OS, it might as well be bricked.
All the more reason to use a Linux or BSD based OS.
To the average thief or receiver of stolen goods, a netbook running an alternate OS is as good as bricked.
Maybe you have intricate dependencies. They do exist. Maybe you are running thousands of Linux machines. That's great.
But it seems odd that you don't seem to realize that this particular bug is most likely not in any of the kernels running on any of those thousands of machines.
In the real world, you are not using this kernel.
I think the compiler should have an "evil compiler flag combination" warning that would be triggered by attempts to optimize out null pointer checks when warnings against using a pointer before checking it are turned off.
In the source, tun was set by a function call before the lines quoted.
I'd say that's a bug in the the friendly article, myself.
undefined behavior is often not obvious?
I'm pretty sure the guy who found it was not just throwing NULL pointers at all the APIs. (He used the source to find it.)