If it were portable and stable and still supported this decade, I'd really like NeWS, or at least OpenLook. The window system ran in PostScript, so What You See really Is What You Get. Iconizing a terminal window just cranked it down to a 1pt = 1 pixel font, and the icon was still a live window, so you could see the icon change when stuff scrolled. My supervisor kept switching between reading glasses and distance glasses, so we just set his default font size to 24 and everything was big and clear. It used a lot of memory, though - you needed the 8MB version of the Sun/3 instead of 4MB to get decent performance.

But realistically, FVWM or anything a half-step up from TWM was fine. Even Motif would do.

OS9 was a nice sort-of-Unixy operating system that ran on 6809 microprocessors, back in the day.

Somebody obviously didn't get the obvious, or at least didn't draw the obvious conclusions from it.

I never found pot did much beyond relaxation, a bit of silliness, and maybe some enhanced enjoyment of music. Yeah, everybody reacts to drugs differently, your mileage may vary, and "relaxation" for me included reduced muscle pain and indica couch-lock, but it wasn't particularly psychedelic. Closest I got to hallucinations from it was a bit of tunnel vision which came with a strong suggestion that I ought to sit down, right then, to avoid falling over.

1 Mbps =~= 10 GB/day = 300GB/month. If your cable company puts a bandwidth cap on your service, it's effectively slowing you down to less than DSL speeds.

Blocking inbound SMTP isn't going to prevent any spam; it's just going to force people to use commercial email services to get their mail. No excuse for it.

There are three kinds of users who send outbound SMTP

• Legitimate home email users.
• Infected zombies sending spam.
• Spammers using home systems.

Many ISPs have a policy of "block SMTP by default, but allow it if the user requests", which keeps out the zombies. It does force them to deal with occasional spam complaints because of customers who spam on purpose, but they're blockable.

I don't use Netflix, but here in Silicon Valley my 3 Mbps DSL is perfectly capable of playing standardish-definition TV from TV network websites, as well as playing YouTube. If I were a sports fan I might care about getting HDTV sports over the net instead of cable TV, since I assume Comcast's sports channel selections are as lame as their non-sports TV channel selections and sports actually does benefit from the higher resolution.

Back in the 90s and early 2000s, we were trying to sell businesses on using 8kbps G.729 calls from IP PBXs instead of 64kbps telco voice, and they would whine about Mean Opinion Scores and latency (and didn't get that India just wasn't going to get any closer and the speed of light wasn't going to change.) Cell phones convinced most of those people that they didn't really need to care - GSM was 13kbps or 6.5, and your office PBX phones had much better microphones than a typical cellphone and usually didn't have wind noise and trucks going by in the background.

I did have one friend who kept an analog cell phone around for a long time after most people had switched over to digital, because he spent a lot of time out in the mountains and back-country where there wasn't yet much cellphone signal, and a bad analog call was noisy, while a bad digital call just wouldn't stay connected.

When you make a VOIP connection, you're signalling to the network that you want to do that, it finds you the IP address and port number, either for a gateway into the old telco network or else for the phone you're calling. That's not getting you out to the public internet, though if you've got another friend with another rooted phone who's also got an active wifi connection, maybe you could do something useful with it.

But remember the other signalling that's going on, between your phone and the cell tower, which is keeping track of how much bandwidth you're sending - you'll have to make it think you're on a voice call also, if the voice prices are managed separately from the data prices.

Jitterbug's been a great phone for my mom. Her vision's not very good, so she doesn't bother texting (she'd need to hold a magnifying glass in one hand and use the phone with the other) , and she's stubborn enough she doesn't like to carry the phone around unless she expects to need it (e.g. going somewhere that she'll need to call a taxi), but it's reliable, does voice just fine, has big buttons for dialing, and makes free long-distance calls (so she doesn't bother buying long-distance from her landline telco any more.) The only way a smartphone would do her any good would be if Siri or equivalent could do everything, not just almost everything.

Vanilla telco G.711 is 64kbps, and it's what the digital parts of a telco voice call use. G.729 codecs, mostly used for PBXs, use 8 kbps. GSM had several codecs, including 13.3, 6.5, and less. The problem with all of these is that they need to send lots of packets per second to minimize latency - typically 20 or 30 - so the transport protocol overhead is usually several times higher than the actual voice payload, between IP, UDP, RDP, plus any layer-2 overhead (Ethernet's huge, or ATM's a bit less, if your DSL is using ATM.) In some limited environments there are ways around it, e.g. using CSLIP to do header compression on modems or whatever, but I don't know if most of the LTE carriers are going to do anything like that, or if they're just going to run native VOIP.

The overhead gets a lot worse if you need crypto and implement it naively using IPSEC, because you end up with a couple more layers of headers on top. It would obviously be better to have an encrypted payload standard, because then all it would cost you is some setup key exchange, but the telcos haven't had a big reason to do that, and most of the IP PBX vendors haven't either.

My GPS uses 2G cellular to get its traffic data and gas prices and to do Google search for destinations. It's going away next year, because Garmin's contract with the cellphone carrier isn't going to be renewed :-(.

Carriers really want that spectrum back, and 3G and LTE are much more efficient in terms of data bitrate per MHz of radio, plus they want to cut down on the number of separate types of equipment (not only for equipment costs, but also because keeping two separate channels of data is much less efficient than one fat channel.)

I don't know the VoLTE protocols, but for regular PBX-style VOIP, the voice compression is good enough and the voice payload in the packets is small enough that most of the bandwidth is used for IP/UDP/RDP headers, not the actual voice. There are way too many standards to choose from, but most of them run about 5KB/sec or less (that's bytes, not bits), so about 300 KB/min, or about 3000 min for 1 GB. There are people who use that much voice time, but not many :-) I'd expect that for a while you'll see multiple different standards for handling hd-mobile-to-hd-mobile, sd-mobile-to-sd-mobile, mobile-to-wireline, mobile-to-other-mobile-carrier, etc.

Back around 1990, I went to a technology talk by a guy from MCI who thought that the conflicting economics of offering voice and video on the same network were going to be a serious problem for telcos - video at the time meant ~1.5-3 Mbps corporate teleconferencing, and either you could price video too high to sell much of it, or you could sell T1 bandwidth cheaply enough to make videoconferencing affordable, in which case you'd undercut your voice pricing because companies would buy your video T1s to interconnect their PBXs for cheap. Better video compression got us out of that hole for a few years (384kbps or especially 128kbps video didn't cause that much trouble), but the Internet came along and started doing the same technological undercutting, VOIP started becoming feasible, etc. Mobile phones gave us a way to charge lots of money per minute again, but Moore's Law is still relentless.

Disclaimer: I do work for AT&T, but I do computer security, not mobile phones, so I have no idea what they're planning to charge for this, this is my own opinion, not the company's, blah blah blah. On the other hand, I have been doing various kinds of telco things for many generations of technology :-)

While the Reagan Administration really wanted to get most of Corporate America doing that, as a tool in the War On Drugs, it was hardly universal, partly to allow companies to go way overboard without the government having to take responsibility.

Cygnus Solutions, a company that did open-source gcc and other GNU work, had a contract supporting the state of California with compilers, so they were required to have a corporate drug policy and have it posted up on the same board as the minimum wage notices, etc. There was no requirement for the policy to be anything specific, including testing, and the company eventually decided on an official policy that if you bring illegal drugs to the workplace, you have to offer to share them with your coworkers, and posted it. I'm not sure how often the policy was actually followed, but I know some obvious people to ask :-)