Another good one: stuff a piece of dry ice in a balloon, tie it shut, and give it to a coworker. Whatch him panic when he realizes the balloon is still getting bigger...
It'd probably make a good time-delayed water baloon. Just set it on the picnic table, and see if anyone notices...
CF is actually an interface(and really, it's just a repackaged ATA interface)...not really a device. IBM sells hard drives that conform to the CF interface. There are also flash devices out there.
And I wouldn't use it for swap space, anyway. When developing an embedded system, you really should slim your memory footprint as far as possible, so you'd fit inside your available RAM.
The way old-timer software developers talk about it, your really start thinking of proper memory usage as a nearly-lost art.
It boots from a CF device, which could be a rewritable device. On the other hand, it's possible that it could get by with a ROM filesystem, not making any changes at all.
Yup. It'd be neat if we had a passive filter to remove nitrogen from the air entering the engine. That would be a simple and effective pollution control mechanism.
My gut feeling is that the difference would have been minimal to having Helium vs Hydrogen as far as that accident. (assuming the design changes needed for Helium would not have worsened the situation.)
That's an interesting point. Using Helium would have required a much larger surface area, which would have required much more paint. So there'd have been more of that stuff to burn.
Well, from what I understand, the main reason people died was that they jumped from the gondola while the Hindenberg was still too high. Those who jumped when it was a lot lower mostly escaped with burns.
If inhaled hydrogen before...It didn't go very far before something in me forced me to exhale and search for oxygen instead. I swear, it was an accident!
Nitrogen is the most stable diatomic elemental gas I know of. There's a triple bond between nitrogen nuclei, so it takes an awful lot of energy to rip apart the molecule.
Even if you do, and you react the resulting N3- ions with something else, you're not going to get much energy out.
Hmm...you might be able to store energy by ionizing and storing the gas. But that sounds like a lot of energy. I'll have to ask my chem teacher.
Mozilla is cross-platform, not the web app he developed. Having used Mozilla as a platform, the editors can access the web app from Linux or Windows, depending on whether they're at work or at home.
I knew kids in high school who would have done it as a joke if they knew how. Now imagine if they had a little intelligence added to all that humor...
Or don't add the intelligence at all. Wait till someone writes a program fashioned for script-kiddies. Then watch the script-kiddie scream when he realizes he can't play Counterstrike online after running that program he just ran.
Actually, I'd be more worried about the maintainers of warez sites. They're the ones without any respect for others. I don't know how low-level of network access Java allows, but if the applet were written, it wouldn't be hard to inline that into the page.
Whoever the poor idiot was who ran the applet would be damned whether or not investigators figured out he did it intentionally or not. If they figure he didn't do it intentionally, they've still got him for visiting a warez site.
Of course they will. However, I'd prefer to keep it at its present pace. What's needed is some sort of DRM applied to the patches to help resist reverse-engineering, which is how binary patches lead to exploits.
Now for OSS, it's a different matter. To begin with, you theoretically have fewer vulnerabilities shown to a network, and those that are aren't intuitively obvious. It's the intuitively obvious flaws like buffer overflows that most frequently have viruses written for them.
Now, I'm looking forward to the x86 extension that allows the OS to tag a portion of memory as non-executable. But that won't help if the "arbitrary code" is placed where an interpereter will read it, instead of being placed in a main codepath.
Small ISPs depend on the storage capability of the user to store their email. Storing it on the server takes an increasingly large amount of space over time, and ends up increasing the costs to the ISP when they have to upgrade their hardware to hold onto all that mail.
If there's a payout cap, I can't see why it wouldn't work. After all, with a patent system as admittedly borked as the US's, patent lawsuits can probably be won. Especially in cases where prior art to the patent, or the "logical next step" nature of the patent, can be demonstrated.
I've never had experience with EDA tools, but here goes:
A schematic, especially for a CPU, can be a huge thing. I can't see why you wouldn't want to parallelize large operations on it. Especially simulations. So either you want a massive vector unit in your system, or you want to split that large operation into smaller chunks, much the same way as one would process large images.
Wouldn't it make more sense to have the two cores combine and share their cache?
If not, I still wouldn't eliminate the use of the memory controller on the second core...the more memory the core can access directly, the less information it will have to get from other CPUs/cores over the HT link.
I'm a hardcore Debian user myself, but I experience trouble both when I upgraded from 2.2 to 2.4, and from 2.4 to 2.6. Of course, that was when the latest major revision was very new, so my trouble was with tool support.
modconf didn't support the 2.4/lib/modules/ format right away, and didn't support the 2.6 format when my box was last connected to the Internet. (Which was a long time ago, when I was playing with 2.6.0rc1)
Of course, upgrading the utilities solve the issue.
Well, what religions call miracles, science tends to call "something we don't understand yet."
I actually subscribe to both views...there's no reason God couldn't have done exactly what's set forth in the Bible, yet created the earth to look exactly as it does. I feel that anyone who thinks that that is impossible doesn't believe in God as all-powerful.
Slashdot Mirror
Another good one: stuff a piece of dry ice in a balloon, tie it shut, and give it to a coworker. Whatch him panic when he realizes the balloon is still getting bigger...
It'd probably make a good time-delayed water baloon. Just set it on the picnic table, and see if anyone notices...
My favorite one was when he compared against "Linux 7.0"
I smile every time I see that.
CF is actually an interface(and really, it's just a repackaged ATA interface)...not really a device. IBM sells hard drives that conform to the CF interface. There are also flash devices out there.
And I wouldn't use it for swap space, anyway. When developing an embedded system, you really should slim your memory footprint as far as possible, so you'd fit inside your available RAM.
The way old-timer software developers talk about it, your really start thinking of proper memory usage as a nearly-lost art.
So they're going to have to arrest people who block the solar panels, right?
It boots from a CF device, which could be a rewritable device. On the other hand, it's possible that it could get by with a ROM filesystem, not making any changes at all.
/dev/shm ...
Of course, there's still
Yup. It'd be neat if we had a passive filter to remove nitrogen from the air entering the engine. That would be a simple and effective pollution control mechanism.
My gut feeling is that the difference would have been minimal to having Helium vs Hydrogen as far as that accident. (assuming the design changes needed for Helium would not have worsened the situation.)
That's an interesting point. Using Helium would have required a much larger surface area, which would have required much more paint. So there'd have been more of that stuff to burn.
Well, from what I understand, the main reason people died was that they jumped from the gondola while the Hindenberg was still too high. Those who jumped when it was a lot lower mostly escaped with burns.
If inhaled hydrogen before...It didn't go very far before something in me forced me to exhale and search for oxygen instead. I swear, it was an accident!
Nitrogen is the most stable diatomic elemental gas I know of. There's a triple bond between nitrogen nuclei, so it takes an awful lot of energy to rip apart the molecule.
Even if you do, and you react the resulting N3- ions with something else, you're not going to get much energy out.
Hmm...you might be able to store energy by ionizing and storing the gas. But that sounds like a lot of energy. I'll have to ask my chem teacher.
Mozilla is cross-platform, not the web app he developed. Having used Mozilla as a platform, the editors can access the web app from Linux or Windows, depending on whether they're at work or at home.
At least, that's how I read it.
...welcome our new XUL overloards.
But if she gets out of hand, bring on the Ghostbusters!
And catch someof that liquid marshmellow for me.
I knew kids in high school who would have done it as a joke if they knew how. Now imagine if they had a little intelligence added to all that humor...
Or don't add the intelligence at all. Wait till someone writes a program fashioned for script-kiddies. Then watch the script-kiddie scream when he realizes he can't play Counterstrike online after running that program he just ran.
Actually, I'd be more worried about the maintainers of warez sites. They're the ones without any respect for others. I don't know how low-level of network access Java allows, but if the applet were written, it wouldn't be hard to inline that into the page.
Whoever the poor idiot was who ran the applet would be damned whether or not investigators figured out he did it intentionally or not. If they figure he didn't do it intentionally, they've still got him for visiting a warez site.
Of course they will. However, I'd prefer to keep it at its present pace. What's needed is some sort of DRM applied to the patches to help resist reverse-engineering, which is how binary patches lead to exploits.
Now for OSS, it's a different matter. To begin with, you theoretically have fewer vulnerabilities shown to a network, and those that are aren't intuitively obvious. It's the intuitively obvious flaws like buffer overflows that most frequently have viruses written for them.
Now, I'm looking forward to the x86 extension that allows the OS to tag a portion of memory as non-executable. But that won't help if the "arbitrary code" is placed where an interpereter will read it, instead of being placed in a main codepath.
So I expect you'll see a distributed effort, using viruses. (shudder)
Small ISPs depend on the storage capability of the user to store their email. Storing it on the server takes an increasingly large amount of space over time, and ends up increasing the costs to the ISP when they have to upgrade their hardware to hold onto all that mail.
Unless IPv6 includes the TCP protocol, I don't think so. AFAIK, it runs on top of TCP, just like traditional TCP/IP (a.k.a. IPv4) does.
Great. Now I'll really start noticing the scheduling timeslices.
I suddenly had a picture of a musical that took place in a courtroom. Odd.
If there's a payout cap, I can't see why it wouldn't work. After all, with a patent system as admittedly borked as the US's, patent lawsuits can probably be won. Especially in cases where prior art to the patent, or the "logical next step" nature of the patent, can be demonstrated.
Then what's your stand going to be when a Linux or other free software contributor who doesn't subscribe gets nailed with a patent lawsuit?
Would you recommend that free software contributors be part of an organization capable of paying the subscription fee?
I've never had experience with EDA tools, but here goes:
A schematic, especially for a CPU, can be a huge thing. I can't see why you wouldn't want to parallelize large operations on it. Especially simulations. So either you want a massive vector unit in your system, or you want to split that large operation into smaller chunks, much the same way as one would process large images.
Wouldn't it make more sense to have the two cores combine and share their cache?
If not, I still wouldn't eliminate the use of the memory controller on the second core...the more memory the core can access directly, the less information it will have to get from other CPUs/cores over the HT link.
I'm a hardcore Debian user myself, but I experience trouble both when I upgraded from 2.2 to 2.4, and from 2.4 to 2.6. Of course, that was when the latest major revision was very new, so my trouble was with tool support.
/lib/modules/ format right away, and didn't support the 2.6 format when my box was last connected to the Internet. (Which was a long time ago, when I was playing with 2.6.0rc1)
modconf didn't support the 2.4
Of course, upgrading the utilities solve the issue.
Well, what religions call miracles, science tends to call "something we don't understand yet."
I actually subscribe to both views...there's no reason God couldn't have done exactly what's set forth in the Bible, yet created the earth to look exactly as it does. I feel that anyone who thinks that that is impossible doesn't believe in God as all-powerful.