My motherboard didn't come with an OS. Neither did the CPU chip or the drives or the ram or the case... I didn't see any part that was outrageously-priced, and if I had, I would have bought it in another store. (Come to think of it, some parts were from another store.)
On four occasions, the batteries in the Kyocera phones have short-circuited and heated up enough to trigger a built-in safety mechanism that vents superheated gases in order to avoid an explosion, according to the safety commission.
Obviously the phones need a voice-warning politeness option. Just before venting superheated gas, the phones could speak warnings such "Whooah!", "Pardon me!", "Burrito meltdown!", "Better out than in!". (Enterprising phone companies could sell custom "blow-tone" warnings.)
I forgot the smiley after VB.:) It's definitely a Linux box, and the resources link makes it pretty clear that it's a specific configuration. Since this is an algorithm battle, the particular language isn't too important. (Athough I'm surprised Java wasn't on the list. Hmm, a LISP squirrel?)
Not much warning however: Deadline for NUTS is November 30th, 2004. I think I'll wait for the next one.
In a perfect world the base protocols, as documented, should do the job. P2P, firewalls, NAT and routers should work properly on top of them. But darn it, I seem to live on Bizarro World instead!
I can't speak for the designers of the P2P protocols. I haven't looked at their code to see what happens, and the documentation tends to be sketchy. I don't know why most tend to keep trying for days, only that they do. I only hope that the UDP P2Ps are better implemented--especially by the more enthusiastic implementors who frequently tweek without understanding.
Current languages include C, C++, Perl, Python, PHP, Shells, and a few other non-compiled interpreters - the resources link will tell you what you need to know about the programming environment.
From the resources link, better check to make sure everything you think you need is available in the sandbox.
P.S. how well does that guaranteed system-level NACK work when someone is using a P2P protocol designed to sneak through firewalls? (Especially if it's a magic "stealth" firewall that eats ICMP packets coming back saying the port is unreachable?)
Yes, I've heard of ICMP. Do they really test for Unreachable responses? Amazing how fscking poorly it works then. (And no, I'm not eating ICMP responses with a "stealth" "firewall".)
eDonkey and BitTorrent never seem to give up trying no matter what they get as a response. (Of course, it could be that someone has hax0red their copy to try and squeeze a bit more cps out of their version.) Sorry, but I've seen no evidence that most protocols have any working code to detect that the other end isn't interested.
Spot on! P2P with TCP can be irritating enough when some index tells everyone that my new IP address is the place to look for the last piece of Debbie Does DDoS. Some of those cheesy protocols never give up.
All the kludged Fred's UDP P2P protocols will be a menace.
Oh good! So when someone starts a moby transfer that's going to take forever, and crashes his machine trying to game with scores of spyware running at the same time, then I can be next in line to pick up his old DHCP dynamic IP address.
I'm so looking forward to having my bandwidth eaten by a system that wants a precise STFU packet to stop spewing at me.
Slashdot Mirror
Why not just get self-cooling cans? Or use this geeky Peltier one can chiller? (Do not overclock your beer!)
Now you might be asking yourself: Did he play five hours of music or six? .."
I doubt that Kipling's McAndrew's Hymn would be as impressive if redone for micro-engines or hamsters.
Laptops? What about listening to music on your Steam-Pod? Stoke up the volume!
My motherboard didn't come with an OS. Neither did the CPU chip or the drives or the ram or the case... I didn't see any part that was outrageously-priced, and if I had, I would have bought it in another store. (Come to think of it, some parts were from another store.)
Bagpipes? Moose? :)
I think slashdotting is a myth. No one ever RTFAs, so how could it bring sites down?
Any equivalents in OSS?
Too late, I already use Warning! on my firewall when Slashdot proxy-probes port 8080. :)
I want a button on my phone to turn it into an anti-car weapon to toss at cell phone talkin' drivers.
Until you posted, I hadn't thought about the pr0n possibilities. A teledildonic brothel, egads!
Tinkering with a fresnel lens to get a larger virtual display with depth. (Haven't tried this, don't know how well it works.)
Not much warning however: Deadline for NUTS is November 30th, 2004. I think I'll wait for the next one.
I can't speak for the designers of the P2P protocols. I haven't looked at their code to see what happens, and the documentation tends to be sketchy. I don't know why most tend to keep trying for days, only that they do. I only hope that the UDP P2Ps are better implemented--especially by the more enthusiastic implementors who frequently tweek without understanding.
Yeah, it's amazing what great oldies still turn up in eight-track audio format in the garage-sales. :)
P.S. how well does that guaranteed system-level NACK work when someone is using a P2P protocol designed to sneak through firewalls? (Especially if it's a magic "stealth" firewall that eats ICMP packets coming back saying the port is unreachable?)
eDonkey and BitTorrent never seem to give up trying no matter what they get as a response. (Of course, it could be that someone has hax0red their copy to try and squeeze a bit more cps out of their version.) Sorry, but I've seen no evidence that most protocols have any working code to detect that the other end isn't interested.
Me too. And we liked it too! (It sure beat running debug traces out the serial port to a terminal.)
All the kludged Fred's UDP P2P protocols will be a menace.
I'm so looking forward to having my bandwidth eaten by a system that wants a precise STFU packet to stop spewing at me.
Sure. You didn't Clippy was invented by a human being, did you?
(Just kidding)
What about if I swap the serial number chip in my printer with the data recorder one in my car? That'll fsck them up!