No, they declare martial law and 'disappear' you, of they just beat the crap out of everyone. That's how it's been done through the ages.
On the plus side, at least 50 cameras will see them doing this, and with any luck at least some of those camera feeds will be accessible to your friends and family.
Re:many of the english ones are absolute rubbish..
on
Dumb Laws
·
· Score: 1
Anal sex is prohibited. A myth - it was decriminalised a few years ago, 1992 I think.
Amazing. You managed to contradict yourself in a one sentence post.
Any consumer that did not want windows could learn enough to piece together their own machine. No computer buyer has ever been 100% forced to buy a microsoft product. Prove me wrong.
No, you're right. But most people do not have the time, the expertise, or the self-confidence to put together their own hardware. Furthermore, most people who buy PCs are more or less required to buy Windows, because if they don't, they won't be able read their co-worker's MS-Word attachments, etc. So in the eyes of Joe Consumer, there really is no choice.
There are many _professional_ studio devices that are supported by BeOS, but not by Linux/Windows.
Sorry, what? I'm as big a BeOS fan as you'll ever see, but I don't think there is a single piece of hardware anywhere that is supported by BeOS but Linux/Windows. BeOS simply doesn't have enough marketshare to justify Be-specific hardware.
if every developer thinks "we'll write it in java for the alt os's", then the awesome speed and ass kicking gui of the beos will meaningless.
Then they need a better VM! Sheesh!
Or a Java to native-code compiler. After all, there's nothing that says you HAVE to compile it to "virtual machine bytecodes".
Actually, what I'd really like to see (and I'll bet someone has already implemented this, feel free to inform me if you know) is a JIT that saves the native code it compiles back to disk, in some sort of a persistent cache. That way, the second time you run your Java program, it loads the JIT-generated.exe files, instead of the.class files, and you literally are running a native program.
>Stick a break point in a callback and check out >the call stack - 20 deep, WTF were they >thinking. I have to protest this assumption of deep call stack -> bad implementation. By that logic, any code that uses recursive function calls is "bad", which is obviously untrue--recursion is an excellent way to define complex behavior via simple code.
They can and do make color images from black and white ones. We got color pictures from Mars by compositing red, green and blue filters over a black and white imager. It just takes more effort.
I just had a sudden flashback to my old Amiga 1000's DigiView setup, with its cardboard color filter wheel. Those were the days!:^)
[world hunger is] that nanotech isn't going to solve.
If you'll forgive me for a bit of pie-in-the-sky optimism, I'll describe a device that would solve world hunger.
This device is a Box. You can pour some easily available raw materials (dirt, water, and sunlight? Air? Whatever is needed) into the top, and press the green button, the nanobots inside do some quick molecular reassembly, and a ham sandwich pops out the other side. Or, you can press the shiny red button, and another Box pops out the other side.
Give one of these to one human being, and within a month world hunger would be solved, because everyone who wanted one would have one. Kind of like software piracy, really...
The thing about it is that learning Dvorak and keeping your QWERTY skills must be weird. After a while, you would probably make lots of mistakes when you went back to a QWERTY, which you will find almost everywhere.
Now that you mention it, that's absolutely true. For a few weeks at the end of my Dvorak learning curve, there was a period where I couldn't type well in either Dvorak *or* Qwerty (this after having been doing 80WPM on Qwerty for years). I kept switching back and forth between keymaps in the middle of sentences (usually after an 'a' or an 'm' character, which are the same in both keymaps). After a while though, my brain managed to get both mappings sorted properly again. What's striking is that this is *exactly* how a neural net behaves when you give it a new data set... more evidence as to how my brain is implemented, I think...
Just as a lark, a year or two ago, I taught myself Dvorak. After a few months, I was as comfortable with Dvorak as with Qwerty (as others have mentioned, the only really tough part is re-learning the control keystrokes for vi, menu item selection, etc). Now I use the Dvorak keymap under Windows NT at work, and the Qwerty keymap under BeOS at home. I type about the same speed in both keymaps, but there are other advantages to knowing Dvorak:
- It keeps your co-workers from messing with your computer. "Hey, your keyboard's broken! It's typing gibberish!"
- It makes it really easy to choose hard-to-crack passwords. Just choose a relatively "easy" password, but type it in using the "wrong" keymap.
- Impresses the girls at parties. (oh, okay, I lied on that one)
One other thing I noticed is that there is some kind of low-level link in my mind between the desktop I see on the screen, and what my fingers will type. Previously had two NT systems, one using Qwerty and one with Dvorak, and I was forever using the wrong keymap and ending up with random characters. But now that I've segregated my keymaps to coincide with the OS (NT=Dvorak, BeOS=Qwerty), there's no problem. Hmmm...
Show me some major bugs in NT that stops software development
I won't do that (there probably are some, but I can't think of any real show-stoppers at the moment). I will point out, though, that Windows presents the developer with hundreds of relatively complicated and difficult-to-use APIs. Such a byzantine environment leads to bugs that would not have occurred in a simpler system.
Windows tries to be everything to everyone, and also keep backwards compatibility with all software and hardware, all the way back to 1985. Complexity increases past the capacity of even the most intelligent programmers, and surprise surprise, out come the bugs.
Has anyone developed an encryption scheme where you can decrypt your file with either of several keys, and each key will decrypt the file to a different plaintext file?
Then, when the police come knocking, demanding that you turn over the key, you can give them the decoy key, which will decrypt the file to something innocuous. (a letter to your Mom, maybe)
Then the police move on, thinking there is nothing there, and stop harrassing you, and your "real" message is forever safe. Problem solved?
Don't be alarmed - Jesus warned that the world would hate us and Paul told us to consider it pure joy when we are persecuted for our faith. Satan has a lot of people here by the you-know-what...
I doubt the world will hate you. Although some of us won't be able to help a little eye rolling at all this self-aggrandizing martyrdom...
those were exactly who we would go for when we were trying to get intel -- wave a little pussy at them and they would happily tell you anything, everything, and thank you too.
Can you really blame them? It's tough to get laid when you have to wear those damn bunny suits...
I always imagine writing a good program to be similar to writing a good novel. Most writers will rewrite a given paragraph or chapter tens or hundreds of times until it's just perfect. Programs are no different--whenever you write a function or module, consider it a draft, and don't worry about throwing it away and writing it again. Too often I see people spending hours and hours trying to get acceptable behaviour out of their fundamentally flawed "first draft", when it would have been much simpler and easier to just toss the code and rewrite it, now that the problem is better understood. That way, when you're done, you have an elegant, easy-to-understand, simple program, instead of an inscrutable mess that "seems to work okay" (as far as your testing shows, anyway!)
I'm just thinking...a device like this would make the getaway from a bank robbery very easy. [...] Either the police would have to have to keep pace with the average purchasing for these things or thre would have to be some way to track them (portable radar?) so police wouldn't need helicopters for each chase.
suddenly these things are everywhere, there's air jams, milage goes down, popularity wears off
I don't buy this prediction that once everybody has an air car, there will suddenly be "air jams". Remember that there is much much more space in the air (a 3D volume) than there is on the ground (a 2D surface, and you only get to use the paved parts of it). Sure, in the short run there will probably be heavy traffic around airports or other "approved flying areas", but once every car is fitted with its own GPS auto-nav system and can land and take off from anywhere, I don't think there will be any problems at all. Too much traffic at 2500 feet? Okay, fly at 2550!
This argument is flawed. If in 18 months one can create reasonable competition and bring down a monopoly, it probably never was one!
I disagree. Remember that 18 months is a long time in the computer industry. Here's a silly example: right now Microsoft has a legal monopoly on sales of Microsoft Office. If (by some incredible leap of legal logic) the government decided to rescind that monopoly, do you really think it would be more than 18 months before other companies started selling their own Office CDs? More like 24 hours if you ask me...
The Real Magic is in the software - the CAVE Library automagically manages all the walls and headtracking for you. When you write a CAVE program, basically you just give the library a callback that draws the world, and the library will call it each time it needs to draw a wall, setting up the correct projection magic so it's drawn properly to your head position. It's really pretty slick.
I've been playing with the idea of designing my own CAVE type setup using a group of 4 to 6 cheap networked PC's, each with a 3D card and an LCD projector. It doesn't seem like it would be that difficult to do; has anyone tried this? If not, are there any "gotchas" that would keep it from working? The only ones I can think of are possible network delay desynchronizing the walls, or perhaps the view-positioning math is harder than I think it is...
Java may be slow (although this will become less of a problem as computer speeds increase) but I don't agree that it is unstable. On the contrary, Java's lack of pointers, run-time type checking, and garbage collector make Java programs much less likely to crash than C/C++ programs.
Of course, this assumes you are running your Java programs as programs, and not as applets in Netscape or IE...
BeOS is already pervasively multithreaded, unlike almost any other OS out there. Its nature makes debugging your apps a pain in the ass, but allows a 95% increase in processing power if you add a second CPU. Or so I've been told.
Multithreaded code isn't so hard to debug as long as you design your program very carefully in advance with multithreading in mind. It's when you take a program or API that was designed to be single-threaded and try to hack in the multithreading after the fact that things can get awful.
Slashdot Mirror
Wait until Microsoft tries to port WindowsCE to your microwave. Then you'll really see the paperclip in action!
LOL! "I see you are trying to reheat a slice of pizza. Would you like me to assist you with that?"
"Share and enjoy!"
No, they declare martial law and 'disappear' you, of they just beat the crap out of everyone. That's how it's been done through the ages.
On the plus side, at least 50 cameras will see them doing this, and with any luck at least some of those camera feeds will be accessible to your friends and family.
Anal sex is prohibited.
A myth - it was decriminalised a few years ago, 1992 I think.
Amazing. You managed to contradict yourself in a one sentence post.
Any consumer that did not want windows could learn enough to piece together their own machine. No computer buyer has ever been 100% forced to buy a microsoft product. Prove me wrong.
No, you're right. But most people do not have the time, the expertise, or the self-confidence to put together their own hardware. Furthermore, most people who buy PCs are more or less required to buy Windows, because if they don't, they won't be able read their co-worker's MS-Word attachments, etc. So in the eyes of Joe Consumer, there really is no choice.
There are many _professional_ studio devices that are supported by BeOS, but not by Linux/Windows.
Sorry, what? I'm as big a BeOS fan as you'll ever see, but I don't think there is a single piece of hardware anywhere that is supported by BeOS but Linux/Windows. BeOS simply doesn't have enough marketshare to justify Be-specific hardware.
if every developer thinks "we'll write it in java for the alt os's", then the awesome speed and ass kicking gui of the beos will meaningless.
.exe files, instead of the .class files, and you literally are running a native program.
Then they need a better VM! Sheesh!
Or a Java to native-code compiler. After all, there's nothing that says you HAVE to compile it to "virtual machine bytecodes".
Actually, what I'd really like to see (and I'll bet someone has already implemented this, feel free to inform me if you know) is a JIT that saves the native code it compiles back to disk, in some sort of a persistent cache. That way, the second time you run your Java program, it loads the JIT-generated
>Stick a break point in a callback and check out >the call stack - 20 deep, WTF were they >thinking. I have to protest this assumption of deep call stack -> bad implementation. By that logic, any code that uses recursive function calls is "bad", which is obviously untrue--recursion is an excellent way to define complex behavior via simple code.
They can and do make color images from black and white ones. We got color pictures from Mars by
:^)
compositing red, green and blue filters over a black and white imager. It just takes more effort.
I just had a sudden flashback to my old Amiga 1000's DigiView setup, with its cardboard color filter wheel. Those were the days!
[world hunger is] that nanotech isn't going to solve.
If you'll forgive me for a bit of pie-in-the-sky optimism, I'll describe a device that would solve world hunger.
This device is a Box. You can pour some easily available raw materials (dirt, water, and sunlight? Air? Whatever is needed) into the top, and press the green button, the nanobots inside do some quick molecular reassembly, and a ham sandwich pops out the other side. Or, you can press the shiny red button, and another Box pops out the other side.
Give one of these to one human being, and within a month world hunger would be solved, because everyone who wanted one would have one. Kind of like software piracy, really...
...and then you need one of these watch devices each tuned to a different frequency controlling each nanorobot..
Not necessarily. Think SIMD...
The thing about it is that learning Dvorak and keeping your QWERTY skills must be weird. After a while, you would probably make lots of mistakes
when you went back to a QWERTY, which you will find almost everywhere.
Now that you mention it, that's absolutely true. For a few weeks at the end of my Dvorak learning curve, there was a period where I couldn't type well in either Dvorak *or* Qwerty (this after having been doing 80WPM on Qwerty for years). I kept switching back and forth between keymaps in the middle of sentences (usually after an 'a' or an 'm' character, which are the same in both keymaps). After a while though, my brain managed to get both mappings sorted properly again. What's striking is that this is *exactly* how a neural net behaves when you give it a new data set... more evidence as to how my brain is implemented, I think...
Just as a lark, a year or two ago, I taught myself Dvorak. After a few months, I was as comfortable with Dvorak as with Qwerty (as others have mentioned, the only really tough part is re-learning the control keystrokes for vi, menu item selection, etc). Now I use the Dvorak keymap under Windows NT at work, and the Qwerty keymap under BeOS at home. I type about the same speed in both keymaps, but there are other advantages to knowing Dvorak:
- It keeps your co-workers from messing with your computer. "Hey, your keyboard's broken! It's typing gibberish!"
- It makes it really easy to choose hard-to-crack passwords. Just choose a relatively "easy" password, but type it in using the "wrong" keymap.
- Impresses the girls at parties. (oh, okay, I lied on that one)
One other thing I noticed is that there is some kind of low-level link in my mind between the desktop I see on the screen, and what my fingers will type. Previously had two NT systems, one using Qwerty and one with Dvorak, and I was forever using the wrong keymap and ending up with random characters. But now that I've segregated my keymaps to coincide with the OS (NT=Dvorak, BeOS=Qwerty), there's no problem. Hmmm...
Show me some major bugs in NT that stops software development
I won't do that (there probably are some, but I can't think of any real show-stoppers at the moment). I will point out, though, that Windows presents the developer with hundreds of relatively complicated and difficult-to-use APIs. Such a byzantine environment leads to bugs that would not have occurred in a simpler system.
Windows tries to be everything to everyone, and also keep backwards compatibility with all software and hardware, all the way back to 1985. Complexity increases past the capacity of even the most intelligent programmers, and surprise surprise, out come the bugs.
Has anyone developed an encryption scheme where you can decrypt your file with either of several keys, and each key will decrypt the file to a different plaintext file?
Then, when the police come knocking, demanding that you turn over the key, you can give them the decoy key, which will decrypt the file to something innocuous. (a letter to your Mom, maybe)
Then the police move on, thinking there is nothing there, and stop harrassing you, and your "real" message is forever safe. Problem solved?
Don't be alarmed - Jesus warned that the world would hate us and Paul told us to consider it pure joy when we are persecuted for our faith. Satan has a lot of people here by the you-know-what...
I doubt the world will hate you. Although some of us won't be able to help a little eye rolling at all this self-aggrandizing martyrdom...
those were exactly who we would go for when we were trying to get intel -- wave a little pussy at them and they would happily tell you anything, everything, and thank you too.
Can you really blame them? It's tough to get laid when you have to wear those damn bunny suits...
I always imagine writing a good program to be similar to writing a good novel. Most writers will rewrite a given paragraph or chapter tens or hundreds of times until it's just perfect.
Programs are no different--whenever you write a function or module, consider it a draft, and don't worry about throwing it away and writing it again. Too often I see people spending hours and hours trying to get acceptable behaviour out of their fundamentally flawed "first draft", when it would have been much simpler and easier to just toss the code and rewrite it, now that the problem is better understood. That way, when you're done, you have an elegant, easy-to-understand, simple program, instead of an inscrutable mess that "seems to work okay" (as far as your testing shows, anyway!)
I'm just thinking...a device like this would make the getaway from a bank robbery very easy. [...] Either the police would have to have to keep pace with the average purchasing for these things or thre would have to be some way to track them (portable radar?) so police wouldn't need helicopters for each chase.
Three letters: S.A.M.
suddenly these things are everywhere, there's air jams, milage goes down, popularity wears off
I don't buy this prediction that once everybody has an air car, there will suddenly be "air jams". Remember that there is much much more space in the air (a 3D volume) than there is on the ground (a 2D surface, and you only get to use the paved parts of it). Sure, in the short run there will probably be heavy traffic around airports or other "approved flying areas", but once every car is fitted with its own GPS auto-nav system and can land and take off from anywhere, I don't think there will be any problems at all. Too much traffic at 2500 feet? Okay, fly at 2550!
This argument is flawed. If in 18 months one can create reasonable competition and bring down a
monopoly, it probably never was one!
I disagree. Remember that 18 months is a long time in the computer industry. Here's a silly example: right now Microsoft has a legal monopoly on sales of Microsoft Office. If (by some incredible leap of legal logic) the government decided to rescind that monopoly, do you really think it would be more than 18 months before other companies started selling their own Office CDs? More like 24 hours if you ask me...
The Real Magic is in the software - the CAVE Library automagically manages all the walls and headtracking for you. When you write a CAVE program, basically you just give the library a callback that draws the world, and the library will call it each time it needs to draw a wall, setting up the correct projection magic so it's drawn properly to your head position. It's really
pretty slick.
I've been playing with the idea of designing my own CAVE type setup using a group of 4 to 6 cheap networked PC's, each with a 3D card and an LCD projector. It doesn't seem like it would be that difficult to do; has anyone tried this? If not, are there any "gotchas" that would keep it from working? The only ones I can think of are possible network delay desynchronizing the walls, or perhaps the view-positioning math is harder than I think it is...
Here in the hall of heads
You look through the keyhole
This is the hall of heads
One step through the doorway
Roll out that special head
This is our favorite one
Please don't try to leave
Don't leave the hall of heads
Hide underneath the porch
Hide down behind the furnace
You can't run away
Your feet won't let you run
You can't get away
You can't really hide
Once you hear the call
The song of the hall of heads
You can't run away
Your feet won't help you run
You can't run away
Out of the hall of heads
(written by They Might Be Giants)
Java may be slow (although this will become less of a problem as computer speeds increase) but I don't agree that it is unstable. On the contrary, Java's lack of pointers, run-time type checking, and garbage collector make Java programs much less likely to crash than C/C++ programs.
Of course, this assumes you are running your Java programs as programs, and not as applets in Netscape or IE...
BeOS is already pervasively multithreaded, unlike almost any other OS out there. Its nature makes debugging your apps a pain in the ass, but allows a 95% increase in processing power if you add a second CPU. Or so I've been told.
Multithreaded code isn't so hard to debug as long as you design your program very carefully in advance with multithreading in mind. It's when you take a program or API that was designed to be single-threaded and try to hack in the multithreading after the fact that things can get awful.
Hey! Since when is Lust the "evil counterpart" of Love? Shouldn't it be Love vs Hate?
Anyway, for the record:
Love: 4,911,400
Hate: 221,950