yuubi

They have ieee1284 printer-port protocol baked into them, so you do an OUT transaction of several bytes and the adapter does the per-byte handshaking. The old parallel ports were just a collection of gpio lines (originally some input-only and some output-only, later some turned bidirectional) connected to some io addresses.

Sounds like if Acme Telecom resells Google's service, and a cop has the number of an Acme subscriber, Google will put the cop in touch with Acme.

MIPS, the Microprocessor without Interlocked Pipeline Stages, doesn't make sure the result of one instruction is available before executing an instruction "later" in the stream that refers to that result. Something like (pseudo-asm with C-notation comments)

     ld r1, @r2   ; r1 = *r2
     add r3,r1,r4 ; r3 = r1+r4

wouldn't set r3=*r2+r4 because the memory access hasn't finished by the time the add runs.

The lock-powered-by-key exists: http://www.cyberlock.com/access-control/cyberkey-smart-keys . The power and signaling go through metal contacts rather than wirelessly.

In many applications, crashes are less of a problem than falsely believing a write happened persistently. Consider a mail server: if it can wait until the message is really saved before returning the final success response, then a crash means a retry later (and maybe a duplicated message if the crash happened in the small window between the write committing and the response going out) rather than a lost message.

For those who haven't had a physics class, that's garbage because silver is somewhat more conductive than copper, which is slightly more conductive than gold.

The main benefit of gold is that it's more stable than copper, so it's a good material for connector contact surfaces, but the bulk of the contact should be something else like copper or steel, depending on the relative importance of electrical or mechanical properties.

Newer systems using 3GPP-type authentication (LTE, and I think UMTS) require mutual authentication between the SIM and the network (details in [1] section 6.3). If the network doesn't provide a satisfactory AUTN, the mobile can't proceed with connecting to the network because later steps in the connection procedure need some keys derived from the authentication procedure.

I think in older GSM-derived systems, the SIM just computed an authenticator based on a nonce provided by the network.

I know for sure that CDMA (IS-95 and 2000) and later AMPS systems supported one-way authentication or not, as selected by the network.

I've heard rumors that attackers have to force a protocol downgrade to something without mutual authentication by jamming the legitimate signal. The other options for the attack would seem to include

- obtaining the secret key value (or a set of authentication vectors) from the legitimate network. Either of these seems more difficult to obtain than the actual locations that the attackers claim to want.

- obtaining K from SIM manufacturers, which has happened [2].

- exploiting implementation defects in SIMs or mobiles.

[1] 3GPP/ETSI TS 133 102 "3G security: security architecture", http://www.etsi.org/deliver/etsi_ts/133100_133199/133102/13....

[2] https://hn.algolia.com/?query=gemalto&sort=byPopularity&pref...

> ultimately I lose a bunch of work.

One trick that's worked ok for me in a private repo is, before starting to edit the fix-spline-reticulation branch (which has a handful of separate logical changes, fixes discovered midway through a later change that really belong in an earlier change, and temporary debug code that was never meant to go into the product) for publication, to do

    git branch fix-spline-reticulation.0

(or .the-next-sequential-number). Then no matter how badly the "rebase -i master" goes, there's a branch tag pointing at the original state, and

    git branch -D fix-spline-reticulation
    git checkout fix-spline-reticulation.0
    git branch fix-spline-reticulation

will destroy the failed attempt and restore the branch to its earlier state. (Note that if you decide in the middle of the rebase that you're losing, "git rebase --abort" will undo anything you've done so far; you need the backup only if you regret the rebase after you're finished). It also makes it easy to "git diff my-feature.0..my-feature" and confirm that all the changes in the edited history add up to the same as the real history.

Sometimes I do this in the middle of development to move all the changes intended for the product ahead of the temp debug stuff in case I suspect the debug code is causing problems. Keeping the debug code in the dev branch even after the cleanup rebase makes the diff to check the rebase easier (then, of course, the merge should take the commit just before the debug).

Best never to do let anything but the cleaned-up branch hit a shared repo.

I think nmake is or was a normalish make.

Confirming you can feed a .sln file to msbuild (I did it the other day), no idea about whether nmake accepts them. Source: https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin3... .

Just redirect gpg's input from the file?

    gpg ... < hello.txt | curl ...

Its stdin will be the file instead of a pipe, but few programs care about the difference and fewer still in such a way that you'd prefer to use the pipe.

The other side from the vector adder ("front" side at https://upload.wikimedia.org/wikipedia/commons/c/c4/StudentE... ) includes a circular slide rule with perfectly normal log scales for fuel, time, distance calculations, an extra scale to help with hours/minutes conversions, and some marks for various conversion factors, including lb/gal fuel and lb/gal oil for use in weight/balance.

The main difference between a straight and circular rule is that it has only one appearance of the index, so you don't have to move the slide around as much, and it's round so the equivalent of a 10" rule has around 3" diameter.

It also has other scales for converting altimeter/airspeed (really pressure gauge) readings into other numbers more useful for certain purposes like true altitude (good for missing obstructions) and "density altitude" (for estimating takeoff performance, also helpful for missing obstructions).

A sim card gets to send messages to the baseband in response to requests from the baseband. It doesn't have arbitrary memory access unless the baseband has really nasty bugs.

A "short-lived victory" isn't what it used to be. Local production started 45 years after the first shipment; sounds pretty good in modern terms.

Gmail also supports you.r.nam.e@gmail.com (add random dots to the local-part). (Almost?) every system considers '.' a valid character. However, you need to keep track of which tagged address goes to what service, much like the case of a tag with random hex digits.

These programs can't do much that the carrier couldn't do without your help: set up calls, send/receive SMS/USSD, sort of thing. It's not as if they ran on the application processor as root or had DMA to the app processor's memory.

The SIM in 3G isn't really much like a DRM thingy, apart from containing a key; it's more like a securid keyfob. The only interesting thing it does (apart from storing constants like its serial number and variables like your phone book and text messages) is to generate authentication responses (to prove to the network that you have it) and derive session keys (so your phone can encrypt and authenticate what it sends over the air).

All the interfaces to this are open: the wire protocol to the SIM and the over-the-air protocols for authentication and security (what a phone needs to do) are specified completely by freely available 3GPP/ETSI specs.

The details of how the SIM computes the derived keys and authentication response are a black box. 3GPP suggests a couple of sample algorithm sets, but there's no way to know whether the card did that unless you have the secret key (shared between the card and a box deep inside the carrier's network).

However, the phone just passes the authentication-request parameters in an authenticate command to the card, passes the result of that in an authentication-response message back to the network, and obtains integrity and ciphering keys (for GSM) from a couple of files on the card (UMTS/LTE use some keys derived from these, but again, it's documented).

An alternative, used in some older US specs like late AMPS, CDMA, and (EIA-136) TDMA is to store the secrets in the phone, generally at manufacturing time. This means that there's no real boundary between the carrier's authentication widget and "your" phone.

Much better to have the identity contained in a SIM that belongs to the carrier, that your phone talks to at arm's length.

Java seems to be for applications other than plain (U)SIM like prepaid account management. The card can ask the phone to add a menu to its interface, show messages, collect inputs, and other things. Maybe all plain USIM apps are written in java these days instead of having a masked ROM like they probably used to.

I think quantized blink rates showed up around the time someone discovered that rx/tx leds as usually implemented on dialup modems of the time leaked data including passwords to anyone who could see the front panel.

At least some use publications like http://www.researchdisclosure.com/ instead. I know the print edition at least used to exist and have subscribers because there were some shelves of it in the local university library.

    add ix iy

I'm pretty sure that isn't a thing (the z80 has prefix opcodes for "hl in next instruction is really ix (or (hl) is (ix+dd)" and one for iy, but not one for both in the same instruction like that). Source: worked on a product with a z80 in this decade.

Pet theory: someone at MS saw Apple taking a 30% cut of app store sales. Hmm, people seem to tolerate gatekeepers on mobile/tablet more than on desktop. So the obvious answer is to get into that business. But the competition has already got trained users. No worries, just make the next version of Windows work like MS tablets and phones. People take whatever they're told is the upgrade, so shortly after the upgrade there'll be a market of people ready to buy Windows tablets and phones, with MS getting a cut of sales.

A while later, it didn't work out that way and 8.1 came out.

In other bands, the operator in control of the transmitter generally needs to file paperwork with the FCC to get a license (in some systems like cellphones, the base station is in control so the subscribers don't need licenses, just approved equipment).

The vax had 4 modes: kernel, executive, supervisor, user. I just read[0] that kernel and executive had implicit SETPRV privilege (and thus access to those modes would be tightly controlled because SETPRV allows bypassing all access controls); and I think I heard a while back that normal programs ran in user mode but the shell-equivalent ran in supervisor mode (and [1] sort of implies this).

[0] http://h30266.www3.hp.com/odl/vax/opsys/vmsos73/vmsos73/5841...

[1] "If you created the name with a DCL command, the access mode defaults to supervisor mode. If you created the name with a program, the access mode typically defaults to user mode." http://h71000.www7.hp.com/doc/731final/4477/4477pro_007.html

Because of that feedback, you get to use your load as the lower half of the divider, so the total current drawn from the source is the load current plus a few microamps for the regulator's internals.

In the passive voltage divider circuit, if the load varies its current draw, you have to have a resistor in parallel with the load so that the total current through both the load and the resistor doesn't vary significantly (where "significant" is derived from your tolerance for voltage variation).

> My guess is that the SIM card contains a small application that can activate a specific profile in response to a command from the Fi software.

Standard smartcards (including SIMs) have a select command[0], which is used to select applications. If there are two USIM apps[1] (what normal LTE SIMs have one of), they can both be listed in the directory file, and the phone can select either based on whatever it likes. I'm not sure what a plain phone would do with a dual-USIM card (search the app directory for a USIM app and use the first or last? Ask the user? Choose based on the network ID as encoded in the IMSI? Other??)

[0] The relevant 3GPP UMTS/LTE spec, http://www.3gpp.org/DynaReport/31101.htm , defers to an older ETSI spec, http://www.etsi.org/deliver/etsi_ts/102200_102299/102221/08.... for the actual command definitions.

[1] The USIM app, defined in http://www.3gpp.org/DynaReport/31102.htm , contains information like the IMSI (readable), perhaps the phone number (r/w), and the secret shared with the network (inaccessible, but the "authenticate" command can use it to generate a set of session keys that are accessible to the phone).

> More likely is that the SIM card just holds a few different profiles and custom software that runs on the baseband processor watches the strength of both networks and sends out of band messages back home to tell recycled Google Voice infrastructure how to find the subscriber.

Or Google provides a P-GW (as shown in https://en.wikipedia.org/wiki/System_Architecture_Evolution#... ) that both networks use; then the mobile could keep one IP address and the voice services wouldn't have to track anything. The SWn interface shown on that diagram is basically a VPN.

Not \x08 tabs, but tabs like recent firefox and chrome use (as if you had several terminal windows with separate ptys and screen contents, but all in one window-manager window).

The "gray background" is really a "bright black" background. The old IBM CGA and successors had a flag for whether to interpret the top bit of the background color as intensity or blink[0]. It looks like Linux used to have it set to blink a few years back[1].

[0] http://webpages.charter.net/danrollins/techhelp/0087.HTM

[1] http://sourceforge.net/p/linux-fbdev/mailman/message/7849329...

Pour encourager les autres? If annoying "P""R"C means you hurt worldwide, perhaps the next company with evil foreign values will avoid trespassing into the only harmonious country or something.

The 16 and 75 were different people (the top 20% and bottom 12% of scorers on a vocabulary quiz that was included in the survey).

^S and ^Q don't send signals; they make the tty driver stop delivering output. If you ^S a process that's not generating output, it will continue to run until it generates some output (until it fills an output buffer? not sure; the original intent, to match a fast process with a slow output device, would be well served by buffering some output).

SIGSTOP is like SIGTSTP, the signal usually generated by ^Z, except (like SIGKILL, signal number 9) it's not possible to catch it. It makes the process stop doing anything at all until something sends SIGCONT (which shows up in ps output as state T).