Sorry, we don't deal in fiddling small change.

That's not how a GSM SIM works (I am working on a couple of SIM products). Firstly, most of them don't have crypto coprocessors. Secondly, the PIN (or PIN2) doesn't wake anything up. Entering the PIN is required to get access to some of the files on the SIM, so it's more like entering a password the first time you use sudo. However there have been proposals for SIM toolkit financial applications which would work roughly as you describe.

SMS was not invented to be email, and came in when fax was more common than email. In fact it was invented for engineers rolling out mobile phone infrastructure so that they could communicated before voice was fully up and working. It's bodged in to a signalling protocol, which is why there is a 160 byte limit - that's all that would fit into the frame, and for the original application it wasn't worth putting in concatenation. Then it was used as one-way notification from the network to the handset, primarily to tell you that you had voicemail. Eventually send-capable phones became available. I bought a Nokia 2110 to be able to send SMS - one of the earliest adopters. Now get off my lawn, kids!

I've worked for a large mobile telco for more than ten years. "Content based charging" has been discussed for all of that time, usually by new people coming in to the business. I don't think it's ever going to happen in the way described here. What we do have is zero-rated "on-net" content - that means that if you go to our internal web sites, it doesn't come out of your bundle (monthly allocation of data). That's reasonable, because you don't want to be charged for going to your account management page.

In general we just want to sell you a bundle of data, and we aren't too worried about what you do with it. There are some exceptions - for instance for VoIP traffic, if possible (and it usually isn't) we try to give a low-latency traffic profile. Video streaming is sometimes throttled for the very good reason that there is only so much bandwidth on the air side, and we need to be able to give other customers on the same cell reasonable service. Sorry guys, but this is more the laws of physics than The Man trying to screw you.

Yes, there are ways that we want to take advantage of our position as a phone company, but this isn't a zero sum game. We have things like micro-charging and secure identification that we are trying to build products on (or more commonly get third parties to build products on) - but this isn't going to work unless we can persuade you that you want to buy those products.

No, there was a UK weapon called Green Grass which was a bit hairy. It was a 4-500kT atomic bomb (i.e. not a hydrogen bomb). Due to its construction and the difficulty of arming and disarming it in flight, there was substantial concern that it was unsafe.

Probably, although I suspect that it also reflects people who left the church years or decades ago in practical terms.

One thing I find amusing about endless American discussions about the separation of church and state is that for many Christians, this is one of our important beliefs. I live in England (specifically England, don't confuse with the UK). We have a state church, the Church of England. Until the 60's farmers had to pay tax (tithes) to the C of E, even if they belonged to non-conformist churches - i.e. those churches which reject a link between church and state. From 1661 until 1828 non-confirmists were barred from holding public office, and were only permitted to take university degrees in 1871.

We don't believe in state support: it's a Faustian bargain. If church and state are linked, the state will control the church, at least to some extent.

It's got to be Bergenholm.

Bah, you kids can get off my lawn!
Back in the days of CP/M, we had to write Z80 code with an 8080 assembler, which meant that a good part of the time we had to hand-assemble code, and splice it in with DB statements because the assembler didn't understand the opcodes.
After that, K&R C was a blessed relief - and I don't mean this modern namby-pamby ANSI C with function prototypes and argument type checking.

There's a huge assumption in the phrase "colour blindness". Most languages call it Daltonism, after the discoverer, which makes sense because most of us can see colours, just not quite the same ones you do. For most of us blue and yellow are seen the same as an ISO standard human. Green is more interesting. I see several colours which I've had to learn to group together as "green", since they don't have much in common to me. Yellow-green is obvious, but I also see blue-green (not turquoise - different colour) and red-green. Those infernal bi-coloured LEDs show red-green. Blue-green is the colour of a "go" traffic light green in my country (UK) and in most countries I've visited. Twenty years ago I would still see the odd old red-green traffic "go" light, but they seem to have been replaced as a matter of policy. The difference between a blue-green "go" and a red "stop" is huge for me: no chance of confusion. An amber (I think it's called yellow in the USA) traffic light is much closer to red, and I have to use the position to distinguish them.
Size of the colour patch also matters: I can distinguish finer gradations in colour if the patch is larger. Luminance differences also help. This is part of the reason why specific mains wiring colours in the UK (and I think the EU) were chosen: for most colour-blind people, there is no risk of confusion.
Would I get it changed? Possibly, but it would be a risk trade-off like laser eye surgery for my myopia, with a much more restricted up-side. It would be useful for getting the right white balance for my photography, but not as much of an advantage for that as you might expect.
Much more important, lower risk, and easier is to make sure that you use the right colours for user interfaces - road signs, software etc. - or provide some sort of word-around. Let me give an example: I have to prepare a weekly Powerpoint 2003 slide summarising the state of my projects. There are two places where I have to colour something red/amber/green. One is a cell in a table, and the other is a filled circle. Unfortunately there are different dialogs for editing these colours: one contains two rectangles - the first containing recently used colours, and the second a wider palette. The other dialog contains a hexagonal palette. It doesn't matter hugely exactly which amber or green I use, but I'd like it consistent across the slide. This two-dialog arrangement means that I can't use the position of a colour in a palette to get a consistent selection.
Since come what may, you will always be dealing with people with uncorrected vision even if an upgrade is available, it's worth taking a few minutes to get this right when you are doing design work. It doesn't need to compromise the experience of anyone with standard sight, any more than a blue-green traffic light bothers them.

And all of them were on the lines of "i9", "s9" - always a 9 for some reason. And yes, they re-used them for different purposes. Actually that made a small amount of sense, since it was loosely based on an older HP86 BASIC program, and re-using variable storage saved memory. However since the HP86 supported structured programming (now there's a phrase that takes me back!) there was no need for all the globals.

Nope, it was a commercial product. And GP is correct - it wasn't used as a swap or other temporary.

No! Don't tell me! My life since then has been a spiritual search for the essence of "midlertidig" and its relationship to dexotrobing. An answer would be as objectionable as the experience of a zen monk finding that "one hand clapping" refers only to the self-congratulation of a pair programmer.

Ah. Well, of course I could tell you, but how much do you want to know the answer? [rubs thumb against fingers]

The academic estimates I've seen for current code are in the range of one bug for every 20-40 lines of code. Mind you, I think that's very vulnerable to definition: if code doesn't do what the requirement says, theoretically that's a bug, but if there is no requirement separate from the code (the normal FOS case) you've reduced the number of bugs without increasing code quality. I think a more important point is that we used to be able to associate a bug with a line of code, or a region of the code. Now a bug is more likely to be something like "3G modem type XYZ indicates an invalid SIM after 20s of poor signal strength", and is probably not connected to a code error per se. If we allow that sort of definition, then based on the asymptotic decrease I see in finding bugs in a particular supplier's mature code over a couple of years hammering, I think about one bug per 300 lines is about right.
BTW, I'm not sure what the 300M lines refers to. The total corpus in current use worldwide is way more than that. I've written about 100k lines myself for production code, and I'm sure there are more than 3000 programmers out there! Did you mean the source for Windows, perhaps?

My favourite bit of code was about 22 years ago. It was supposed to control some scientific equipment that we had bought from Denmark, and I had insisted on getting the source because of previous problems with the supplier. In summary:

- 6000 lines of Pascal
- 200 global variables
- 3 local variables
- 1 comment - the single word "midlertidig"

Oh, and one bug. Code really was less buggy back then.

Now get off my lawn, you kids.