Even just to Canada. Dealing with imports via courier companies is a pain in the backside.
For starters, I can't have them delivered to the office because the mailroom won't be able to pay any import duties which may be owing. (If I know in advance, I can leave a cheque... but you don't find out what the duties are until they actually try to deliver.)
Making it worse, your company can set up a "special" broker for at least UPS, which can cost much, much more than UPS's already-overpriced brokerage service. (You never want UPS Economy or Ground for international; the extra cost for Express or Expedited is much lower than the brokerage fee for Economy/Ground.)
And, like in Europe, the Post Office is in everyone's neighbourhood. The couriers are not.
In a number of non-US jurisdictions, PayPal is regulated more like a bank.
But when it comes to international transactions, the choices in terms of increasing cost are: mailing cash, using a credit card (which only works with merchants), then using PayPal (which works with everyone). Then there's a big gap, and you get International Postal Money Orders. If you can find a Post Office at both sides that know what they are. Then there's an even bigger gap (in costs) and you can start talking about wire transfer service, or negotiating a cheque in a foreign currency, or all that sort of stuff.
Obviously, mailing cash has issues. But for, say, a $20AUD amount, I would have been happy to go to the money exchange here (Canada) and get a $20 Aussie bill and stick it in the mail. PayPal was the only other approach that had fees much lower than the transaction amount; a Money Order would have had a $5CDN handling charge, nearly 1/4 the amount of money.
For the wire transfer services that we could find, it was more like $40 or $60 handling.
Suddenly, PayPal's rates look really good.
If you are staying within a single currency, sure, there's more choices. But if you're going international, PayPal gets really good really fast.
If you've ever programmed on both NT and OS/2, and I mean really programmed, down to the level of what OS/2 called "Control Program", the similarity between NT and OS/2 is far more than striking.
All the subroutines in "Control Program" started with "Dos", as a primitive namespace set-up. All Dos* subroutines in OS/2 use a pass-by-name parameter to provide storage for the result of the subroutine, and the return from the subroutine is the error code. (So quite unlike the UNIX libc convention, for the most part.)
In NT, all the corresponding subroutines have had their "Dos" prefix removed (so "FindFirstFile" instead of "DosFindFirstFile"). But just to make porting really painful, on NT, most subroutines return the result, and you have to do a separate call to get the error code. (Much like UNIX libc and errno, only it's GetLastError().)
Which is really annoying: semantically, the two are close enough to equivalent that you want to #ifdef the differences. (But they're so different from UNIX, you don't try to mix the support code for the two.)
But syntactically, they're different enough that just about every single line needs to be #ifdef'ed.
And I really doubt that was by accident. Microsoft helped write OS/2, after all, and retained the rights to OS/2 V3 and up: which is why IBM's OS/2 Warp Connect was really 2.3 under the covers, and Warp 4 was 2.4 under the covers.
Doesn't Sandvine make the "deep packet inspection" equipment Bell Canada uses to throttle ALL GAS DSL connections, regardless of ISP, that are carrying BitTorrent traffic at certain times of day?
Given all the completely bogus "proof" of network congestion Bell provided to the regulator, I wouldn't believe a word out of Sandvine if they provide that equipment to Bell. They're part of the problem.
(Bell managed to prove that "congestion" was strictly limited in time and location, usually no more than a few minutes at a single node. But they react by throttling to 6% of GAS bandwidth limit--500 MB/s to 30/s MB.)
Oh gods, I hate those stupid portal systems so so so so so so so so so so much.
For starters, unless you only use the Web, you have no idea why you've got good Wi-Fi signal and yet nothing is working... because the stupid portal is hijacking all DNS to point to its "yes I know the Internet isn't controlled by Holiday Inn Express" page. And once you get that fixed, you still have to deal with clearing the resulting bogus crap from your DNS cache.
Then I can't figure out why the stupid thing kept timing out and having me have to re-authenticate. Maybe it's only kept alive by web traffic? What if I don't want to use the web?
Bah, if I wasn't on U.S. data roam, I'd have just tethered to the 3G network. There's something that just works... at least in my parts of Canada.
And that's something that hotels have to watch out for: if they make their service bad enough, we'll just use something else. Most people I know don't use the overpriced hotel long distance any more, they just use their cell. As soon as roaming data rates actually make sense, the demand for hotel Wi-Fi will disappear. (Like, the data is actually being sent up to Canada by the 3G network to get to the Big Bad Internet? If that's the case, then sure, the 1000x price for cellular data in the U.S., and 1000000x price in Europe... still doesn't make sense. But it's data--doesn't it hit the Internet locally? Just like my phone calls don't go up to Canada and then back down to the local number, it goes to the local phone system right away.)
I'd long wondered why it was taking them so long to put a genny in the trunk of an EV-1. Having to take the genny apart and wedge in a transmission connection to the drive wheels would certainly explain a couple of months delay.
Though I still don't understand why it is taking them so long....
And, with all that, the market is much, much, much larger. The Commodore 64, over the course of 12 years, sold 17 million units. The Nintendo Wii, over a mere 4 years, sold 74 million units. (And yes, I'm using the respective Wikipedia pages as source.)
Of course, some of those C64s were bought by schools and other places unlikely to buy lots of game titles. Although there's a few people messing around with Wiis in rehab, I expect you'll find most people who buy a Wii intend to play games on it. (Whereas, most people worked hard to convince their parents that the C64 was for school, not about the games, really mom, I can do my homework on it, I can learn to program... hey, wait, I actually did learn to program and do my homework on it! But I played lots of games, too.)
Heck, Apple sold nearly 3.5 million machines in the spring quarter this year (), a year's worth of sales is nearly the entire lifecycle of C64s.
So, you can get away with smaller mark-up, in real value, because you can sell more copies. And we all know about the real cost of making a copy....
I have it on reasonably good authority that you can make a brilliant bludgeoning weapon using only socks. Tube socks for preference, but any crew-high or longer athletic sock will do fine. Roll a bunch up really, really, really tight, stuff them in the toe of another sock, you don't even need to tie them in place if you're in a hurry.
Much like the rubber hose, you get "deep" damage, not surface damage. And unlike a length of rubber hose without fittings on it, you don't need plausible deniability: you're expected to have socks.
(I haven't tried this particular technique; though for people who know knots, a Monkey's Fist, even unloaded, can leave a bruise that lasts more than a week.)
Indeed; I've dealt with a small-office LAN that got kicked off Roger's Cable for having bots. The infected machines were the Macs, and the infection vector was a trojaned Adobe PhotoShop key-gen.
The annoying thing is, the people at Roger's could not give me any fingerprint information on the infection: they could not identify the remote port or remote IP that caused them to flag the connection and ultimately shut it down. So I had to block all the local machines (except the Linux fileserver) from the WAN via the DD-WRT router, have them re-activate the Cable connection, re-start local DNS, and sit on the router with tcpdump... as I brought one machine at a time back on-line (but not fully connected to the WAN).
I mean, it's do-able, but it would sure be a lot easier if I could have just run "tcpdump host badaddr and port badport".
Actually, it turns out I had caught the program with a "ps -fe" list before I had enough data from tcpdump--but at that point, I wasn't letting anything back on the 'net without a thorough inspection.
Probably paid more for me to do that than buying PhotoShop would have cost them. And they'll still ultimately have to pay for the missing licenses--so they're effectively paying twice by "waiting until we have more cash". Mind you, isn't that how a mortgage works?
By late in the 4.3 cycle, SMIT was getting pretty hairy with invoking shell functions. But it would still log the shell function itself, so you could find out the underlying command. Or read the script. And you didn't have to read the log file: one of the function keys (or ESC-number for TTYs) would bring up the command.
I'd often just run SMIT, bring up the command, read its man page, and then cancel out of SMIT and batch the command. (And/or update my master "new system configuration script". With that sucker and NIM, I could re-create any node in the test lab in about 10 minutes, completely unattended: it would wipe itself out, re-install, customize, and start the worker daemons and go multi-user all by itself. Happy admins never have to leave the keyboard when they don't want to.)
Anyway, earlier versions of AIX had simpler SMIT commands, so you usually would just find the raw command in the log. At least, 3.1 through 4.2--I never had the misfortune to admin the RT/PC or PS/2 versions.
(And by SMIT I mean SMITTY--the invocation that forces TTY use, even on an X11 display. The only problem was, in the ASCII interface, there was no SMIT man to fall on his face when the command failed. I mean if the command failed.)
IBM could have really nuked Sun out of the water, except they insisted that traditional UNIX "man" pages were a bad idea and you should use InfoExplorer instead. And they held off--and ultimately cancelled--the PowerPC-601-based PC that could run AIX, OS/2, Windows NT, and Solaris because OS/2 wasn't ready. But damn did that thing make a great low-end AIX node. Especially when you got 'em by the pallet from cancelled projects.
Basically, these days your best protection from IBM is IBM itself....
I'm driving a car with a new-to-me radio/cd-player that I had never used for radio. I see the big sign on the side of this messy junction among I-81, I-380, "to I-80" and "to I-84" and some local roads with the "EMERGENCY WHEN FLASHING TUNE TO AM xxxx" lights flashing. So I try and juggle the interchange and the radio and get it tuned to hear:
"Pennsylvania D-O-T welcomes travellers on this holiday weekend. Please drive with extra care. Traffic enforcement will be heightened for your safety. Enjoy the holiday."
In a similar vein, I long ago heard the story of the news agency that reported a company was "in the African-American" after their spell checker had made a replacement suggestion. I figured it was just an urban legend (after all, that would be a style checker, not spelling).
So a friend is registering blackSOMETHING.com at a well-known but somewhat annoying registrar. It comes up with the upsell list of suggested other domains to give them money for. At the end is:
It is possible to have a helmet speaker/microphone rig that ties in to your cellphone; wired or BlueTooth. (Mine's a mix: wired to my Zumo GPS, which then uses BlueTooth to talk to the phone.)
Then all you need to sort out is dialling; again, if you've got the right kind of GPS or a from-the-factory comm setup, it's not too hard. I wouldn't want to be in heavy traffic, but I'd be willing to hit "menu", "phone", "9", "1", "1" and "DIAL"--the Zumo is set up for left-hand use, so your right can stay on throttle and brake. Or take a chance with the stupid voice activated thing working for once.
Only thing is, the type of bikes that have those comm setups are heavy touring machines (ST1100/1300, Gold Wing, full dress Harleys, Concours, and so on) which are seldom found going more than 30% the posted limit.
Most alarm panels already have a battery backup built-in. It's the size you'd get in a 500VA UPS, an exit-sign-and-emergency-light, and so on: 7 amp-hours (or a bit more), lead-acid gel cell. APC RBC2 fits my alarm panel, which is handy when you have spare UPS batteries and your alarm battery decides it would rather be a heater than a power supply. (I did have to crimp on 1/4" terminals to replace the 3/16" ones used by the alarm battery.)
So as long as you're happy with the backup for the fibre-to-copper converter, you're done; the alarm doesn't power itself from the phone line.
You may find "electrocute" is from "electro-" and "execute".
That people now use it to mean a non-fatal shock is right up there with people using "literally" to mean "not literally". Or "bimonthly" meaning either twice a month ("semimonthly") or every two months ("bimonthly", archaic)....
Re:List geek cooking instructions here
on
Cooking For Geeks
·
· Score: 1
It's very likely his disk couldn't max out a SATA 150 connection. I don't think any 7200 RPM drives have a sustained transfer rate better than 145 MB/s; though I would be surprised if PCI could keep up--the three PCI + SATA configs I've used have choked the drives at about 50 MB/s. On an allegedly 32-bit 66 MHz PCI card. (The integrated SATA controller or a PCIe SAS controller can run them up to their 115 MB/s documented maximum at outer rim.)
So if your disk is slow enough that SATA 150 will do, the protocol overhead of running SCSI commands in a USB wrapper and the USB protocol overhead will kill the advantages. Fortunately, USB 3.0 finally gets full duplex transmission like FireWire and switched Ethernet.
However, if you have a whole bunch of those drives in a striping configuration, then you should see some benefit. Like I can get 680 MB/s from several my 115 MB/s drives with the SAS controller.
eSATA does do something akin to hubs; they're called "port multipliers". I've got a dual-disk eSATA box that has one integrated; you pop in two disks, plug in one eSATA cable, and the host sees two SATA endpoints on the far side of the multiplier. (This isn't the same as a true hardware RAID box; in that case, the RAID controller presents a single endpoint to the host and manages the disk array itself.)
They're readily available in a x5 configuration; I don't know why "5" seems to be such a magic number. You can get them standalone or in a multi-disk tower or....
They're fairly expensive compared to a USB hub or gigabit Ethernet switch.
Some people call the whole assembly the antenna; others mean just the feed antenna or feed horn. (On this sort, it is usually integrated with the low-noise block-converter, the LNB.) The reflecting (dish) part of the antenna system is not polarized, but the feed antenna usually is.
It's kind of like using single sideband to double the number of CB channels... only I can see wanting more satellite links, I don't know why you'd want more CB channels.
If you check, you'll find a good carpenter uses good tools, and more importantly, an appropriate one for the job.
You won't find a good carpenter putting a nail in with a circular saw. Or using a hammer to drive in a screw.
A good carpenter will be adaptable: if he needs to take a bit off the edge of a door, he'll be able to use a hand-plane, jointer, table saw, radial arm saw, belt sander, portable power planer, and so on.
But that's not the same as someone's dad handing them a metal-bodied electric drill with sparks coming out of the vents, setting sawdust on fire, and asking them to cut a straight line in a piece of plywood, telling them, "A good carpenter never blames his tools." A good carpenter doesn't get into that situation in the first place.
What they could do is, actually advertise the bit you said: '"you'll get the maximum speed your line will support, up to the theoretical maximum of 24 Mbps". xDSL is a 'best effort' service - you'll get whatever speed your modem can manage to squeeze out of your line and no more or less.'
Since they actually advertise the maximum speed as if everyone will get it, the "up to" part is in the fine print. Or when you phone up to order, they go on and on about how fast the lines are... the colour glossy brochures that they dump in your mailbox talk about the top speed... every time you hear from the ILEC ISPs you never hear or see "up to"... unless you get a stethoscope and magnifying glass out.
They also, or at least Bell Canada, charge you for the "up to" speed regardless of what you actually get. If I can't get 5/800, I can only get 3/512, why am I paying the 5/800 rates?
Well, actually, I'm not paying for any of that now, I'm paying the cable company. Only partly because of the crappy uplink on DSL; the other part is every time a truck rolled through my neighbourhood with Bell's logo on it, either the phone or the DSL would fail. Fixing one would, 1/2 the time, break the other.
Since 300 bps was also 300 baud, and the coding was very, very simple (four tones, one and zero for each of originate and answer), you could push it to 500 or 550 baud on a really clean line. Somewhere between 450 and 500 I started to need the pager to slow it down a bit... by 1200 bps, 'more' was mandatory.
Those were the days when, if you had an interactive 'chat' with someone, it was the sysop. 'Cause with only one phone line, the only other keyboard was the one on the PET running the 'board itself....
I started with direct-wire modems, but did use an acoustic-coupler device later, in 1990: it was the ordering terminal for a hardware store. You went around the store with this hand-held gizmo, typing in SKUs and quantities or scanning barcodes off the shelf stickers. Then, when you were ready for the weekly order, you strapped it to the telephone receiver and pressed the Big Order Button.
It was great; head office got electronic orders, and the Mom & Pop franchise stores didn't need to have a full-fledged computer terminal, modem and all the other stuff to go with it. The order pad would probably have been needed anyway, and so they just put everything in that.
A lot of people called "software engineers" have absolutely no background in engineering. They're really programmers who've had a chunk of program design dumped on them.
Engineering is all about what you can use, and how it can go wrong. If you've got an engineer who looks at you funny when you ask about "failure modes", you need a better engineer.
That being said, you'll probably have noticed a recurring theme is that the person who knows how something is supposed to work isn't very good at putting bad data into it. I've got a background in engineering and my first full-time job was in testing, and I'm fairly good at it; especially coming up with large swathes of "negative" tests (ones that should fail).
But, in general, the developer should show the code works. An independent test group, using the specs rather than the implementation, should try and make it fail.
Maybe that's the best advice I can give: you're trying to make it fail. If you're testing with a "this will work" mentality, you're looking at it the wrong way.
Nothing quite as much fun as looking at some ridiculous input that will never be valid in a million years and the program doesn't trap it... "why did that work?! what could it even _mean_?!"
Slashdot Mirror
Even just to Canada. Dealing with imports via courier companies is a pain in the backside.
For starters, I can't have them delivered to the office because the mailroom won't be able to pay any import duties which may be owing. (If I know in advance, I can leave a cheque... but you don't find out what the duties are until they actually try to deliver.)
Making it worse, your company can set up a "special" broker for at least UPS, which can cost much, much more than UPS's already-overpriced brokerage service. (You never want UPS Economy or Ground for international; the extra cost for Express or Expedited is much lower than the brokerage fee for Economy/Ground.)
And, like in Europe, the Post Office is in everyone's neighbourhood. The couriers are not.
Ah. I was a bit surprised to see this is a kdawson story for exactly that reason. Thanks.
Where's my bigger hammer?
In a number of non-US jurisdictions, PayPal is regulated more like a bank.
But when it comes to international transactions, the choices in terms of increasing cost are: mailing cash, using a credit card (which only works with merchants), then using PayPal (which works with everyone). Then there's a big gap, and you get International Postal Money Orders. If you can find a Post Office at both sides that know what they are. Then there's an even bigger gap (in costs) and you can start talking about wire transfer service, or negotiating a cheque in a foreign currency, or all that sort of stuff.
Obviously, mailing cash has issues. But for, say, a $20AUD amount, I would have been happy to go to the money exchange here (Canada) and get a $20 Aussie bill and stick it in the mail. PayPal was the only other approach that had fees much lower than the transaction amount; a Money Order would have had a $5CDN handling charge, nearly 1/4 the amount of money.
For the wire transfer services that we could find, it was more like $40 or $60 handling.
Suddenly, PayPal's rates look really good.
If you are staying within a single currency, sure, there's more choices. But if you're going international, PayPal gets really good really fast.
If you've ever programmed on both NT and OS/2, and I mean really programmed, down to the level of what OS/2 called "Control Program", the similarity between NT and OS/2 is far more than striking.
All the subroutines in "Control Program" started with "Dos", as a primitive namespace set-up. All Dos* subroutines in OS/2 use a pass-by-name parameter to provide storage for the result of the subroutine, and the return from the subroutine is the error code. (So quite unlike the UNIX libc convention, for the most part.)
In NT, all the corresponding subroutines have had their "Dos" prefix removed (so "FindFirstFile" instead of "DosFindFirstFile"). But just to make porting really painful, on NT, most subroutines return the result, and you have to do a separate call to get the error code. (Much like UNIX libc and errno, only it's GetLastError().)
Which is really annoying: semantically, the two are close enough to equivalent that you want to #ifdef the differences. (But they're so different from UNIX, you don't try to mix the support code for the two.)
But syntactically, they're different enough that just about every single line needs to be #ifdef'ed.
And I really doubt that was by accident. Microsoft helped write OS/2, after all, and retained the rights to OS/2 V3 and up: which is why IBM's OS/2 Warp Connect was really 2.3 under the covers, and Warp 4 was 2.4 under the covers.
And I saw it crash the other day! It actually worked, Flash crashed out and Safari kept going.
Then I told the guy who owned the computer about ClickToFlash.
Doesn't Sandvine make the "deep packet inspection" equipment Bell Canada uses to throttle ALL GAS DSL connections, regardless of ISP, that are carrying BitTorrent traffic at certain times of day?
Given all the completely bogus "proof" of network congestion Bell provided to the regulator, I wouldn't believe a word out of Sandvine if they provide that equipment to Bell. They're part of the problem.
(Bell managed to prove that "congestion" was strictly limited in time and location, usually no more than a few minutes at a single node. But they react by throttling to 6% of GAS bandwidth limit--500 MB/s to 30/s MB.)
Oh gods, I hate those stupid portal systems so so so so so so so so so so much.
For starters, unless you only use the Web, you have no idea why you've got good Wi-Fi signal and yet nothing is working... because the stupid portal is hijacking all DNS to point to its "yes I know the Internet isn't controlled by Holiday Inn Express" page. And once you get that fixed, you still have to deal with clearing the resulting bogus crap from your DNS cache.
Then I can't figure out why the stupid thing kept timing out and having me have to re-authenticate. Maybe it's only kept alive by web traffic? What if I don't want to use the web?
Bah, if I wasn't on U.S. data roam, I'd have just tethered to the 3G network. There's something that just works... at least in my parts of Canada.
And that's something that hotels have to watch out for: if they make their service bad enough, we'll just use something else. Most people I know don't use the overpriced hotel long distance any more, they just use their cell. As soon as roaming data rates actually make sense, the demand for hotel Wi-Fi will disappear. (Like, the data is actually being sent up to Canada by the 3G network to get to the Big Bad Internet? If that's the case, then sure, the 1000x price for cellular data in the U.S., and 1000000x price in Europe... still doesn't make sense. But it's data--doesn't it hit the Internet locally? Just like my phone calls don't go up to Canada and then back down to the local number, it goes to the local phone system right away.)
I'd long wondered why it was taking them so long to put a genny in the trunk of an EV-1. Having to take the genny apart and wedge in a transmission connection to the drive wheels would certainly explain a couple of months delay.
Though I still don't understand why it is taking them so long....
And, with all that, the market is much, much, much larger. The Commodore 64, over the course of 12 years, sold 17 million units. The Nintendo Wii, over a mere 4 years, sold 74 million units. (And yes, I'm using the respective Wikipedia pages as source.)
Of course, some of those C64s were bought by schools and other places unlikely to buy lots of game titles. Although there's a few people messing around with Wiis in rehab, I expect you'll find most people who buy a Wii intend to play games on it. (Whereas, most people worked hard to convince their parents that the C64 was for school, not about the games, really mom, I can do my homework on it, I can learn to program... hey, wait, I actually did learn to program and do my homework on it! But I played lots of games, too.)
Heck, Apple sold nearly 3.5 million machines in the spring quarter this year (), a year's worth of sales is nearly the entire lifecycle of C64s.
So, you can get away with smaller mark-up, in real value, because you can sell more copies. And we all know about the real cost of making a copy....
I have it on reasonably good authority that you can make a brilliant bludgeoning weapon using only socks. Tube socks for preference, but any crew-high or longer athletic sock will do fine. Roll a bunch up really, really, really tight, stuff them in the toe of another sock, you don't even need to tie them in place if you're in a hurry.
Much like the rubber hose, you get "deep" damage, not surface damage. And unlike a length of rubber hose without fittings on it, you don't need plausible deniability: you're expected to have socks.
(I haven't tried this particular technique; though for people who know knots, a Monkey's Fist, even unloaded, can leave a bruise that lasts more than a week.)
Indeed; I've dealt with a small-office LAN that got kicked off Roger's Cable for having bots. The infected machines were the Macs, and the infection vector was a trojaned Adobe PhotoShop key-gen.
The annoying thing is, the people at Roger's could not give me any fingerprint information on the infection: they could not identify the remote port or remote IP that caused them to flag the connection and ultimately shut it down. So I had to block all the local machines (except the Linux fileserver) from the WAN via the DD-WRT router, have them re-activate the Cable connection, re-start local DNS, and sit on the router with tcpdump... as I brought one machine at a time back on-line (but not fully connected to the WAN).
I mean, it's do-able, but it would sure be a lot easier if I could have just run "tcpdump host badaddr and port badport".
Actually, it turns out I had caught the program with a "ps -fe" list before I had enough data from tcpdump--but at that point, I wasn't letting anything back on the 'net without a thorough inspection.
Probably paid more for me to do that than buying PhotoShop would have cost them. And they'll still ultimately have to pay for the missing licenses--so they're effectively paying twice by "waiting until we have more cash". Mind you, isn't that how a mortgage works?
By late in the 4.3 cycle, SMIT was getting pretty hairy with invoking shell functions. But it would still log the shell function itself, so you could find out the underlying command. Or read the script. And you didn't have to read the log file: one of the function keys (or ESC-number for TTYs) would bring up the command.
I'd often just run SMIT, bring up the command, read its man page, and then cancel out of SMIT and batch the command. (And/or update my master "new system configuration script". With that sucker and NIM, I could re-create any node in the test lab in about 10 minutes, completely unattended: it would wipe itself out, re-install, customize, and start the worker daemons and go multi-user all by itself. Happy admins never have to leave the keyboard when they don't want to.)
Anyway, earlier versions of AIX had simpler SMIT commands, so you usually would just find the raw command in the log. At least, 3.1 through 4.2--I never had the misfortune to admin the RT/PC or PS/2 versions.
(And by SMIT I mean SMITTY--the invocation that forces TTY use, even on an X11 display. The only problem was, in the ASCII interface, there was no SMIT man to fall on his face when the command failed. I mean if the command failed.)
IBM could have really nuked Sun out of the water, except they insisted that traditional UNIX "man" pages were a bad idea and you should use InfoExplorer instead. And they held off--and ultimately cancelled--the PowerPC-601-based PC that could run AIX, OS/2, Windows NT, and Solaris because OS/2 wasn't ready. But damn did that thing make a great low-end AIX node. Especially when you got 'em by the pallet from cancelled projects.
Basically, these days your best protection from IBM is IBM itself....
I've got a good one for distraction.
I'm driving a car with a new-to-me radio/cd-player that I had never used for radio. I see the big sign on the side of this messy junction among I-81, I-380, "to I-80" and "to I-84" and some local roads with the "EMERGENCY WHEN FLASHING TUNE TO AM xxxx" lights flashing. So I try and juggle the interchange and the radio and get it tuned to hear:
"Pennsylvania D-O-T welcomes travellers on this holiday weekend. Please drive with extra care. Traffic enforcement will be heightened for your safety. Enjoy the holiday."
Some emergency.
In a similar vein, I long ago heard the story of the news agency that reported a company was "in the African-American" after their spell checker had made a replacement suggestion. I figured it was just an urban legend (after all, that would be a style checker, not spelling).
So a friend is registering blackSOMETHING.com at a well-known but somewhat annoying registrar. It comes up with the upsell list of suggested other domains to give them money for. At the end is:
africanSOMETHING.com
africanamericanSOMETHING.com
africancanadianSOMETHING.com
caribbeanSOMETHING.com
I could barely stop laughing long enough to say, "I didn't know that really happened!"
It is possible to have a helmet speaker/microphone rig that ties in to your cellphone; wired or BlueTooth. (Mine's a mix: wired to my Zumo GPS, which then uses BlueTooth to talk to the phone.)
Then all you need to sort out is dialling; again, if you've got the right kind of GPS or a from-the-factory comm setup, it's not too hard. I wouldn't want to be in heavy traffic, but I'd be willing to hit "menu", "phone", "9", "1", "1" and "DIAL"--the Zumo is set up for left-hand use, so your right can stay on throttle and brake. Or take a chance with the stupid voice activated thing working for once.
Only thing is, the type of bikes that have those comm setups are heavy touring machines (ST1100/1300, Gold Wing, full dress Harleys, Concours, and so on) which are seldom found going more than 30% the posted limit.
Most alarm panels already have a battery backup built-in. It's the size you'd get in a 500VA UPS, an exit-sign-and-emergency-light, and so on: 7 amp-hours (or a bit more), lead-acid gel cell. APC RBC2 fits my alarm panel, which is handy when you have spare UPS batteries and your alarm battery decides it would rather be a heater than a power supply. (I did have to crimp on 1/4" terminals to replace the 3/16" ones used by the alarm battery.)
So as long as you're happy with the backup for the fibre-to-copper converter, you're done; the alarm doesn't power itself from the phone line.
You may find "electrocute" is from "electro-" and "execute".
That people now use it to mean a non-fatal shock is right up there with people using "literally" to mean "not literally". Or "bimonthly" meaning either twice a month ("semimonthly") or every two months ("bimonthly", archaic)....
exec >> plate /dev/boiler - | filter > carafe
( bake --temp 400 --time 20:00 < bacon; ) &
( repeat 2 slice bread | { sleep $((18*60)) && toaster --doneness=dark; } ) &
( sleep $((18*60)) && dd if=/dev/fridge/eggs | fry --style=over-easy ) &
dd if=/dev/cupboard/coffee bs=tbsp count=6 | grind --size=extra-fine | cat
dd if=/dev/fridge/orange-juice bs=250mL count=1 > glass
Sadly, I do have the times down so that the toaster pops as the bacon is ready and the eggs are just coming out of the pan....
The cronjob that roasts coffee is left as an exercise for the student. So is the demand-loaded job to make a new batch of OJ.
It's very likely his disk couldn't max out a SATA 150 connection. I don't think any 7200 RPM drives have a sustained transfer rate better than 145 MB/s; though I would be surprised if PCI could keep up--the three PCI + SATA configs I've used have choked the drives at about 50 MB/s. On an allegedly 32-bit 66 MHz PCI card. (The integrated SATA controller or a PCIe SAS controller can run them up to their 115 MB/s documented maximum at outer rim.)
So if your disk is slow enough that SATA 150 will do, the protocol overhead of running SCSI commands in a USB wrapper and the USB protocol overhead will kill the advantages. Fortunately, USB 3.0 finally gets full duplex transmission like FireWire and switched Ethernet.
However, if you have a whole bunch of those drives in a striping configuration, then you should see some benefit. Like I can get 680 MB/s from several my 115 MB/s drives with the SAS controller.
eSATA does do something akin to hubs; they're called "port multipliers". I've got a dual-disk eSATA box that has one integrated; you pop in two disks, plug in one eSATA cable, and the host sees two SATA endpoints on the far side of the multiplier. (This isn't the same as a true hardware RAID box; in that case, the RAID controller presents a single endpoint to the host and manages the disk array itself.)
They're readily available in a x5 configuration; I don't know why "5" seems to be such a magic number. You can get them standalone or in a multi-disk tower or ....
They're fairly expensive compared to a USB hub or gigabit Ethernet switch.
Some people call the whole assembly the antenna; others mean just the feed antenna or feed horn. (On this sort, it is usually integrated with the low-noise block-converter, the LNB.) The reflecting (dish) part of the antenna system is not polarized, but the feed antenna usually is.
It's kind of like using single sideband to double the number of CB channels... only I can see wanting more satellite links, I don't know why you'd want more CB channels.
If you check, you'll find a good carpenter uses good tools, and more importantly, an appropriate one for the job.
You won't find a good carpenter putting a nail in with a circular saw. Or using a hammer to drive in a screw.
A good carpenter will be adaptable: if he needs to take a bit off the edge of a door, he'll be able to use a hand-plane, jointer, table saw, radial arm saw, belt sander, portable power planer, and so on.
But that's not the same as someone's dad handing them a metal-bodied electric drill with sparks coming out of the vents, setting sawdust on fire, and asking them to cut a straight line in a piece of plywood, telling them, "A good carpenter never blames his tools." A good carpenter doesn't get into that situation in the first place.
What they could do is, actually advertise the bit you said: '"you'll get the maximum speed your line will support, up to the theoretical maximum of 24 Mbps". xDSL is a 'best effort' service - you'll get whatever speed your modem can manage to squeeze out of your line and no more or less.'
Since they actually advertise the maximum speed as if everyone will get it, the "up to" part is in the fine print. Or when you phone up to order, they go on and on about how fast the lines are... the colour glossy brochures that they dump in your mailbox talk about the top speed... every time you hear from the ILEC ISPs you never hear or see "up to"... unless you get a stethoscope and magnifying glass out.
They also, or at least Bell Canada, charge you for the "up to" speed regardless of what you actually get. If I can't get 5/800, I can only get 3/512, why am I paying the 5/800 rates?
Well, actually, I'm not paying for any of that now, I'm paying the cable company. Only partly because of the crappy uplink on DSL; the other part is every time a truck rolled through my neighbourhood with Bell's logo on it, either the phone or the DSL would fail. Fixing one would, 1/2 the time, break the other.
Since 300 bps was also 300 baud, and the coding was very, very simple (four tones, one and zero for each of originate and answer), you could push it to 500 or 550 baud on a really clean line. Somewhere between 450 and 500 I started to need the pager to slow it down a bit... by 1200 bps, 'more' was mandatory.
Those were the days when, if you had an interactive 'chat' with someone, it was the sysop. 'Cause with only one phone line, the only other keyboard was the one on the PET running the 'board itself....
I started with direct-wire modems, but did use an acoustic-coupler device later, in 1990: it was the ordering terminal for a hardware store. You went around the store with this hand-held gizmo, typing in SKUs and quantities or scanning barcodes off the shelf stickers. Then, when you were ready for the weekly order, you strapped it to the telephone receiver and pressed the Big Order Button.
It was great; head office got electronic orders, and the Mom & Pop franchise stores didn't need to have a full-fledged computer terminal, modem and all the other stuff to go with it. The order pad would probably have been needed anyway, and so they just put everything in that.
A lot of people called "software engineers" have absolutely no background in engineering. They're really programmers who've had a chunk of program design dumped on them.
Engineering is all about what you can use, and how it can go wrong. If you've got an engineer who looks at you funny when you ask about "failure modes", you need a better engineer.
That being said, you'll probably have noticed a recurring theme is that the person who knows how something is supposed to work isn't very good at putting bad data into it. I've got a background in engineering and my first full-time job was in testing, and I'm fairly good at it; especially coming up with large swathes of "negative" tests (ones that should fail).
But, in general, the developer should show the code works. An independent test group, using the specs rather than the implementation, should try and make it fail.
Maybe that's the best advice I can give: you're trying to make it fail. If you're testing with a "this will work" mentality, you're looking at it the wrong way.
Nothing quite as much fun as looking at some ridiculous input that will never be valid in a million years and the program doesn't trap it... "why did that work?! what could it even _mean_?!"