I see your point about aerial recon, but can we *really* aim at something 250 miles away? With what accuracy? These things are dumb bullets, not smart bombs. Less moving parts to break or be debugged is awesome, but seriously, *250* miles away? We're not talking about a straight shot either, which I can believe is within the realm of possibility.. they have to be arced up and down into the target because of the earth's curvature. What about wind resistance slowing it down or worse, deflecting it? Sure it's a huge amount of kinetic energy, but that's a huge amount of air to pass through.
Oh, Lassie will rescue him. Any dog would. Their top-secret training prevents them from acting in such a way as to reveal the master dog agenda.
I hope you never hit your dog, because if you have, you'll be first up against the wall when the Space Canines land, their space-suited heads hanging out the spaceship windows...
3) Data on where bugs are found and how they are found increases the knowledge base of those developing more secure programming techniques, such as preventing overflows (in the manner that e.g. Python and Java do), providing abstractions to do IPC/RPC that prevent exploitation by one of the endpoints, encrypting wire communications, etc.
Over time, these techniques will become more and more widespread and easier to use such that more software will use them. This is a much slower trend than the one the paper analyzes; it will take decades, but its effects will be permanent.
There's no reason this has to be more complex than HTTP.
The pen doesn't have to be mass storage. Just put a radio/IR receiver on it. When it touches an object on the screen, the PDA it touches transmits a message to the pen: a URL for the object touched (e.g. <http://xantspda/hugefile.pdf>). Simultaneously it places the object, hugefile.pdf, on a web server (we'll assume the server is public and therefore anyone can pick it up, but point-to-point security for this is actually not hard at all to implement; I just want to ignore it for now).
The point is, the pen only knows what URL it picked up, and the PDA with the object to be transferred is solely responsible for serving the object over the network.
When the pen contacts another PDA screen with the same software and transceiver as the first one, the pen sends the URL down to the screen, and that PDA initiates a transfer of the URL.
There's a point I think a lot of people are missing. Despite having failed to keep the aforementioned feces in the aforementioned equine on the matter of computer-spread malware, society has failed to collapse because of same malware. In part this is because the damage malware can do is finite, and in part because we developed defense against all these things.
We deal with problems as they arise. It's almost impossible to do otherwise. Thinking about them and postulating that they could exist is about the best we could do. Making laws about them is almost certainly the worst thing we can do.
These results don't trouble me, provided...
on
Testing ISP Censorship
·
· Score: 2, Interesting
provided a followup step occurred, and certain events then took place.
The follow-up step: 1) Contact the ISP(s) that took down the material. 2) Inform them that the material they took down was public domain, or you really own the material or whatever 3) Request that they restore it, and (optional) request a refund for the period of time it was down
The events that should occur: The ISP in question should obey all your instructions, and refuse to take down the material again until they hear from a legal authority.
They have a duty to protect themselves; I just want to see that they are concerned about protecting themselves from both lawsuits on *both* sides.
One of the strongest stabilizing forces on both technology and culture is the lifespan of the human being. As long as people are physically alive to remember and teach their children about a particular cultural facet, that facet will remain strong. The strength of that facet can get either stronger or weaker over time, depending on how many other trusted human beings are around practicing it and teaching it. (This gets heavily into memetics, but I'm going to avoid that topic.)
In the same vein, technology is taught by other trusted human beings. If a lot of trusted people say to use C++ or Java, then lots of people will choose to learn C++ or Java. (I'm convinced this is the only reason these languages still exist.;-) People will always be innovating, but it'll take a lot longer for new technologies and techniques to gain acceptance when almost every technologist will be satisfied with the technologies they're already using. College kids entering the workforce are a great source, not of new ideas (necessarily), but of blank slates--people who can be talked into trying new things and seeing if they work, because they haven't made up their minds yet.
If the average human lifespan becomes much longer, it may not matter that it takes longer for technology to be accepted and become mainstream, but we will see a distinct change in how we plot the rate change of history.
Other cars will be driving with different relative speeds around you. Controller car changes lanes left. At the correct time, your car also changes lanes left. However, asshole speeder behind you has already filled the gap. And now you're dead.
To see what's more precious. When something drops nuclear waste in your vicinity, if your species can figure out how to give it back to the originator, you qualify as precious.
Not really. They both rely on having a common interface to a set of objects, whether they be objects in the browser environment or objects in the OS environment. There are fewer objects in the browser environment, but balancing that is the fact that tools for working in the OS environment are much more powerful. On the whole, I'd much prefer to write a cross-platform native app than a cross-platform browser app, and I've done both.
This is nonsense. Who do you think finds the problem that needs patching in the first place? Sometimes it's white-hats, but far more often it's black-hats. There are mountains of exploits out there that nobody has ever documented or patched, and we may never know about them. But a firewall is usually enough to keep them from mattering.
Not that there aren't hundreds of other ways around this useless technology, but your suggestion would just cause the bomb to blow up as soon as the terrorist carried it into the protected area, most likely having no effect on the intended target (who would be at the center of the area, not at its edges).
No, a better way would be to use a signal on a frequency that wasn't being jammed, or use a line-of-sight system with a laser, or use a good old-fashioned timer, or use a good old-fashioned suicide bomber, or a good old-fashioned sniper rifle. Or hey, they could always try diplomacy to achieve their goals.
Look at all the armor and technology necessary to protect the smartest organism in the known universe from an animal. Sure, it's a fairly smart animal, and it's certainly a big animal, and it will fucking kill you a lot if you get close to it and piss it off without wearing a bear suit, but come on. It took us thousands of years of technological progress to come up with protection equal to its ferocity.
Next: Suits to protect you from sharks with laser beams.
Less code is faster than more code! Simply put, it's easier to optimize if you can understand it, and it's easier to understand if there's not so much of it. But when you optimize code that didn't really need it, you usually add more code; more code leads to confusion and confusion leads to performance problems. THAT is the highly-counterintuitive reason premature optimization is bad: It's not because it makes your code harder to maintain, but because it makes your code slower.
In a high-level interpreted language with nice syntax--mine is Python, not Erlang, but same arguments apply--it's easier to write clean, lean code. So high-level languages lead to (c)leaner code, which is faster code. I often find that choosing the right approach, and implementing it in an elegant way, I get performance far better than I was expecting. And if what I was expecting would have been "fast enough", I'm done -- without optimizing.
It sucks that new procedures are necessary, but we've now had an EMT and a FF both testify that there are lots of ways for a totalled car to injure the rescuers. So they're already alert and aware that there may be dangers, and the first Prius to get totalled won't be a total, erm, shock to them.
This is not going to be a cheap OS review, but it's a thorough one, and if anyone did it this way maybe they'd be taken a little more seriously. ..
Linux distros have the most problems with hardware compatibility, so:
1) Install the OS on at least 4 computers: a couple of different laptop models, a desktop model, and a rackmounted server model, all configured the way they come out of the box, with maybe some weird odds and ends like cameras. They will have some components in common and some different enough to see whether the distro really supports your hardware. Bonus points if some of the systems are brand new and some are a few years old. DO WHATEVER IS NECESSARY TO MAKE ALL THE HARDWARE WORK.
2) Select at least two different filesystems between the four computers. Make sure it supports something like a journaling filesystem out of the box.
3) Select at least one each of Gnome and KDE (and maybe non-graphics) between the four computers.
4) Figure out how hard it is to install up-to-date versions of the most common services like samba, apache and postgresql/mysql (you might reasonably restrict this testing to the rackmounted computer). Then configure them. DO WHATEVER IS NECESSARY TO ENABLE THESE SERVICES TO MAKE THE COMPUTERS TALK TO EACH OTHER.
5) Then list the major applications that are installed by default and the ones that are available for download using the update tools. Describe the procedure for updating/getting new software. Run no more than one or two of the most common applications; let's face it, it's all open source so at this level anybody can get almost any piece of software to work.
Well, they're not like everyone else. For example, they're not like the large number of organizations that seek to increase censorship and decrease freedom. The ACLU chooses what causes to champion, just like everyone else, but they don't choose to champion one right while working to shut down another.
Slashdot Mirror
The next generation of "smarter" satellites will generate photos of things it imagines, using onboard photoshop, and transmit those.
I see your point about aerial recon, but can we *really* aim at something 250 miles away? With what accuracy? These things are dumb bullets, not smart bombs. Less moving parts to break or be debugged is awesome, but seriously, *250* miles away? We're not talking about a straight shot either, which I can believe is within the realm of possibility.. they have to be arced up and down into the target because of the earth's curvature. What about wind resistance slowing it down or worse, deflecting it? Sure it's a huge amount of kinetic energy, but that's a huge amount of air to pass through.
How is this done?
Oh, Lassie will rescue him. Any dog would. Their top-secret training prevents them from acting in such a way as to reveal the master dog agenda.
...
I hope you never hit your dog, because if you have, you'll be first up against the wall when the Space Canines land, their space-suited heads hanging out the spaceship windows
3) Data on where bugs are found and how they are found increases the knowledge base of those developing more secure programming techniques, such as preventing overflows (in the manner that e.g. Python and Java do), providing abstractions to do IPC/RPC that prevent exploitation by one of the endpoints, encrypting wire communications, etc.
Over time, these techniques will become more and more widespread and easier to use such that more software will use them. This is a much slower trend than the one the paper analyzes; it will take decades, but its effects will be permanent.
There's no reason this has to be more complex than HTTP.
The pen doesn't have to be mass storage. Just put a radio/IR receiver on it. When it touches an object on the screen, the PDA it touches transmits a message to the pen: a URL for the object touched (e.g. <http://xantspda/hugefile.pdf>). Simultaneously it places the object, hugefile.pdf, on a web server (we'll assume the server is public and therefore anyone can pick it up, but point-to-point security for this is actually not hard at all to implement; I just want to ignore it for now).
The point is, the pen only knows what URL it picked up, and the PDA with the object to be transferred is solely responsible for serving the object over the network.
When the pen contacts another PDA screen with the same software and transceiver as the first one, the pen sends the URL down to the screen, and that PDA initiates a transfer of the URL.
There's a point I think a lot of people are missing. Despite having failed to keep the aforementioned feces in the aforementioned equine on the matter of computer-spread malware, society has failed to collapse because of same malware. In part this is because the damage malware can do is finite, and in part because we developed defense against all these things.
We deal with problems as they arise. It's almost impossible to do otherwise. Thinking about them and postulating that they could exist is about the best we could do. Making laws about them is almost certainly the worst thing we can do.
provided a followup step occurred, and certain events then took place.
The follow-up step:
1) Contact the ISP(s) that took down the material.
2) Inform them that the material they took down was public domain, or you really own the material or whatever
3) Request that they restore it, and (optional) request a refund for the period of time it was down
The events that should occur:
The ISP in question should obey all your instructions, and refuse to take down the material again until they hear from a legal authority.
They have a duty to protect themselves; I just want to see that they are concerned about protecting themselves from both lawsuits on *both* sides.
He's talking about the personalities that make up the two hills on either side of her uncanny valley.
One of the strongest stabilizing forces on both technology and culture is the lifespan of the human being. As long as people are physically alive to remember and teach their children about a particular cultural facet, that facet will remain strong. The strength of that facet can get either stronger or weaker over time, depending on how many other trusted human beings are around practicing it and teaching it. (This gets heavily into memetics, but I'm going to avoid that topic.)
;-) People will always be innovating, but it'll take a lot longer for new technologies and techniques to gain acceptance when almost every technologist will be satisfied with the technologies they're already using. College kids entering the workforce are a great source, not of new ideas (necessarily), but of blank slates--people who can be talked into trying new things and seeing if they work, because they haven't made up their minds yet.
In the same vein, technology is taught by other trusted human beings. If a lot of trusted people say to use C++ or Java, then lots of people will choose to learn C++ or Java. (I'm convinced this is the only reason these languages still exist.
If the average human lifespan becomes much longer, it may not matter that it takes longer for technology to be accepted and become mainstream, but we will see a distinct change in how we plot the rate change of history.
Other cars will be driving with different relative speeds around you. Controller car changes lanes left. At the correct time, your car also changes lanes left. However, asshole speeder behind you has already filled the gap. And now you're dead.
To see what's more precious. When something drops nuclear waste in your vicinity, if your species can figure out how to give it back to the originator, you qualify as precious.
Not really. They both rely on having a common interface to a set of objects, whether they be objects in the browser environment or objects in the OS environment. There are fewer objects in the browser environment, but balancing that is the fact that tools for working in the OS environment are much more powerful. On the whole, I'd much prefer to write a cross-platform native app than a cross-platform browser app, and I've done both.
This is nonsense. Who do you think finds the problem that needs patching in the first place? Sometimes it's white-hats, but far more often it's black-hats. There are mountains of exploits out there that nobody has ever documented or patched, and we may never know about them. But a firewall is usually enough to keep them from mattering.
Not that there aren't hundreds of other ways around this useless technology, but your suggestion would just cause the bomb to blow up as soon as the terrorist carried it into the protected area, most likely having no effect on the intended target (who would be at the center of the area, not at its edges).
No, a better way would be to use a signal on a frequency that wasn't being jammed, or use a line-of-sight system with a laser, or use a good old-fashioned timer, or use a good old-fashioned suicide bomber, or a good old-fashioned sniper rifle. Or hey, they could always try diplomacy to achieve their goals.
It's unintentionally funny. The "English" system is also not American.
Throw them both out.. Go for the Jersey system!
Look at all the armor and technology necessary to protect the smartest organism in the known universe from an animal. Sure, it's a fairly smart animal, and it's certainly a big animal, and it will fucking kill you a lot if you get close to it and piss it off without wearing a bear suit, but come on. It took us thousands of years of technological progress to come up with protection equal to its ferocity.
Next: Suits to protect you from sharks with laser beams.
Less code is faster than more code! Simply put, it's easier to optimize if you can understand it, and it's easier to understand if there's not so much of it. But when you optimize code that didn't really need it, you usually add more code; more code leads to confusion and confusion leads to performance problems. THAT is the highly-counterintuitive reason premature optimization is bad: It's not because it makes your code harder to maintain, but because it makes your code slower.
In a high-level interpreted language with nice syntax--mine is Python, not Erlang, but same arguments apply--it's easier to write clean, lean code. So high-level languages lead to (c)leaner code, which is faster code. I often find that choosing the right approach, and implementing it in an elegant way, I get performance far better than I was expecting. And if what I was expecting would have been "fast enough", I'm done -- without optimizing.
Microsoft will spend tomorrow vehemently denying a report that says "Microsoft does not kill kittens."
Friday will be dedicated to denying vehemently the report that says "Microsoft has cancelled its nuclear arms development program."
It sucks that new procedures are necessary, but we've now had an EMT and a FF both testify that there are lots of ways for a totalled car to injure the rescuers. So they're already alert and aware that there may be dangers, and the first Prius to get totalled won't be a total, erm, shock to them.
This is not going to be a cheap OS review, but it's a thorough one, and if anyone did it this way maybe they'd be taken a little more seriously. . .
Linux distros have the most problems with hardware compatibility, so:
1) Install the OS on at least 4 computers: a couple of different laptop models, a desktop model, and a rackmounted server model, all configured the way they come out of the box, with maybe some weird odds and ends like cameras. They will have some components in common and some different enough to see whether the distro really supports your hardware. Bonus points if some of the systems are brand new and some are a few years old. DO WHATEVER IS NECESSARY TO MAKE ALL THE HARDWARE WORK.
2) Select at least two different filesystems between the four computers. Make sure it supports something like a journaling filesystem out of the box.
3) Select at least one each of Gnome and KDE (and maybe non-graphics) between the four computers.
4) Figure out how hard it is to install up-to-date versions of the most common services like samba, apache and postgresql/mysql (you might reasonably restrict this testing to the rackmounted computer). Then configure them. DO WHATEVER IS NECESSARY TO ENABLE THESE SERVICES TO MAKE THE COMPUTERS TALK TO EACH OTHER.
5) Then list the major applications that are installed by default and the ones that are available for download using the update tools. Describe the procedure for updating/getting new software. Run no more than one or two of the most common applications; let's face it, it's all open source so at this level anybody can get almost any piece of software to work.
Only in the sense that programs written in one or the other never get maintained.
Well, they're not like everyone else. For example, they're not like the large number of organizations that seek to increase censorship and decrease freedom. The ACLU chooses what causes to champion, just like everyone else, but they don't choose to champion one right while working to shut down another.
Let the 15YMOUA begin!
You can hand out a fucking B.S. when they leave the museum, because they'd spend about 4 years in there learning how to do all that shit. :P
Museums are supposed to be fun, not hard work.
back to the stoneage.
You mean, the server will be forced to run IRC again?