The deal is that Compaq reversed engineered IBM's BIOS -- the only part of the design that was a trade secret. Everything else with the PC was very well documented and easily reproduced. The BIOS calls were already well documented. All Compaq needed to do was come up with a fully compatible BIOS without using IBM's code. Compaq came up with workalike BIOS using clean room techniques (or was it Phoenix technologies or some other shop -- I don't remember). I'm sure IBM fought tooth and nail, but they obviously weren't successful.
As for Apple vs. Psystar, it's quite different, the issue is that Psystar is violating Apple's software license agreement (that the OSX software will only be used on Apple-branded hardware). There are software checks in OSX to verify the hardware is Apple's, which means that Psystar would have to patch OSX to bypass those checks, and then distribute the modified code as their own OS.
Had Psystar somehow reverse engineered OSX with clean-room techniques to produce their own fully compatible workalike, this might be a very different case.
Also, copyright laws have changed quite a bit since 1981. I don't know if Compaq would have been able to legally clone the PC with today's laws.
It's one thing to write code that follows a sequence of steps and generates correct output. It's quite another thing to write robust code that handles problems gracefully.
In the real world, problems are inevitable. For example:
Database servers might be offline or unreachable (or misconfigured)
Resource exhaustion issues (e.g. no free memory, filesystem full, etc)
Network issues (e.g. cannot connect to remote server, DNS failure, web services, etc). Data transfers could be unexpectedly slow.
Your output file might already exist from a previous run of the program
Your configuration file might be invalid or incomplete (BTW: configuration files names don't end with.cpp... )
Your user might interrupt the program in the middle of a run, after it's created a partial output file (because it looked like it was stuck)
Your user might run two instances of the program at the same time. Will they coexist peacefully, especially if they have to share data or resources?
As you design and write your code, try to anticipate the problems you'll have to deal with, and the things that could go wrong. Be religious about error checking and handling -- sure, it's tedious, but it makes your software dependable and easier to support once it hits production. Unless you like 3AM wakeup calls from the guys in network.
You may not be able to recover or work around all problems, but your code should at least handle them gracefully--even if that simply means cleaning up, logging an error, and alerting the operator for further troubleshooting.
Sure, Hayes technically owned the AT command set, but it was not a trade secret -- it was widely emulated by other modem manufacturers, and became a de-facto standard. I'm a little fuzzy here -- did Hayes actually try to keep other manufacturers from using it?
Similarly, most dot matrix printers were Epson compatible, and laser printers were typically LaserJet II compatible or Apple Laserwriter compatible (e.g. postscript). That didn't give you access to all of the extra features of a particular printer, but it did mean your printer would be functional / useful with the software you already owned.
I don't remember serial / printer cables being different, at least for standard peripherals like parallel printers or serial modems. I remember HP had their own serial plotter cables (which made supporting AutoCAD lots of fun). Sometimes, cables and hardware would play fast and loose with the hardware flow control signals, or by hard-wiring pins together (e.g. DTR/DSR, CTS/RTS, etc). But generally, hardware was well-behaved enough that you could get it working.
It has not always been a myth. Sure, there may be no such thing as perfectly interchangeable hardware, but most hardware used to adhere to well-known standard interfaces.
Modems all supported RS-232 serial ports, and nearly all used the AT command set. Internal modems had no physical RS-232 port, but to rest of the computer, they looked like a serial port and still presented the same AT command interface. There were no "drivers" to speak of.
Sure, some modems added extensions / features, but as long as you stuck to the core AT commands (e.g. ATH, ATD, ATA, etc), the modem would work the same predictable way regardless of who made it or whether it was internal/external. You were free to choose your terminal software... hardware... operating system... even serial port hardware... the list goes on.
What was really nice about generic hardware was that it worked in a well-known, predictable way. If you were so inclined, you could write your own terminal software, operating system... even create your own hardware if you wanted. The information you needed to get everything working--UART documentation, AT command set, BIOS calls, X86 instruction set, etc... was widely available. The only limits in your way were the limits of your own ability to figure everything out.
You mention the C64 and its own proprietary modems. In fact, the user port on the C64 was RS-232 compatible, the main difference being voltage levels. Many companies designed RS-232 interface kits for the C64 allowing you to connect any standard modem you wanted. The specs for the user port were published in the Commodore 64 programmer's reference manual. If you were so inclined, you could actually build your own RS-232 interface from parts available at the electronics store.
With Windows-specific hardware, we no longer have that freedom. We've lost something -- Now, even if we want to write our own software stack or implement our own hardware, we're stuck -- the information needed to make the hardware work is hidden, locked away in a binary driver that only works on one platform. The only way to make it work elsewhere (e.g. Linux) is to reverse engineer the product -- much more difficult that working against an open spec.
Why do I have to reverse engineer my own hardware if it supposedly adheres to a published / well known specification?
A while ago, our company ordered an upgraded protocol license for some Intel telecommunications gear.
A few days later, a big box shows up -- I think a 2 x 2 x 2 foot cube. In that box was a wad of packing peanuts, as well as a padded envelope...
When we opened the envelope, we expected to find a license button, which would be physically installed in our equipment. There would be no reason to ship that in a large box, but at least a license button would have been some tangible product that justified shipping.
Alas, the envelope contained no license button after all. Instead, it contained a single sheet of paper complete with instructions on how to access a web site, and a validation code to use. That validation code would then give us an actual license key, which we could then enter into our equipment to unlock the extra protocol features (that were already built in to the equipment).
I can't quite put my finger on it, but something seems a little wasteful here... I'm *sure* if somebody thought hard about this, they could probably find a way to do the whole thing electronically...
I think if you went to the average person who uses text messaging heavily, they would say they're paying for the ability to send text messages to their friends when they can't make a phone call. They don't really care how it works or how the network is (mis)engineered. -- they just care that it does. If they're happy paying $.10 per message (or $10.00 / month for unlimited), then they'll subscribe to SMS and the telco will be happy to take their money.
As for being badly engineered, nobody expected SMS volume to grow like it has. SMS was originally expected to be a way to send programming updates to handsets via "spare" bandwidth on the network. While it was also possible to send regular text messages via SMS, it really didn't get much attention until just a few years ago. Once people discovered SMS, the usage took off beyond the wildest dreams of the carriers (both in terms of profit and also impact). It's difficult to keep engineering for 30 - 50% per year growth in volume without spending a lot of money in hardware / network upgrades.
As for a better protocol that may one day deprecate SMS -- I guarantee that carriers are looking for one that scales better, without impacting battery life (you probably can't keep the phone continuously connected to an IM server via the data network, or you'll drain the battery in an hour). That's a solvable problem though, once the carriers and handset manufacturers can all agree on the solution. I expect the end result it will look something like a cross between SMS and IM.
Don't expect that to happen quickly, as people will need new handsets for that to work -- and most people don't upgrade phones that often. Even when it does, as long as the carriers control the network or the devices that communicate with it, they'll find a way to bill for you using it, in a way that maximizes their profit.
The bottom line is this -- carriers are looking for ways to bill you as much as possible without you complaining or dropping service. Services and add-on features are the means by which they justify this billing. They're not holding a gun to your head though -- if you don't want the service, have them remove it from your account, or don't use it. But with SMS, lots of people use it happily, and some quite heavily. They wouldn't be doing so if they truly felt it was a ripoff.
Considering the cost of SMS, keep in mind there's much more to SMS than just transporting the bytes of text. One of the things you're overlooking is the store/forward nature of SMS (for reliable delivery), as well as the per-message transactional overhead.
With a voice call, most of the work is in setting up the connection to the person you're calling. Once that connection is established, essentially you're streaming 8K per second of data (64 kilobits / sec). None of that data gets stored anywhere for later retransmission -- the network really needs to do nothing beyond act as a pipe.
With SMS, your message gets stored in a queue so that it can be sent to your recipient if they're not available. This message queue needs to be able to handle many thousands of transactions per second -- if done incorrectly, this can cause a significant bottleneck. You might not notice if 160 bytes worth of voice data get scrambled, but a missed SMS message might cause you significant problems. If your phone is turned off, you miss your calls -- maybe you'll get a voicemail. With SMS, you'll get your message when you turn the phone back on.
The per-message transactional overhead can be quite substantial. The carrier has to generate billing events for sending / receiving messages. They may need to query or debit a prepaid system. They may have per-subscriber whitelist / blacklist rules which need to be applied to every message. All of these systems cost money to purchase and maintain. These also apply to voice calls, but in that case, those costs are covered either by your flat-rate local service charge, or by your per-minute long distance charges.
One other thing is that delivering SMS messages does actually cause quite an engineering problem for cell providers. SMS messages are typically delivered via the overhead control channel, which is the same channel used to do call setup/teardown, handoffs between cell sites, and other tasks. The overhead control channel is typically limited in capacity, and many carriers have engineered enough capacity for regular call activity. SMS has exploded in growth over the past few years, to the point that it is exhausting this overhead control channel for some carriers. Carriers have to spend considerable effort to reengineer their networks, so that they are able to keep up with both SMS traffic as well as regular call handling traffic.
The bottom line is that SMS is not a data transport -- SMS is a communication medium, an alternative to a voice call or email. People often send an SMS when a voice call would be inappropriate -- for example, in church, in class, at dinner, etc. The value of SMS isn't in the transport of the bits/bytes, but in conveying a message without having to talk, and without needing to be next to a computer. As for comparing it to a data transport, nobody sends files via SMS. It would be far too slow and expensive.
I agree that 10 cents / message is a little steep, but then, I've paid for a bundle to control costs. Most carriers offer unlimited SMS plans for reasonable prices, or smaller bundles at lower rates. Even though carriers are making money hand over fist for SMS, usage continues to grow exponentially. Even if you consider it a ripoff, there are millions of active SMS users who don't. If you don't want to pay for it, don't use it.:)
Sometimes, you really do inherit sloppy code... stuff that doesn't anticipate failures, or attempt any kind of error handling or recovery.
Sometimes, the code wasn't written with the mindset of how things *should* be done. Sometimes, the code was hurriedly slapped together by somebody who didn't anticipate the ways that things could fail (e.g. malloc() failure, disk full, database connection failure, etc). Sometimes, it's code that was written poorly because the developer didn't know of a nice standard best-practices way to do it, didn't care to figure it out, or dismissed it out of hand because they didn't get it.
Other times, you run into code where the developer gets fancy in an attempt to shave every last cycle out of their code (especially when the application isn't even CPU bound to begin with). Sometimes, developers like to do it the hard way just to show off how smart they are.
Finally, sometimes the code you inherit is truly spaghetti code. Some of my favorites:
dead code that is never executed
while() loops that can become endless loops in non-obvious ways
function calls that take 15 arguments
function calls that nest 15 layers deep, and require you to hunt through source code scattered all over the filesystem (e.g./usr/include/my_code/object_list.c)
To go with the above, using #include to reference functions in another C file (e.g. #include "object_list.c"
unnecessarily cryptic variable names
using macros excessively, especially when the macro definition is more complex than the code it replaces.
I bought an unlocked Nokia E70 a while ago, and have no trouble using it with the AT&T GPRS/EDGE network.
The phone does have to be set up with the appropriate settings to 'log on' to their network though. At least with Nokia, I was able to get the settings sent to my phone over the air from Nokia's website--they had settings for a wide range of models and carriers. You might even be able to do the same directly from the AT&T website as well.
In fact, a few months ago, my wife and I bought a MacBook at an Apple store. My wife asked about upgrading it to 2G of RAM.
The salesperson told us they could do it in store, or we could do it ourselves. Sure, she would have been happy to sell us the RAM and service, but mostly she was happy to sell us a laptop.
At no point did she try to pressure or scare us into paying to have an Apple Genius install Apple-branded RAM. In fact, she even referred us to Crucial.com and PNY.com, going as far as showing how to use their online configurator.
There was actually quite a bit more to Logo than just the familiar turtle graphics. While I haven't played with Logo in a long time, I remember it was quite easy to write structured programs. You could define primitives (essentially subroutines), read/write files, handle I/O, etc. I think everything was in place to write some fairly sophisticated software without ever involving the turtle.
IMHO the turtle is really more of the friendly face, to make Logo fun for beginners (e.g. look at the pretty designs you can draw, and look how easy it is to build more complex images out of very simple, reusable building blocks).
At the time, BASIC made it very easy to write spaghetti code, especially with its use of line numbers rather than labels. The more GOTO and GOSUB statements you had, the harder it became to manage--changing line numbers could unleash a horde of broken GOTO statements.
IMHO, I think Logo doesn't get enough credit for what it truly was.
This has nothing to do with the iPhone, and everything to do with me not having the international calling plan.
For me as a fairly light user, it doesn't make sense to pay for a $75 / month international data roaming plan. Even the extra cost of an international plan would be a waste for me. I've been overseas one week in the past three years, and that was while on vacation. The only reason for having the phone was for emergency use (and occasionally texting my wife when she went off shopping). It would have cost us more to have the international plan than it ever would have saved us.
If I need data access while overseas, it's for work, and therefore it's on the company's dime.
From what I understand though, it has everything to do with the European carriers charging outrageous roaming rates.
The other thing I read is that if you don't answer a call and let it ring through to voicemail, you actually get nailed for double the airtime charge, as it becomes two calls. The first call is from the caller to whichever switch you're roaming on. The second call is set up from the serving switch, all the way back to your home voicemail platform. Can somebody confirm if this is true? It sounds like quite a ripoff! And quite a neat way to run up somebody else's cell phone bill...
In fact, I'm even told that if your phone rings for an incoming call, that's enough for you to get roaming charges (even if you don't answer it). Supposedly you can avoid that by forwarding incoming calls directly to voicemail.
BTW, you don't want to roam internationally, at least, not without an expense account.
I remember one year I took a week's vacation in Ireland, and took my GSM phone with me. One day I was walking back to the hotel and the phone rang -- one of our customers was calling me directly, rather than use our central tech support line. It's bad enough to take direct customer calls on your personal cell phone (because the customer hasn't updated their contact info). It's even worse when that happens while you're roaming internationally.
The upshot is that I answered reflexively, before I realized what the call was going to cost. I hung up immediately as soon as I made that realization--the call must have been less than a second or two. That was still good enough to bill for a complete call, rounded up to a minute of airtime.
That second or two of airtime cost me $3.00 on my bill.
Game Console or PC, a DVD Drive is still a DVD drive with a different face plate. Especially since they sold me the hardware below cost, I'm willing to cut them some slack.
Why? You paid $300+ for it. Who cares what it cost *them*? If they sold it to you below cost, why does that entitle them to any more leniency on your part? Are they doing you a favor that way, or does the low cost mean that you owe *them* a favor?
Would you be harder on them if it only cost them $100 to make the 360?
Also many rural areas aren't served by cable. They're very prone to outages due to downed lines (cable) or rain (satellite) too. Not fun if you're in the middle of tornado alley and all satellite and cable goes down for the community because of wind or rain from the approaching line of thunderstorms.
I don't live in tornado alley, but rather on the gulf coast of Florida. Needless to say, hurricanes are a fact of life for us. I can relate to this concern.
During a hurricane, it's very important to keep up with fast-changing weather updates. For example, during Hurricane Charley, the storm made a sudden transition from category 2 to category 4 strength, plus took a jog in our direction. What was going to be a non-event for us very quickly turned into a direct threat to our safety. Thanks to the local news broadcast, we were able to keep up to date with the storm's progress.
I should point out that in a hurricane, you can pretty much count on losing power, cable, phone and of course satellite. The only way to watch the weather radar is by a battery powered TV, picking up a local broadcast.
Until handheld digital TVs are readily available and affordable, the converter boxes will be of limited use to me during a hurricane. If I'm huddled away under the stairs without power, will I need to plug the converter box into a UPS so I can watch the local weather broadcast on a portable TV?
Will digital TVs be affordable enough that a typical Florida retiree on a fixed income can afford to buy one?
Electricity generation via fossil fuels may generate pollution, but consider:
The centralized power plant can be specially tuned to run at a constant speed with optimum efficiency, since the workload is very different from that faced by an automotive engine (e.g. stop/go traffic).
By running constantly, the centralized powerplant is able to avoid the emissions generated at engine startup, when the catalytic converter hasn't heated up yet
A central power plant is likely to be much better maintained than most car engines. That also goes for the emissions control equipment. Fluid leaks are more likely to be properly contained and addressed promptly.
The centralized power plant does not *have* to be driven by fossil fuels. Nuclear power is very viable. Localized solar panels may become an option too, as price / performance improves
Don't forget to consider the fuel used to truck gasoline to your local gas station, as well as the resulting emissions from that truck.
Wow... I stand corrected on the nesting... Since I'm primarily a C developer (and only dabble in HTML) I just assumed HTML was as strict as C. You learn something new every day:)
I didn't realize HTML was somewhat lenient about nesting elements. There must be situations where HTML requires strict nesting (e.g. tables, lists, frames). Is there anywhere I can go to get a good answer? Is this part of the original design for HTML, or is this a real-world concession, given the number of broken authoring tools and browsers?
I can see this would be helpful for basic character formatting, esp if you think of the tags as on/off tokens, rather than nested blocks.
<ul> means underline ON, </ul> means underline OFF.
It would reduce the amount of HTML code needed for something like this:
<ul>underline this <b>this is bold *and* underlined</ul> this is only bold</b>.
With strict nesting, it would look like:
<ul>underline this <b>this is bold *and* underlined</b></ul><b>this is only bold</b>.
From what I understand, XHTML is absolutely strict about nesting. Personally, I prefer that approach, but that's because I'm a developer that has to do that daily--how hard is it to get the nesting right anyway?
Actually, it's not a terrible idea at all. It removes syntax ambiguity, which makes it much easier to parse the code. By having tag-specific closing tags, HTML makes it possible for a web developer to get the nesting wrong. This leaves it up to the browser to either send an error to the user (not the developer!) or silently try to get it right in a browser-specific way. If browser 'A' sends an error but browser 'B' makes a sensible guess, which one do you think the user will use (and what incentive is there for the developer to actually fix their code?)
Using universal closing tags forces the developer / authoring tool to properly nest tags. The result is that the web browser doesn't have to guess when it sees improperly nested tags--in turn this makes page rendering much more consistent between browsers. This also removes the need for workaround kludges for various HTML quirks.
Universal closing tags are nothing new -- The C language and many others use the same curly braces to open/close a code block.
For example:
if (x) {......}
while (x) {.... }
for (;;) {....}
if (x) { while (x) {.....} }
You can easily nest 'if', 'while' and 'for' blocks. The compiler has no problem figuring out which block should be closed when it sees a '}'.
By making the close tag universal, you make it impossible to get the nesting syntax wrong. Sure, a developer might still get the nesting *logic* wrong, but IMHO it's better to have a human developer fix this rather than have the browser or compiler try to guess.
A coworker and I walked over to the local EBGames about 15 minutes before they opened. There were three people in line before us. About 10 - 15 showed up after us (right before the store opened at 10:00). There was one family that had been there since before 8:00 AM, but I saw no tents or sleeping bags:)
Neither of us had a problem getting a reservation. I don't know what the store's allocation was, so I don't know how many people were disappointed. Alas, we both had to get back to actual work:)
I was most impressed with how orderly the line was--there was an unspoken agreement that everybody would line up single file, and first-come-first-served.
Many years ago, I got hoodwinked / pressured into signing up for the credit card "payment protector" plan. Essentially, they would bill me 1% of the previous month's balance for the program, and charge that to my card.
So after a few months of not using the card, I finally charged $169 to it and promptly paid it off. I got a bill in the mail the next month for $1.69, charged to my card. That was entirely 'payment protector premium. I was a bit steamed, but I paid that off anyway......the *NEXT* month, I get a bill for $0.02... the payment protector premium for the previous month's bill of $1.69. It's bad enough that they charged me a premium to protect the previous month's premium... but then on top of it they actually paid postage to mail out a bill for $0.02. Highly cost-effective:)
I proudly paid the $0.02 at an ATM, and then gave their customer service department a call. They took me off the program without any problem, and even paid me back the $1.71 I'd paid in premiums.
Each pound of paper that goes into landfills and which does not degrade is three pounds of carbon dioxide that had been taken out of the atmosphere.
So in fact, it's actually a good thing that the paper doesn't degrade in landfills. Think of paper as basically one giant sheet of carbon dioxide in a fixated form. Essentially, making paper is really just one of the steps in removing carbon dioxide from the atmosphere. You see, paper comes from trees, and trees grow by using atmospheric carbon dioxide (and water and sunlight). Essentially, trees act as carbon dioxide sponges, cleansing the air. Just like sponges, eventually they get saturated and lose their cleaning power. So, what you do is you make paper out of the trees, then you bury the paper. since the paper never degrades, the carbon dioxide is never released back to the atmosphere. You also plant new trees in place of the old ones, so that the cycle can repeat.
Slashdot Mirror
As long as they're adhering to the licensing terms of the projects they're using, there's no reason why Apple should stop.
The deal is that Compaq reversed engineered IBM's BIOS -- the only part of the design that was a trade secret. Everything else with the PC was very well documented and easily reproduced. The BIOS calls were already well documented. All Compaq needed to do was come up with a fully compatible BIOS without using IBM's code. Compaq came up with workalike BIOS using clean room techniques (or was it Phoenix technologies or some other shop -- I don't remember). I'm sure IBM fought tooth and nail, but they obviously weren't successful.
As for Apple vs. Psystar, it's quite different, the issue is that Psystar is violating Apple's software license agreement (that the OSX software will only be used on Apple-branded hardware). There are software checks in OSX to verify the hardware is Apple's, which means that Psystar would have to patch OSX to bypass those checks, and then distribute the modified code as their own OS.
Had Psystar somehow reverse engineered OSX with clean-room techniques to produce their own fully compatible workalike, this might be a very different case.
Also, copyright laws have changed quite a bit since 1981. I don't know if Compaq would have been able to legally clone the PC with today's laws.
It's one thing to write code that follows a sequence of steps and generates correct output. It's quite another thing to write robust code that handles problems gracefully.
In the real world, problems are inevitable. For example:
As you design and write your code, try to anticipate the problems you'll have to deal with, and the things that could go wrong. Be religious about error checking and handling -- sure, it's tedious, but it makes your software dependable and easier to support once it hits production. Unless you like 3AM wakeup calls from the guys in network.
You may not be able to recover or work around all problems, but your code should at least handle them gracefully--even if that simply means cleaning up, logging an error, and alerting the operator for further troubleshooting.
Sure, Hayes technically owned the AT command set, but it was not a trade secret -- it was widely emulated by other modem manufacturers, and became a de-facto standard. I'm a little fuzzy here -- did Hayes actually try to keep other manufacturers from using it?
Similarly, most dot matrix printers were Epson compatible, and laser printers were typically LaserJet II compatible or Apple Laserwriter compatible (e.g. postscript). That didn't give you access to all of the extra features of a particular printer, but it did mean your printer would be functional / useful with the software you already owned.
I don't remember serial / printer cables being different, at least for standard peripherals like parallel printers or serial modems. I remember HP had their own serial plotter cables (which made supporting AutoCAD lots of fun). Sometimes, cables and hardware would play fast and loose with the hardware flow control signals, or by hard-wiring pins together (e.g. DTR/DSR, CTS/RTS, etc). But generally, hardware was well-behaved enough that you could get it working.
I miss those days :(
It has not always been a myth. Sure, there may be no such thing as perfectly interchangeable hardware, but most hardware used to adhere to well-known standard interfaces.
Modems all supported RS-232 serial ports, and nearly all used the AT command set. Internal modems had no physical RS-232 port, but to rest of the computer, they looked like a serial port and still presented the same AT command interface. There were no "drivers" to speak of.
Sure, some modems added extensions / features, but as long as you stuck to the core AT commands (e.g. ATH, ATD, ATA, etc), the modem would work the same predictable way regardless of who made it or whether it was internal/external. You were free to choose your terminal software... hardware... operating system... even serial port hardware... the list goes on.
What was really nice about generic hardware was that it worked in a well-known, predictable way. If you were so inclined, you could write your own terminal software, operating system... even create your own hardware if you wanted. The information you needed to get everything working--UART documentation, AT command set, BIOS calls, X86 instruction set, etc... was widely available. The only limits in your way were the limits of your own ability to figure everything out.
You mention the C64 and its own proprietary modems. In fact, the user port on the C64 was RS-232 compatible, the main difference being voltage levels. Many companies designed RS-232 interface kits for the C64 allowing you to connect any standard modem you wanted. The specs for the user port were published in the Commodore 64 programmer's reference manual. If you were so inclined, you could actually build your own RS-232 interface from parts available at the electronics store.
With Windows-specific hardware, we no longer have that freedom. We've lost something -- Now, even if we want to write our own software stack or implement our own hardware, we're stuck -- the information needed to make the hardware work is hidden, locked away in a binary driver that only works on one platform. The only way to make it work elsewhere (e.g. Linux) is to reverse engineer the product -- much more difficult that working against an open spec.
Why do I have to reverse engineer my own hardware if it supposedly adheres to a published / well known specification?
A while ago, our company ordered an upgraded protocol license for some Intel telecommunications gear.
A few days later, a big box shows up -- I think a 2 x 2 x 2 foot cube. In that box was a wad of packing peanuts, as well as a padded envelope...
When we opened the envelope, we expected to find a license button, which would be physically installed in our equipment. There would be no reason to ship that in a large box, but at least a license button would have been some tangible product that justified shipping.
Alas, the envelope contained no license button after all. Instead, it contained a single sheet of paper complete with instructions on how to access a web site, and a validation code to use. That validation code would then give us an actual license key, which we could then enter into our equipment to unlock the extra protocol features (that were already built in to the equipment).
I can't quite put my finger on it, but something seems a little wasteful here... I'm *sure* if somebody thought hard about this, they could probably find a way to do the whole thing electronically...
I think if you went to the average person who uses text messaging heavily, they would say they're paying for the ability to send text messages to their friends when they can't make a phone call. They don't really care how it works or how the network is (mis)engineered. -- they just care that it does. If they're happy paying $.10 per message (or $10.00 / month for unlimited), then they'll subscribe to SMS and the telco will be happy to take their money.
As for being badly engineered, nobody expected SMS volume to grow like it has. SMS was originally expected to be a way to send programming updates to handsets via "spare" bandwidth on the network. While it was also possible to send regular text messages via SMS, it really didn't get much attention until just a few years ago. Once people discovered SMS, the usage took off beyond the wildest dreams of the carriers (both in terms of profit and also impact). It's difficult to keep engineering for 30 - 50% per year growth in volume without spending a lot of money in hardware / network upgrades.
As for a better protocol that may one day deprecate SMS -- I guarantee that carriers are looking for one that scales better, without impacting battery life (you probably can't keep the phone continuously connected to an IM server via the data network, or you'll drain the battery in an hour). That's a solvable problem though, once the carriers and handset manufacturers can all agree on the solution. I expect the end result it will look something like a cross between SMS and IM.
Don't expect that to happen quickly, as people will need new handsets for that to work -- and most people don't upgrade phones that often. Even when it does, as long as the carriers control the network or the devices that communicate with it, they'll find a way to bill for you using it, in a way that maximizes their profit.
The bottom line is this -- carriers are looking for ways to bill you as much as possible without you complaining or dropping service. Services and add-on features are the means by which they justify this billing. They're not holding a gun to your head though -- if you don't want the service, have them remove it from your account, or don't use it. But with SMS, lots of people use it happily, and some quite heavily. They wouldn't be doing so if they truly felt it was a ripoff.
Considering the cost of SMS, keep in mind there's much more to SMS than just transporting the bytes of text. One of the things you're overlooking is the store/forward nature of SMS (for reliable delivery), as well as the per-message transactional overhead.
With a voice call, most of the work is in setting up the connection to the person you're calling. Once that connection is established, essentially you're streaming 8K per second of data (64 kilobits / sec). None of that data gets stored anywhere for later retransmission -- the network really needs to do nothing beyond act as a pipe.
With SMS, your message gets stored in a queue so that it can be sent to your recipient if they're not available. This message queue needs to be able to handle many thousands of transactions per second -- if done incorrectly, this can cause a significant bottleneck. You might not notice if 160 bytes worth of voice data get scrambled, but a missed SMS message might cause you significant problems. If your phone is turned off, you miss your calls -- maybe you'll get a voicemail. With SMS, you'll get your message when you turn the phone back on.
The per-message transactional overhead can be quite substantial. The carrier has to generate billing events for sending / receiving messages. They may need to query or debit a prepaid system. They may have per-subscriber whitelist / blacklist rules which need to be applied to every message. All of these systems cost money to purchase and maintain. These also apply to voice calls, but in that case, those costs are covered either by your flat-rate local service charge, or by your per-minute long distance charges.
One other thing is that delivering SMS messages does actually cause quite an engineering problem for cell providers. SMS messages are typically delivered via the overhead control channel, which is the same channel used to do call setup/teardown, handoffs between cell sites, and other tasks. The overhead control channel is typically limited in capacity, and many carriers have engineered enough capacity for regular call activity. SMS has exploded in growth over the past few years, to the point that it is exhausting this overhead control channel for some carriers. Carriers have to spend considerable effort to reengineer their networks, so that they are able to keep up with both SMS traffic as well as regular call handling traffic.
The bottom line is that SMS is not a data transport -- SMS is a communication medium, an alternative to a voice call or email. People often send an SMS when a voice call would be inappropriate -- for example, in church, in class, at dinner, etc. The value of SMS isn't in the transport of the bits/bytes, but in conveying a message without having to talk, and without needing to be next to a computer. As for comparing it to a data transport, nobody sends files via SMS. It would be far too slow and expensive.
I agree that 10 cents / message is a little steep, but then, I've paid for a bundle to control costs. Most carriers offer unlimited SMS plans for reasonable prices, or smaller bundles at lower rates. Even though carriers are making money hand over fist for SMS, usage continues to grow exponentially. Even if you consider it a ripoff, there are millions of active SMS users who don't. If you don't want to pay for it, don't use it. :)
Sometimes, the code wasn't written with the mindset of how things *should* be done. Sometimes, the code was hurriedly slapped together by somebody who didn't anticipate the ways that things could fail (e.g. malloc() failure, disk full, database connection failure, etc). Sometimes, it's code that was written poorly because the developer didn't know of a nice standard best-practices way to do it, didn't care to figure it out, or dismissed it out of hand because they didn't get it.
Other times, you run into code where the developer gets fancy in an attempt to shave every last cycle out of their code (especially when the application isn't even CPU bound to begin with). Sometimes, developers like to do it the hard way just to show off how smart they are.
Finally, sometimes the code you inherit is truly spaghetti code. Some of my favorites:
I bought an unlocked Nokia E70 a while ago, and have no trouble using it with the AT&T GPRS/EDGE network.
The phone does have to be set up with the appropriate settings to 'log on' to their network though. At least with Nokia, I was able to get the settings sent to my phone over the air from Nokia's website--they had settings for a wide range of models and carriers. You might even be able to do the same directly from the AT&T website as well.
In fact, a few months ago, my wife and I bought a MacBook at an Apple store. My wife asked about upgrading it to 2G of RAM.
The salesperson told us they could do it in store, or we could do it ourselves. Sure, she would have been happy to sell us the RAM and service, but mostly she was happy to sell us a laptop.
At no point did she try to pressure or scare us into paying to have an Apple Genius install Apple-branded RAM. In fact, she even referred us to Crucial.com and PNY.com, going as far as showing how to use their online configurator.
There was actually quite a bit more to Logo than just the familiar turtle graphics. While I haven't played with Logo in a long time, I remember it was quite easy to write structured programs. You could define primitives (essentially subroutines), read/write files, handle I/O, etc. I think everything was in place to write some fairly sophisticated software without ever involving the turtle.
IMHO the turtle is really more of the friendly face, to make Logo fun for beginners (e.g. look at the pretty designs you can draw, and look how easy it is to build more complex images out of very simple, reusable building blocks).
At the time, BASIC made it very easy to write spaghetti code, especially with its use of line numbers rather than labels. The more GOTO and GOSUB statements you had, the harder it became to manage--changing line numbers could unleash a horde of broken GOTO statements.
IMHO, I think Logo doesn't get enough credit for what it truly was.
This has nothing to do with the iPhone, and everything to do with me not having the international calling plan.
For me as a fairly light user, it doesn't make sense to pay for a $75 / month international data roaming plan. Even the extra cost of an international plan would be a waste for me. I've been overseas one week in the past three years, and that was while on vacation. The only reason for having the phone was for emergency use (and occasionally texting my wife when she went off shopping). It would have cost us more to have the international plan than it ever would have saved us.
If I need data access while overseas, it's for work, and therefore it's on the company's dime.
This was AT&T wireless.
From what I understand though, it has everything to do with the European carriers charging outrageous roaming rates.
The other thing I read is that if you don't answer a call and let it ring through to voicemail, you actually get nailed for double the airtime charge, as it becomes two calls. The first call is from the caller to whichever switch you're roaming on. The second call is set up from the serving switch, all the way back to your home voicemail platform. Can somebody confirm if this is true? It sounds like quite a ripoff! And quite a neat way to run up somebody else's cell phone bill...
In fact, I'm even told that if your phone rings for an incoming call, that's enough for you to get roaming charges (even if you don't answer it). Supposedly you can avoid that by forwarding incoming calls directly to voicemail.
BTW, you don't want to roam internationally, at least, not without an expense account.
I remember one year I took a week's vacation in Ireland, and took my GSM phone with me. One day I was walking back to the hotel and the phone rang -- one of our customers was calling me directly, rather than use our central tech support line. It's bad enough to take direct customer calls on your personal cell phone (because the customer hasn't updated their contact info). It's even worse when that happens while you're roaming internationally.
The upshot is that I answered reflexively, before I realized what the call was going to cost. I hung up immediately as soon as I made that realization--the call must have been less than a second or two. That was still good enough to bill for a complete call, rounded up to a minute of airtime.
That second or two of airtime cost me $3.00 on my bill.
No, they didn't buy me dinner first.
Game Console or PC, a DVD Drive is still a DVD drive with a different face plate. Especially since they sold me the hardware below cost, I'm willing to cut them some slack.
Why? You paid $300+ for it. Who cares what it cost *them*? If they sold it to you below cost, why does that entitle them to any more leniency on your part? Are they doing you a favor that way, or does the low cost mean that you owe *them* a favor?
Would you be harder on them if it only cost them $100 to make the 360?
Also many rural areas aren't served by cable. They're very prone to outages due to downed lines (cable) or rain (satellite) too. Not fun if you're in the middle of tornado alley and all satellite and cable goes down for the community because of wind or rain from the approaching line of thunderstorms.
I don't live in tornado alley, but rather on the gulf coast of Florida. Needless to say, hurricanes are a fact of life for us. I can relate to this concern.
During a hurricane, it's very important to keep up with fast-changing weather updates. For example, during Hurricane Charley, the storm made a sudden transition from category 2 to category 4 strength, plus took a jog in our direction. What was going to be a non-event for us very quickly turned into a direct threat to our safety. Thanks to the local news broadcast, we were able to keep up to date with the storm's progress.
I should point out that in a hurricane, you can pretty much count on losing power, cable, phone and of course satellite. The only way to watch the weather radar is by a battery powered TV, picking up a local broadcast.
Until handheld digital TVs are readily available and affordable, the converter boxes will be of limited use to me during a hurricane. If I'm huddled away under the stairs without power, will I need to plug the converter box into a UPS so I can watch the local weather broadcast on a portable TV?
Will digital TVs be affordable enough that a typical Florida retiree on a fixed income can afford to buy one?
You mean 0.90 is the same as 90%, right?
Wow... I stand corrected on the nesting... Since I'm primarily a C developer (and only dabble in HTML) I just assumed HTML was as strict as C. You learn something new every day :)
I didn't realize HTML was somewhat lenient about nesting elements. There must be situations where HTML requires strict nesting (e.g. tables, lists, frames). Is there anywhere I can go to get a good answer? Is this part of the original design for HTML, or is this a real-world concession, given the number of broken authoring tools and browsers?
I can see this would be helpful for basic character formatting, esp if you think of the tags as on/off tokens, rather than nested blocks.
<ul> means underline ON, </ul> means underline OFF.
It would reduce the amount of HTML code needed for something like this:
<ul>underline this <b>this is bold *and* underlined</ul> this is only bold</b>.
With strict nesting, it would look like:
<ul>underline this <b>this is bold *and* underlined</b></ul><b>this is only bold</b>.
From what I understand, XHTML is absolutely strict about nesting. Personally, I prefer that approach, but that's because I'm a developer that has to do that daily--how hard is it to get the nesting right anyway?
Using universal closing tags forces the developer / authoring tool to properly nest tags. The result is that the web browser doesn't have to guess when it sees improperly nested tags--in turn this makes page rendering much more consistent between browsers. This also removes the need for workaround kludges for various HTML quirks.
Universal closing tags are nothing new -- The C language and many others use the same curly braces to open/close a code block.
For example:
if (x) {
while (x) {
for (;;) {....}
if (x) { while (x) {.....} }
You can easily nest 'if', 'while' and 'for' blocks. The compiler has no problem figuring out which block should be closed when it sees a '}'.
By making the close tag universal, you make it impossible to get the nesting syntax wrong. Sure, a developer might still get the nesting *logic* wrong, but IMHO it's better to have a human developer fix this rather than have the browser or compiler try to guess.
A coworker and I walked over to the local EBGames about 15 minutes before they opened. There were three people in line before us. About 10 - 15 showed up after us (right before the store opened at 10:00). There was one family that had been there since before 8:00 AM, but I saw no tents or sleeping bags :)
:)
Neither of us had a problem getting a reservation. I don't know what the store's allocation was, so I don't know how many people were disappointed. Alas, we both had to get back to actual work
I was most impressed with how orderly the line was--there was an unspoken agreement that everybody would line up single file, and first-come-first-served.
Many years ago, I got hoodwinked / pressured into signing up for the credit card "payment protector" plan. Essentially, they would bill me 1% of the previous month's balance for the program, and charge that to my card.
...the *NEXT* month, I get a bill for $0.02... the payment protector premium for the previous month's bill of $1.69. It's bad enough that they charged me a premium to protect the previous month's premium... but then on top of it they actually paid postage to mail out a bill for $0.02. Highly cost-effective :)
So after a few months of not using the card, I finally charged $169 to it and promptly paid it off. I got a bill in the mail the next month for $1.69, charged to my card. That was entirely 'payment protector premium. I was a bit steamed, but I paid that off anyway...
I proudly paid the $0.02 at an ATM, and then gave their customer service department a call. They took me off the program without any problem, and even paid me back the $1.71 I'd paid in premiums.
Each pound of paper that goes into landfills and which does not degrade is three pounds of carbon dioxide that had been taken out of the atmosphere.
:)
So in fact, it's actually a good thing that the paper doesn't degrade in landfills. Think of paper as basically one giant sheet of carbon dioxide in a fixated form. Essentially, making paper is really just one of the steps in removing carbon dioxide from the atmosphere. You see, paper comes from trees, and trees grow by using atmospheric carbon dioxide (and water and sunlight). Essentially, trees act as carbon dioxide sponges, cleansing the air. Just like sponges, eventually they get saturated and lose their cleaning power. So, what you do is you make paper out of the trees, then you bury the paper. since the paper never degrades, the carbon dioxide is never released back to the atmosphere. You also plant new trees in place of the old ones, so that the cycle can repeat.
I think I understand now
In fact many parents don't even let their children play violet video games, for fear that the games might adversely affect their children's minds.