Glad I'm a Neilson family this week
on
WB Cancels Angel
·
· Score: 4, Insightful
This sort of stupidity makes me glad I am a Nielson family this week.
Keeping track of what I watch has brought home to me how little I DO watch. Angel is one of the shows I watch.
The great thing is this datum will be entered into Nielson's computers - that Angel has a person making damn good money watching it, and NOT MUCH ELSE on WB.
Since most of television today is either a) "Reality" shows (HEY KIDS! LET'S STAB EACH OTHER IN THE BACK TO GET AHEAD!) b) Sit-coms (HEY KIDS! LET'S HIT THE LAUGH TRACK EVERYTIME SOMEBODY SAYS SOMETHING! THAT WILL MAKE IT FUNNY!) c) CSI (HEY KIDS! LETS MAKE A SHOW ABOUT SCIENCE THAT GETS IT WRONG ON EVERY SHOW) d) Law and order (HEY KIDS! LET'S PULL SHIT THAT NO REAL JUDGE WOULD TOLERATE!)
After all, you now have NBC (All "Law and Order", all the time), CBS (All "CSI", all the time), WB (All Pokemon, all the time), and UPN (All crap, all the time.) Yeah, I *really* want to run out and buy a HDTV.
It is too late for you to do anything that has a meaningful chance of success, but I wish you luck anyway.
What you SHOULD have done was:
Verified IN THE STORE that the package specifically mentioned multiplayer gaming. If not, do not buy the game if that is what you want.
Assuming the package mentioned multiplayer, as soon as you got home verified the multiplayer mode. When you found it absent, check online for updates.
When you found no MP updates online, you should have gone back to the store, and demanded your money back. The store would give you a lot of shit over the "no returns unless the game is defective, then only return for store credit or same game". You then point out that the box says multiplayer, the game is not multiplayer, therefor game does not do what it is advertised to do, therefor defective, and since any other copy on the shelf is "defective" as well, store credit or money back.
I am not saying the above has a 100% chance of success, but at least you would have had some chance to succeed. Furthurmore, should more people do this, the stores will get tired of the returns and will charge back to the distributor, who will in turn go after the manufacturer.
In short - if you cannot buy what you want TODAY - DON'T. Don't accept promises that "It will do $thing later" - say "Fine - then when it does $thing I will buy it. Until then the money stays in my bank. Good day."
"Sometimes you have to shoot the enginner and ship the product."
Back off that flamebait, friend - I *AM* the engineer.
If you adopt a "We will ship this when it is done" then it never will be done, for a variety of reasons:
The engineer will always think up some cool new feature, and absent any motivation not to, put it into the product. It takes YEARS of experience to learn the self-control to not do this (hell, I have decades of experience and I still succumb to that temptation on occasion.)
The marketing guys will always think up some cool new feature, and absent any motivation not to, pester the engineer to put it in.
The Q/A guys will say "I won't waste my time looking at anything that is not at least a release candidate." If the engineer releases an RC, absent any firm schedule, the Q/A guys will blow it off and not test it.
When the Q/A guys finally do get bored enough to look at the code, they WILL find bugs, so there will always be one more bug to fix, and absent any motivation not to, the engineer will fix the bug in the current codebase - thus generating a new version that must go through Q/A (see above).
Sometimes having a firm deadline is a wonderfully focusing motivator - the engineer will say "This is a cool idea - I will save it for AFTER the release", the marketing guys will say "Well, the customers want this really cool feature, but the return on investment isn't enough to jepordize the ship date, so we'll put it in later", the Q/A guys say "We'd better check this NOW, so any problems can get fixed before release data", and you actually make progress.
Of course, when the deadlines are not set with the buy-in of the engineers, the marketing people, and upper management, but rather are set for some highly arbitrary date....
For example, while Hannibal know that he was viewed as evil by society (he was crazy, not stupid), he did not believe himself to be evil - he was a sociopath; he had no personal concept of evil, just "what do I want to do today?" (or rather, "Who do I want to eat today?")
Most fantasy villans believe their actions are correct, usually because "I am destined to rule", or "I will bring order to the world".
True, there are the crazyevil folks - the "I want to DESTROY EVERYTHING MUHAHAHAHA" types in fiction. However, crazyevil (and I am deliberately combining those two words) people aren't as threatening simply BECUASE they are crazy - they end up doing something stupid and thus losing. The Hans Gruber (Die Hard 1) bad guys, who are in control, cold, calculating, are FAR more dangerous than the Riff Raff "YOU NEVER LIKED ME!" crazyevil types. Riff might shoot you with the ZZ-Top AntiMatter Lazer (again, I misspelled that deliberately), but Hans will coldly let you think you are going free then blow you up.
I've said it before, and I shall now say it again:
Evil does not think itself evil
While villans in cheap movies may rub their hands together and cackle about how eeeeeeviiiil they are, in the real world those who do evil do not see themselves as evil.
The pusher on the corner doesn't see himself as evil, "Yo, I'm just givin' folks what they want."
Saddam did not see himself as evil, "I am maintaining order in my country - this person is a threat to that order, and to prevent others from becoming threats I must make an example of him. Uday, turn on the wood chipper."
Darl McBride does not see himself as evil, "I am running a business. This is my chance to make money."
If you want your villans to be believable, try to get inside their heads and make their actions make sense from their perspective. It's taxing, it's scary, but it makes for a believable villan.
Vary the brightness of a small light bulb. Vary the speed of a small motor. Drive an old-style swing needle meter. (Variant of above) Drive a tachometer.
Heck, why not interface to a slot-car and have it go faster the higher your load average is?
A package declares what other packages are required to install. Imagine if you were installing a program that *required* IE6.0 and Media player 5.0: a Windows installer will start up, run, and then barf saying you need to install something. A package would allow to to determine BEFORE you start that you need other things installed.
A package lists all files to be installed, and a package manager tracks who installed what. Thus, when you encounter a file you don't recognize, you can ask the system "Where is this from?" and the system can tell you "This was installed when you installed Gator.1.2"
A package can be digitally signed so that you know who created it without a doubt, and you can tell your package manager who you trust and who you do not trust. Again, this key can be inspected without running the installer.
Because packages detail what files they will install and what packages they depend upon, it makes the creation of a repository easier - a repo is a collection of packages that can be accessed by a program, so that you can say "Let's see - I want that, that, and that, but not that. Install those, please."
-fomit-frame-pointer makes it a bitch to debug things - I don't like making debugging harder.;)
Yes, APT is a great piece of the puzzle, but it doesn't solve everything - for example, in Fedora, there was a package checked in for Bittorrent-GUI, which required a package wxPython, which exists NOWHERE on the 'Net. Smooth.
That is one thing I will give the Debian folks - you make your package work or you don't get in stable.
What I'd like to see is more distro vendors moving to a metapackaging system like APT, and then the following rule applied throughout:
Either your package uses packages from some standard repository (Linux standard base, anyone?)
OR
You will provide all needed packages that are NOT in that standard set in your APT repository.
So if I provide Foo.1.2.3, and it requires Narf.2.4.pentium, and the standard repository is providing Narf.2.3, then I must provide Narf.2.4.pentium on my site.
Of course, I would also pimpslap anybody who actually depended upon Narf.2.4.pentium as opposed to simply Narf.2.4.
And to address the tweakophillia of the Gentoo types - what about a program that could be run from a cron job that would examine all recently installed packages, pull the source packages, rebuild them with the locally provided options, and upgrade them? Thus, I could *quickly* install Poit.9.1, and then tonight my machine would pull Poit.9.1.src, build it with "-Os -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse,387", and install it.
There's an aspect of the Crusoe and code morphing that I am surprised that Transmeta and some vendor haven't jumped on - the idea of using CMS to simulate hardware.
Consider the Centrino chipset from Intel, specifically the 802.11 part. (Now, this is conjecture on my part, but fits the observed behavior of Intel as a corporation and the Centrino chipset, so if somebody can prove me wrong please do so.)
I suspect the real reason that Intel is uneasy about releasing Linux drivers for the Centrino's WLAN chip is not just that an open source driver could be programmed to operate out of band or over power. I suspect that the WLAN chip is little more than a DMA core and an RF A/D converter (actually, a quadrature programmable up converter)- that the actual modulation/demodulation are being done by the CPU. Were that the case, then releasing the driver would expose a complete 802.11* modulation/demodulation algorithm. Furthurmore, modifications to that code could perform other forms of modulation besides 802.11 - a regulatory nightmare.
Now, consider the Crusoe. What if you had a version of the CMS that emulated a hardware device at a specific set of I/O addresses? The x86 driver would queue a bufferlist of symbols to be modulated, and, from the perspective of the x86 driver, "hardware" would DMA that data, modulate it, and send it. Simillarly, the x86 driver would queue a bufferlist of empty buffers, and "hardware" would receive the data, demodulate it, and fill the buffers.
Now the real work would be done in native CMS micro-ops. The micro-ops would create the modulation buffers from the symbol buffers (storing them into the CMS working area), and would set up the REAL DMA to transfer those modulation buffers to the RF section. Simillarly, the CMS code would set up the RF section to fill buffers in CMS-space with received data, which would then be decoded by the CMS code into symbols and placed into the x86 bufferspace.
The advantage of this is that the x86 drivers for (Windows|Linux|*BSD) would not contain any of the "magic" that causes problems - indeed, the "hardware" could have a register that sets the region the system supposedly is in, allowing the "hardware" (CMS driver) to select power levels, frequencies, and modulation schemes that are permissable to the area (e.g. USA, England, etc.) Thus the drivers could be completely Free.
I would think that this could allow a one-chip-wonder computer - a single Transmeta part for the main system, with integrated video, 802.11, Bluetooth, audio, V.90 modem, etc. Add an RF chip for the RF side of the Bluetooth and 802.11, RAM, a flash-ROM chip, et voila! A very low power, all integrated laptop/PDA/Phone/Set top box/Whatever that could have GOOD driver support under any OS.
(Yes, such a technique would shoot to hell any chance of hard-realtime in the OS, as "hardware" might preempt the code. However, I would not want to do hard real time on a Crusoe anyway, as you simple cannot guarantee the execution time of any block of code due to the possiblity of needing to re-morph it.)
And now when you sort the data base, your sort is useless because all the data is alike.
So you have to make the data be sortable, yet obfuscated. And that is where you run the risk of data leakage.
So, if you have an algorithm that will yield sortable data but is not trivially reversable, then you should be able to create random data rather than basing your data upon a real dataset.
Part of the annoyance was the lack of information - "Door ajar. Door ajar."
OK, which fscking door is it?!?
Also, this would start the instant the door was opened with the key in place. Had it dinged a couple of times first, then said "Driver's door ajar" or "Front right door ajar" (or for you who drive on the wrong side of the road, "Front left door ajar";) then it might not have been quite so annoying.
The Plain Old Telephone System is not analog, save the "last mile" to your house. As soon as you hit the line card, you are a 8 kSample/sec 8 bit/sample digital data stream.
What you MEANT to say was, "How long until the end of the circuit-switched network is replaced by a packet-switched network."
And when you start throwing Quality-Of-Service guarantees, bandwidth guarantees, and everything else to make a packet-switched network have the level of performance and reliability that the circuit-switched network has, guess what - you've just created a circuit-switched network!
Why screw with some complicated method? Just say "To access my SSH port, first send a UDP datagram to port $foo containing this data [list]".
Since you cannot tell if anybody received a UDP datagram or not, you can then have the stealth advantages of not having a TCP port open until the UDP packet comes in.
And if you require the UDP packet to be a time-stamped message, signed with a keypair, you can protect yourself against replay attacks and such.
A tube amp distorts the signal. As a tube amp is overloaded, it goes into compression - an N percent change in the signal starts to yield an N/2 percent compression (actually it is a logarithmic ratio).
Solid state amps are pretty much linear (N percent in is N percent out) right up to the limit, then they STOP DEAD - what is known as clipping.
Now, to the human ear clipping is VERY objectionable, while compression is not.
So, when you are deliberately compressing a signal (to simulate sustain on a guitar, for example), you want the amp to compress the signal, not clip it (unless you are trying to fuzz the signal).
However, when you are PLAYING BACK a recording, you want the amp to represent the signal exactly - you don't want compression, you don't want clipping, you want "a stright wire with gain".
I have a technology they missed (granted, it is somewhat specialized), and one I feel they incorrectly marked.
The one they missed is IEEE-488 (a.k.a. GPIB) - a control bus used in instrument control. 1 Mbyte/sec (unless you used a bastardized protocol), 30 units maximum, length limits, interface cards that cost US$500 or more, yet customers are STILL asking for GPIB over USB or Ethernet.
The one they wiffed on is vacuum tubes. Sorry, but when it comes to making high power RF amplifiers tubes are hard to beat - it is a great deal easier to use a vacuum tube running at 3000V to make a kilowatt of RF than a transistor at 30V - and when you get up to microwaves (2GHz and up) tubes are kings. True, when a (sic)audiophile(cough) claims tubes are better for low power audio.... Well, as a coworker of mine says, "I don't argue with wheelbarrows - I push them."
First point - like many of the other posters, I think you may wish to start reducing your caffine intake, as it sounds like you are becoming chemically dependant. I was in a similar state a few years back - if I slept in on Saturday, I would awaken with a caffine-withdrawl headache; I simply HAD to have that first shot of coffee before 0730.
OK, so assume you either a) cut down or b) disregard - what to do about coffee? Go forth to the World of Wally, and purchase an Air Pot - this ia a large Thermos-style container with a spout and an air pump on the top. Brew your coffee as normal in the morning. Fill the air pot with hot water (to pre-heat it), then dump the water and fill it with coffee (should you be concerned about wasting water, dump the water into the coffee maker for the next batch). Take air pot to work. A good air pot will keep the coffee hot for 24 hours or more - a 3x overcapacity for your needs.
When the jones'n hits you, put cup under spout, press pump button, et voila! A cup of brewed, fresh coffee.
Think this through - how does Slashdot conduct an interview?
They send the interviewee questions VIA EMAIL, and get the responses VIA EMAIL.
Ergo:
1) It is unlikely that/.'s questions would get through the wall of flames to this moron. 2) It is unlikely the/. crew would wish to give this moron a live email address to respond to. 3) Assuming they did, it is unlikely this moron's response would be accepted by the/. mail servers - it would in all likelihood be rejected as spam.
Slashdot Mirror
This sort of stupidity makes me glad I am a Nielson family this week.
Keeping track of what I watch has brought home to me how little I DO watch. Angel is one of the shows I watch.
The great thing is this datum will be entered into Nielson's computers - that Angel has a person making damn good money watching it, and NOT MUCH ELSE on WB.
Since most of television today is either
a) "Reality" shows (HEY KIDS! LET'S STAB EACH OTHER IN THE BACK TO GET AHEAD!)
b) Sit-coms (HEY KIDS! LET'S HIT THE LAUGH TRACK EVERYTIME SOMEBODY SAYS SOMETHING! THAT WILL MAKE IT FUNNY!)
c) CSI (HEY KIDS! LETS MAKE A SHOW ABOUT SCIENCE THAT GETS IT WRONG ON EVERY SHOW)
d) Law and order (HEY KIDS! LET'S PULL SHIT THAT NO REAL JUDGE WOULD TOLERATE!)
After all, you now have NBC (All "Law and Order", all the time), CBS (All "CSI", all the time), WB (All Pokemon, all the time), and UPN (All crap, all the time.) Yeah, I *really* want to run out and buy a HDTV.
What you SHOULD have done was:
I am not saying the above has a 100% chance of success, but at least you would have had some chance to succeed. Furthurmore, should more people do this, the stores will get tired of the returns and will charge back to the distributor, who will in turn go after the manufacturer.
In short - if you cannot buy what you want TODAY - DON'T. Don't accept promises that "It will do $thing later" - say "Fine - then when it does $thing I will buy it. Until then the money stays in my bank. Good day."
Back off that flamebait, friend - I *AM* the engineer.
If you adopt a "We will ship this when it is done" then it never will be done, for a variety of reasons:
Sometimes having a firm deadline is a wonderfully focusing motivator - the engineer will say "This is a cool idea - I will save it for AFTER the release", the marketing guys will say "Well, the customers want this really cool feature, but the return on investment isn't enough to jepordize the ship date, so we'll put it in later", the Q/A guys say "We'd better check this NOW, so any problems can get fixed before release data", and you actually make progress.
Of course, when the deadlines are not set with the buy-in of the engineers, the marketing people, and upper management, but rather are set for some highly arbitrary date....
Or to put it another way:
"Everybody! Stay away from the brown source code! Do NOT take the brown source code!"
There is a world of difference between
"believing yourself to be evil"
and
"believing society believe you to be evil."
For example, while Hannibal know that he was viewed as evil by society (he was crazy, not stupid), he did not believe himself to be evil - he was a sociopath; he had no personal concept of evil, just "what do I want to do today?" (or rather, "Who do I want to eat today?")
Most fantasy villans believe their actions are correct, usually because "I am destined to rule", or "I will bring order to the world".
True, there are the crazyevil folks - the "I want to DESTROY EVERYTHING MUHAHAHAHA" types in fiction. However, crazyevil (and I am deliberately combining those two words) people aren't as threatening simply BECUASE they are crazy - they end up doing something stupid and thus losing. The Hans Gruber (Die Hard 1) bad guys, who are in control, cold, calculating, are FAR more dangerous than the Riff Raff "YOU NEVER LIKED ME!" crazyevil types. Riff might shoot you with the ZZ-Top AntiMatter Lazer (again, I misspelled that deliberately), but Hans will coldly let you think you are going free then blow you up.
I've said it before, and I shall now say it again:
Evil does not think itself evil
While villans in cheap movies may rub their hands together and cackle about how eeeeeeviiiil they are, in the real world those who do evil do not see themselves as evil.
The pusher on the corner doesn't see himself as evil, "Yo, I'm just givin' folks what they want."
Saddam did not see himself as evil, "I am maintaining order in my country - this person is a threat to that order, and to prevent others from becoming threats I must make an example of him. Uday, turn on the wood chipper."
Darl McBride does not see himself as evil, "I am running a business. This is my chance to make money."
If you want your villans to be believable, try to get inside their heads and make their actions make sense from their perspective. It's taxing, it's scary, but it makes for a believable villan.
Set up a machine with 4MB of RAM, and NFS mounted root and swap.
Boot KDE or Gnome.
OK, this is neat, but WHY?
This same circuit could be adapted to:
Vary the brightness of a small light bulb.
Vary the speed of a small motor.
Drive an old-style swing needle meter.
(Variant of above) Drive a tachometer.
Heck, why not interface to a slot-car and have it go faster the higher your load average is?
And if you look at the date, you will see it is fairly recent.
Now, go look at when BTUI was posted to Fedora.
And if you are in Kansas, you can see them st the Kansas Cosmosphere and Space Center.
The differences are:
A package declares what other packages are required to install. Imagine if you were installing a program that *required* IE6.0 and Media player 5.0: a Windows installer will start up, run, and then barf saying you need to install something. A package would allow to to determine BEFORE you start that you need other things installed.
A package lists all files to be installed, and a package manager tracks who installed what. Thus, when you encounter a file you don't recognize, you can ask the system "Where is this from?" and the system can tell you "This was installed when you installed Gator.1.2"
A package can be digitally signed so that you know who created it without a doubt, and you can tell your package manager who you trust and who you do not trust. Again, this key can be inspected without running the installer.
Because packages detail what files they will install and what packages they depend upon, it makes the creation of a repository easier - a repo is a collection of packages that can be accessed by a program, so that you can say "Let's see - I want that, that, and that, but not that. Install those, please."
-pipe is only good at saving compile time.
;)
-fomit-frame-pointer makes it a bitch to debug things - I don't like making debugging harder.
Yes, APT is a great piece of the puzzle, but it doesn't solve everything - for example, in Fedora, there was a package checked in for Bittorrent-GUI, which required a package wxPython, which exists NOWHERE on the 'Net. Smooth.
That is one thing I will give the Debian folks - you make your package work or you don't get in stable.
What I'd like to see is more distro vendors moving to a metapackaging system like APT, and then the following rule applied throughout:
Either your package uses packages from some standard repository (Linux standard base, anyone?)
OR
You will provide all needed packages that are NOT in that standard set in your APT repository.
So if I provide Foo.1.2.3, and it requires Narf.2.4.pentium, and the standard repository is providing Narf.2.3, then I must provide Narf.2.4.pentium on my site.
Of course, I would also pimpslap anybody who actually depended upon Narf.2.4. pentium as opposed to simply Narf.2.4.
And to address the tweakophillia of the Gentoo types - what about a program that could be run from a cron job that would examine all recently installed packages, pull the source packages, rebuild them with the locally provided options, and upgrade them? Thus, I could *quickly* install Poit.9.1, and then tonight my machine would pull Poit.9.1.src, build it with "-Os -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse,387", and install it.
There's an aspect of the Crusoe and code morphing that I am surprised that Transmeta and some vendor haven't jumped on - the idea of using CMS to simulate hardware.
Consider the Centrino chipset from Intel, specifically the 802.11 part. (Now, this is conjecture on my part, but fits the observed behavior of Intel as a corporation and the Centrino chipset, so if somebody can prove me wrong please do so.)
I suspect the real reason that Intel is uneasy about releasing Linux drivers for the Centrino's WLAN chip is not just that an open source driver could be programmed to operate out of band or over power. I suspect that the WLAN chip is little more than a DMA core and an RF A/D converter (actually, a quadrature programmable up converter)- that the actual modulation/demodulation are being done by the CPU. Were that the case, then releasing the driver would expose a complete 802.11* modulation/demodulation algorithm. Furthurmore, modifications to that code could perform other forms of modulation besides 802.11 - a regulatory nightmare.
Now, consider the Crusoe. What if you had a version of the CMS that emulated a hardware device at a specific set of I/O addresses? The x86 driver would queue a bufferlist of symbols to be modulated, and, from the perspective of the x86 driver, "hardware" would DMA that data, modulate it, and send it. Simillarly, the x86 driver would queue a bufferlist of empty buffers, and "hardware" would receive the data, demodulate it, and fill the buffers.
Now the real work would be done in native CMS micro-ops. The micro-ops would create the modulation buffers from the symbol buffers (storing them into the CMS working area), and would set up the REAL DMA to transfer those modulation buffers to the RF section. Simillarly, the CMS code would set up the RF section to fill buffers in CMS-space with received data, which would then be decoded by the CMS code into symbols and placed into the x86 bufferspace.
The advantage of this is that the x86 drivers for (Windows|Linux|*BSD) would not contain any of the "magic" that causes problems - indeed, the "hardware" could have a register that sets the region the system supposedly is in, allowing the "hardware" (CMS driver) to select power levels, frequencies, and modulation schemes that are permissable to the area (e.g. USA, England, etc.) Thus the drivers could be completely Free.
I would think that this could allow a one-chip-wonder computer - a single Transmeta part for the main system, with integrated video, 802.11, Bluetooth, audio, V.90 modem, etc. Add an RF chip for the RF side of the Bluetooth and 802.11, RAM, a flash-ROM chip, et voila! A very low power, all integrated laptop/PDA/Phone/Set top box/Whatever that could have GOOD driver support under any OS.
(Yes, such a technique would shoot to hell any chance of hard-realtime in the OS, as "hardware" might preempt the code. However, I would not want to do hard real time on a Crusoe anyway, as you simple cannot guarantee the execution time of any block of code due to the possiblity of needing to re-morph it.)
And now when you sort the data base, your sort is useless because all the data is alike.
So you have to make the data be sortable, yet obfuscated. And that is where you run the risk of data leakage.
So, if you have an algorithm that will yield sortable data but is not trivially reversable, then you should be able to create random data rather than basing your data upon a real dataset.
Part of the annoyance was the lack of information - "Door ajar. Door ajar."
;) then it might not have been quite so annoying.
OK, which fscking door is it?!?
Also, this would start the instant the door was opened with the key in place. Had it dinged a couple of times first, then said "Driver's door ajar" or "Front right door ajar" (or for you who drive on the wrong side of the road, "Front left door ajar"
And simple for anybody to reverse, too.
Simple letter frequency analysis, coupled with a few dictionary searches, and bingo - I've recovered the data.
The Plain Old Telephone System is not analog, save the "last mile" to your house. As soon as you hit the line card, you are a 8 kSample/sec 8 bit/sample digital data stream.
What you MEANT to say was, "How long until the end of the circuit-switched network is replaced by a packet-switched network."
And when you start throwing Quality-Of-Service guarantees, bandwidth guarantees, and everything else to make a packet-switched network have the level of performance and reliability that the circuit-switched network has, guess what - you've just created a circuit-switched network!
Why screw with some complicated method? Just say "To access my SSH port, first send a UDP datagram to port $foo containing this data [list]".
Since you cannot tell if anybody received a UDP datagram or not, you can then have the stealth advantages of not having a TCP port open until the UDP packet comes in.
And if you require the UDP packet to be a time-stamped message, signed with a keypair, you can protect yourself against replay attacks and such.
A tube amp distorts the signal. As a tube amp is overloaded, it goes into compression - an N percent change in the signal starts to yield an N/2 percent compression (actually it is a logarithmic ratio).
Solid state amps are pretty much linear (N percent in is N percent out) right up to the limit, then they STOP DEAD - what is known as clipping.
Now, to the human ear clipping is VERY objectionable, while compression is not.
So, when you are deliberately compressing a signal (to simulate sustain on a guitar, for example), you want the amp to compress the signal, not clip it (unless you are trying to fuzz the signal).
However, when you are PLAYING BACK a recording, you want the amp to represent the signal exactly - you don't want compression, you don't want clipping, you want "a stright wire with gain".
I have a technology they missed (granted, it is somewhat specialized), and one I feel they incorrectly marked.
The one they missed is IEEE-488 (a.k.a. GPIB) - a control bus used in instrument control. 1 Mbyte/sec (unless you used a bastardized protocol), 30 units maximum, length limits, interface cards that cost US$500 or more, yet customers are STILL asking for GPIB over USB or Ethernet.
The one they wiffed on is vacuum tubes. Sorry, but when it comes to making high power RF amplifiers tubes are hard to beat - it is a great deal easier to use a vacuum tube running at 3000V to make a kilowatt of RF than a transistor at 30V - and when you get up to microwaves (2GHz and up) tubes are kings. True, when a (sic)audiophile(cough) claims tubes are better for low power audio.... Well, as a coworker of mine says, "I don't argue with wheelbarrows - I push them."
First point - like many of the other posters, I think you may wish to start reducing your caffine intake, as it sounds like you are becoming chemically dependant. I was in a similar state a few years back - if I slept in on Saturday, I would awaken with a caffine-withdrawl headache; I simply HAD to have that first shot of coffee before 0730.
OK, so assume you either a) cut down or b) disregard - what to do about coffee? Go forth to the World of Wally, and purchase an Air Pot - this ia a large Thermos-style container with a spout and an air pump on the top. Brew your coffee as normal in the morning. Fill the air pot with hot water (to pre-heat it), then dump the water and fill it with coffee (should you be concerned about wasting water, dump the water into the coffee maker for the next batch). Take air pot to work. A good air pot will keep the coffee hot for 24 hours or more - a 3x overcapacity for your needs.
When the jones'n hits you, put cup under spout, press pump button, et voila! A cup of brewed, fresh coffee.
Did you bother to look at what urushiol is?
I think distributing poison ivy throughout his body might be even more fun than trying to get enough estrogen into his system to cause problems.
And, again, the fact that I know about such matters should be a sign that my mail servers too are server with which not to fuck.
I'd like to send him a "personal lubricant" laced with urushiol and Dimethyl Sulfoxide.
Think this through - how does Slashdot conduct an interview?
/.'s questions would get through the wall of flames to this moron. /. crew would wish to give this moron a live email address to respond to. /. mail servers - it would in all likelihood be rejected as spam.
They send the interviewee questions VIA EMAIL, and get the responses VIA EMAIL.
Ergo:
1) It is unlikely that
2) It is unlikely the
3) Assuming they did, it is unlikely this moron's response would be accepted by the