You can usually cut dead weight at a company pretty easily by organizing them in alphabetical order by title, and going down the list firing people until you have enough money to pay everybody else.
Chief comes before Programmer, Executive comes before Technical...
The target audience doesn't know anything more about ethernet except "Hmm, I can plug the phone modem cord into either hole, but the big fat cord from the cable modem only fits into this one, so it must go this way".
The technical support required to get something like this set up in an "Ethernet. Etherwhat? What's that?" environment would be costly, and make the product less attractive to users.
"What? Of course I have a switch! How the hell do you think I turn my lights on?"
"Hub? Don't you hubba-hubba me, buster, or I'll call the cops. Now tell me where to plug this fuckin' thing in!"
Think about it. This is NOT a toy marketed at geeks.
Once again, the moderators are on crack
on
VoIP at $15 a Pop
·
· Score: 0, Flamebait
What is it with you guys, do you all work for Senator Disney? +2 interesting??? How about +3 funny!
The post is an obvious allusion to CD->MP3 recording combined with a healthy dose of tongue-in-cheek paranoia. It's a hell of a lot easier to tap somebody's PHONE and make calls than it is to tap an IP connection right now.
At any rate, there's one thing you haven't tried. Code in a datacenter with non-cycling air conditioners (dress warm). It will help you achieve the final state of "the zone". After a few hours of this, when you stand up, you may be lost (i.e. not know where you are, which way to the door, etc) for several seconds. If so, you have achieved the final state of "The Zone".
I once pulled a 53 hour day like that, got up from my seat only three times. I did two months worth of work.
I don't know about your habit, but mine is up to about 1500 mg a day. If I go more than 10 hours without a cup, I get withdrawal headaches so bad I'd literally trade them for a good swift kick in the nuts.
If you're going to advocate quitting caffeine, the least you could do is suggest that the user get down to zero intake in 100 mg per day steps.
That sounds right (remember, it's been fifteen years!!:-)
Now that I think about it, it *should* work. The VIC reads/writes RAM, which IIRC is under ROM. Except for the character set, of course.
I was thinking that jumping the address bus decoders (74138s?) into the right "shape" for the 6502 to use the default config might screw with the VICs access to chipset select lines. IIRC, the VIC puts the 6510 to "sleep", diddles the CS/A lines, and tells the 6510 to wake up when its done. There must be another bit of glue logic on the board that we could mess with (maybe adding a gate or two) that would allow the VIC chip to do what it wanted to. Hmm.
Again, I wish I had the schematics in front of me, it's SOO hard to remember stuff that long gone by. Anybody know if they're available online anywhere?
The 1520 datasette isn't "intended to be sensitive within certain high frequencies" -- it's basically an on-off device. Is there sound? On. Is there no sound? Off.
The reason it sounded like high-frequency shrieking is because that's how your ears perceived the rapid transition from sound-to-no-sound.
Okay, so it sounds like we're talking about the same thing, but the subtle difference explains a lot.
The digitizer program you're talking about was published in Compute's Gazette, I believe. Basically, it sampled the data from the tape player as the tape moved over the head. If there was sound, it jotted down a one; if there was no sound, it jotted down a zero. So, we've got a _one_bit_sample_rate_ -- nothing to do with frequency ranges at all!
The faster you can sample (and the CPU limits that quite effectively!), the better resolution you can get, but it is still one-bit sound, so it'll still sound like crap.
The playback program used a bug in the 6561 SID chip to replay one bit sounds quickly. Transitioning the volume from min to max or back was a fast operation (STA, XOR, STA -- 8 cycles, maybe?) and produced a side-effect "click". Not all C=64s had this side effect though, so some people couldn't play the music! Hahahaha. You poor bastards with the C64cs!:-)
You'd have to jumper the default memory mapping by hand, and not use any programs which make use of bank-switching code. (Whoops, there goes everything interesting).
The only concern I'd have is the VIC chip in that scenario; it might not be able to get at screen ram with the memory layout hard-coded.
Hmm, now where is my C64 PRG with the schematics at the back...
> Commodore was actually the first to mass-market > a system based on that type of head & disk format
Bzzt! Wrong. As far as I know, IBM was, but not Commodore. While its true both systems used 5.25" double-density disks, IBM PC disks are MFM encoded; Commdore's disks are GCR encoded from the 4040 (late 70s) until the release of the 1571 (late 80s). The 1571 added an MFM encoding mode and double-sided capability in order to be compatible with CP/M disks for the CP/M mode of the C128. That was the first drive able to read PC floppies, although extra hacking was required.
The 4040 (cum 1530, 1540, 1541) disk format that we're all familiar with held 170K -- actually, 169984 bytes of data after formatting, arranged in 664 blocks of 256 bytes.
1. Publish false mailto: addresses on your web pages in the same colour font as your background
2. Change them to visible, valid addresses by munging them with DHTML properties and a JavaScript include file (sorry, Lynx users)
3. When a recognizable spam-bot comes in, refuse to load the javascript include file. mod_setenvif and mod_rewrite should help out here.
4. When a probable spam-bot comes in, serve up the page reaalllly slowly, don't close the connection until it goes in CLOSE_WAIT. This ties up sockets on the remote machine and reduces its ability to troll OTHER sites. You can do this by writing a handler for your base directory, checking the browser, and returning DECLINED for friendly people. That should be in, I think the "post read" phase.
5. When a recognized bad address comes through to your mail server (from step 1), slooooow the SMTP transaction down as much as you can (same idea as step 4), and throw an error at the end of the 354 DATA section a few times (to force him to come back!), etc. (Some sendmail internals hacking required here, although it would be much easier to hack if you don't have any real mail and just ran a script from inetd.)
6. Those fake email addresses. Make them all point to a common MX or group of MXes that you control the DNS for. Make sure those MX records aren't used by anything legitimate. Slooooow your in.named down for requests to that domain. A cool side effect, besides tying up sockets on the spammers end, IIRC some OSs can only make one resolver request at a time -- this'll effectively block all of his out outbound spam traffic while he's trying to look up your MX record! Also, make sure the TTL is set to about 10 seconds, just to make sure he comes back the glue trap very often.
How's *that* for spam countermeasures? I wish I had time to write it.:-)
I'd wind up doing those changes myself whether I had a fancy content management system or not. If I had gotten one, I would have had to learn how to use it effectively, which probably would have taken a lot more time than banging out a few shell scripts.
But the BEST part: the execs understand that the CM is put together in shell, and that there is only so much it can do. (Well, that's what they think;-). They're just happy because they got it for "free" (as in beer). So, it stops a WHOLE PILE of moronic requests, like...
..can you change the "alert" button to blue? ..can you write a cache of user data on the guy's harddrive? ..can't you just see if the guy's using netscape, and if he is, load the page in IE? ..can you change the brower's borders to match the site layout? ..can you make the confirm dialog box use Arial fonts? ..can you generate thumbnails for the mp3s?
Happily! Before, we didn't have any content. Well, just a billion emails going everywhere and nobody knew what was going on. Of course, there was no budget for a CM system, so I "invented" one in my spare time that was put together with incredible speed.
> How much was invested for training?
Zero. Everybody who uses it also happens to be a unix systems programmer.
> How have you been finding it w.r.t. scalability and concurrent use?
Concurrent use problems were solved by doing all writes with a 10-line C program which blocks until it acquires an exclusive lock on the file.
("echo | copylock filename" instead of "echo >> filename")
Also, there are no "writes" to the data records, only appends. This happily also gets you a shell-parsable (while read line do eval blah done) revision model. Yay!
Reads never seemed to be an issue.
Scalability? Well, it scales big enough for what we do. A few hundred users, a little tiny overloaded linux box... It still works. If it ever stops working, then we'll "profile" the app (top) and move whatever pieces are sucking CPU into C.
The UNIX filesystem, though, seems to be a decent way to store data.
..is implemented with a magic program called, "bash" and few of its friends.
I can search by content (grep). I can search by date (find). I can filter to other types (sed). I can assign hiearchical meaning to records (mkdir).
I can even assign meaning by fields with the '=' operator, source the file with '.' and deference environment varibles!
Works great. I've implemented a change control system, a BBS (threads, fancy search engine, and all!), a user management system, a product management system and a bunch of other cool things with it.
Right now most of those systems support formatted plain text and html as output. But I could add an XYZ module with almost no effort.
So it's not secure. Nobody said anything about security.
Okay, so you take some fish up, and it gains in mass by 14%.
But, you also took up a bunch of cow abortions, which lost the equivalent mass, if not more.
So, where's the savings? Seems to be they'd be better off shipping up 14% more freeze-dried goldfish.
During launch, you put in a big box full of ice. After launch, you tie the fish to the outside of the spaceship (like beer, when ice fishing), melt the ice to use as drinking water, and collapse the box into a corner somewhere.
If the robot is capable of violating copyright by singing Styx's "Mr. Roboto", and Sony made it, aren't they responsible for creating a device which can be used to circumvent copyright?
NNTP *can* be P2P. It's been awhile (10 years?) since I've developed anything that groks NNTP, but trying grepping the RFC for "IHAVE" and "SENDME" and try disagreeing with me.
The ARP thing can be done by monitoring the dhcp CLIENT end of things. If the IP number changes, broadcast ping the subnet you're on now, and the one you just left. That's enough for more hardware out there to get it's head out of its ass and recognize your host, and it's reasonably efficient, too. (Two small ICMP packets per network change)
Slashdot Mirror
..a university professor who is ignorant of the real world. Never met one of those before...
...Museum of Modern Art sues Kodak (Camera)
...Addison-Wesley sues Xerox (Photocopier)
...Sony sues Bell ExpressVu (PVR)
This law is assinine. I wonder how long it is before the inventor of the floppy disk gets sue, lord knows I used them to pirate millions of games.
You can usually cut dead weight at a company pretty easily by organizing them in alphabetical order by title, and going down the list firing people until you have enough money to pay everybody else.
Chief comes before Programmer, Executive comes before Technical...
The target audience doesn't know anything more about ethernet except "Hmm, I can plug the phone modem cord into either hole, but the big fat cord from the cable modem only fits into this one, so it must go this way".
The technical support required to get something like this set up in an "Ethernet. Etherwhat? What's that?" environment would be costly, and make the product less attractive to users.
"What? Of course I have a switch! How the hell do you think I turn my lights on?"
"Hub? Don't you hubba-hubba me, buster, or I'll call the cops. Now tell me where to plug this fuckin' thing in!"
Think about it. This is NOT a toy marketed at geeks.
What is it with you guys, do you all work for Senator Disney? +2 interesting??? How about +3 funny!
The post is an obvious allusion to CD->MP3 recording combined with a healthy dose of tongue-in-cheek paranoia. It's a hell of a lot easier to tap somebody's PHONE and make calls than it is to tap an IP connection right now.
Seriously, you've described me to a tee.
At any rate, there's one thing you haven't tried. Code in a datacenter with non-cycling air conditioners (dress warm). It will help you achieve the final state of "the zone". After a few hours of this, when you stand up, you may be lost (i.e. not know where you are, which way to the door, etc) for several seconds. If so, you have achieved the final state of "The Zone".
I once pulled a 53 hour day like that, got up from my seat only three times. I did two months worth of work.
(Too bad I didn't get the next 58 days off!)
I don't know about your habit, but mine is up to about 1500 mg a day. If I go more than 10 hours without a cup, I get withdrawal headaches so bad I'd literally trade them for a good swift kick in the nuts.
If you're going to advocate quitting caffeine, the least you could do is suggest that the user get down to zero intake in 100 mg per day steps.
That sounds right (remember, it's been fifteen years!! :-)
Now that I think about it, it *should* work. The VIC reads/writes RAM, which IIRC is under ROM. Except for the character set, of course.
I was thinking that jumping the address bus decoders (74138s?) into the right "shape" for the 6502 to use the default config might screw with the VICs access to chipset select lines. IIRC, the VIC puts the 6510 to "sleep", diddles the CS/A lines, and tells the 6510 to wake up when its done. There must be another bit of glue logic on the board that we could mess with (maybe adding a gate or two) that would allow the VIC chip to do what it wanted to. Hmm.
Again, I wish I had the schematics in front of me, it's SOO hard to remember stuff that long gone by. Anybody know if they're available online anywhere?
The 1520 datasette isn't "intended to be sensitive within certain high frequencies" -- it's basically an on-off device. Is there sound? On. Is there no sound? Off.
:-)
The reason it sounded like high-frequency shrieking is because that's how your ears perceived the rapid transition from sound-to-no-sound.
Okay, so it sounds like we're talking about the same thing, but the subtle difference explains a lot.
The digitizer program you're talking about was published in Compute's Gazette, I believe. Basically, it sampled the data from the tape player as the tape moved over the head. If there was sound, it jotted down a one; if there was no sound, it jotted down a zero. So, we've got a _one_bit_sample_rate_ -- nothing to do with frequency ranges at all!
The faster you can sample (and the CPU limits that quite effectively!), the better resolution you can get, but it is still one-bit sound, so it'll still sound like crap.
The playback program used a bug in the 6561 SID chip to replay one bit sounds quickly. Transitioning the volume from min to max or back was a fast operation (STA, XOR, STA -- 8 cycles, maybe?) and produced a side-effect "click". Not all C=64s had this side effect though, so some people couldn't play the music! Hahahaha. You poor bastards with the C64cs!
You'd have to jumper the default memory mapping by hand, and not use any programs which make use of bank-switching code. (Whoops, there goes everything interesting).
The only concern I'd have is the VIC chip in that scenario; it might not be able to get at screen ram with the memory layout hard-coded.
Hmm, now where is my C64 PRG with the schematics at the back...
> Commodore was actually the first to mass-market
> a system based on that type of head & disk format
Bzzt! Wrong. As far as I know, IBM was, but not Commodore. While its true both systems used 5.25" double-density disks, IBM PC disks are MFM encoded; Commdore's disks are GCR encoded from the 4040 (late 70s) until the release of the 1571 (late 80s). The 1571 added an MFM encoding mode and double-sided capability in order to be compatible with CP/M disks for the CP/M mode of the C128. That was the first drive able to read PC floppies, although extra hacking was required.
The 4040 (cum 1530, 1540, 1541) disk format that we're all familiar with held 170K -- actually, 169984 bytes of data after formatting, arranged in 664 blocks of 256 bytes.
..howabout a glue trap?
:-)
1. Publish false mailto: addresses on your web pages in the same colour font as your background
2. Change them to visible, valid addresses by munging them with DHTML properties and a
JavaScript include file (sorry, Lynx users)
3. When a recognizable spam-bot comes in, refuse to load the javascript include file. mod_setenvif and mod_rewrite should help out here.
4. When a probable spam-bot comes in, serve up the page reaalllly slowly, don't close the connection until it goes in CLOSE_WAIT. This ties up sockets on the remote machine and reduces its ability to troll OTHER sites. You can do this by writing a handler for your base directory, checking the browser, and returning DECLINED for friendly people. That should be in, I think the "post read" phase.
5. When a recognized bad address comes through to your mail server (from step 1), slooooow the SMTP transaction down as much as you can (same idea as step 4), and throw an error at the end of the 354 DATA section a few times (to force him to come back!), etc. (Some sendmail internals hacking required here, although it would be much easier to hack if you don't have any real mail and just ran a script from inetd.)
6. Those fake email addresses. Make them all point to a common MX or group of MXes that you control the DNS for. Make sure those MX records aren't used by anything legitimate. Slooooow your in.named down for requests to that domain. A cool side effect, besides tying up sockets on the spammers end, IIRC some OSs can only make one resolver request at a time -- this'll effectively block all of his out outbound spam traffic while he's trying to look up your MX record! Also, make sure the TTL is set to about 10 seconds, just to make sure he comes back the glue trap very often.
How's *that* for spam countermeasures? I wish I had time to write it.
I'd wind up doing those changes myself whether I had a fancy content management system or not. If I had gotten one, I would have had to learn how to use it effectively, which probably would have taken a lot more time than banging out a few shell scripts.
;-). They're just happy because they got it for "free" (as in beer). So, it stops a WHOLE PILE of moronic requests, like...
But the BEST part: the execs understand that the CM is put together in shell, and that there is only so much it can do. (Well, that's what they think
..can you change the "alert" button to blue?
..can you write a cache of user data on the guy's harddrive?
..can't you just see if the guy's using netscape, and if he is, load the page in IE?
..can you change the brower's borders to match the site layout?
..can you make the confirm dialog box use Arial fonts?
..can you generate thumbnails for the mp3s?
(etc, ad nauseum)
> And how has your user community accepted this?
Happily! Before, we didn't have any content. Well, just a billion emails going everywhere and nobody knew what was going on. Of course, there was no budget for a CM system, so I "invented" one in my spare time that was put together with incredible speed.
> How much was invested for training?
Zero. Everybody who uses it also happens to be a unix systems programmer.
> How have you been finding it w.r.t. scalability and concurrent use?
Concurrent use problems were solved by doing all writes with a 10-line C program which blocks until it acquires an exclusive lock on the file.
("echo | copylock filename" instead of "echo >> filename")
Also, there are no "writes" to the data records, only appends. This happily also gets you a shell-parsable (while read line do eval blah done) revision model. Yay!
Reads never seemed to be an issue.
Scalability? Well, it scales big enough for what we do. A few hundred users, a little tiny overloaded linux box... It still works. If it ever stops working, then we'll "profile" the app (top) and move whatever pieces are sucking CPU into C.
The UNIX filesystem, though, seems to be a decent way to store data.
..is implemented with a magic program called, "bash" and few of its friends.
I can search by content (grep). I can search by date (find). I can filter to other types (sed). I can assign hiearchical meaning to records (mkdir).
I can even assign meaning by fields with the '=' operator, source the file with '.' and deference environment varibles!
Works great. I've implemented a change control system, a BBS (threads, fancy search engine, and all!), a user management system, a product management system and a bunch of other cool things with it.
Right now most of those systems support formatted plain text and html as output. But I could add an XYZ module with almost no effort.
So it's not secure. Nobody said anything about security.
Carp, actually, goldfish is a kind of carp.
I suppose now would be a good time to point out, however, that the only difference between carp and crap is a vowel movement.
Okay, so you take some fish up, and it gains in mass by 14%.
But, you also took up a bunch of cow abortions, which lost the equivalent mass, if not more.
So, where's the savings? Seems to be they'd be better off shipping up 14% more freeze-dried goldfish.
During launch, you put in a big box full of ice. After launch, you tie the fish to the outside of the spaceship (like beer, when ice fishing), melt the ice to use as drinking water, and collapse the box into a corner somewhere.
Seems pretty straightforward to me.
If the robot is capable of violating copyright by singing Styx's "Mr. Roboto", and Sony made it, aren't they responsible for creating a device which can be used to circumvent copyright?
Sick the DMCA on them, see how *they* like it.
NNTP *can* be P2P. It's been awhile (10 years?) since I've developed anything that groks NNTP, but trying grepping the RFC for "IHAVE" and "SENDME" and try disagreeing with me.
The ARP thing can be done by monitoring the dhcp CLIENT end of things. If the IP number changes, broadcast ping the subnet you're on now, and the one you just left. That's enough for more hardware out there to get it's head out of its ass and recognize your host, and it's reasonably efficient, too. (Two small ICMP packets per network change)
> It's very sad, but what can you do?
Legalize marijuana.
..until I poured hot grits down your pipe.
The sound card might offer reasonably sensitive voltage comparisons in the 1V range, but really wouldn't be an ideal way to go, IMHO.
:)
Looking at the game ports (two ADCs each) might be one option, and probably "safer". (Game boards are practically free).
Another might be look at the tape port. You have a true IBM-PC, don't you?
Think that would work?
> My old address was 1:2260/140 :) haven't typed that number in years.
Ditto! 1:249/128
But Usenet was around before FidoNet -- it just wasn't as available to the masses.
--