"In computational complexity theory, NP (nondeterministic polynomial time) is a complexity class used to classify decision problems. NP is the set of decision problems for which the problem instances, where the answer is 'yes', have proofs verifiable in polynomial time by a deterministic Turing machine, or alternatively the set of problems that can be solved in polynomial time by a nondeterministic Turing machine."

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F...

Did nobody ever fix Slashdot for Unicode?

The connection machine's processors were distributed among multiple cards, a single card contained 16 processors, the 1 bit processors were implemented using a ROM chip, I think.

UTF-16 is an encoding which explains how to map bytes to code-points (what you call characters), like UTF-8. UTF-16 encodes data in chunks of 16 bits, while UTF-8 encodes the data in chunks of 8 bits. UCS-2 was an encoding where only the 2^16 first code-points could be encoded, in the same way that ASCII is an encoding where only the first 2^7 code-points can be expressed, and ISO-latin only encodes the 2^8 first code-points. UCS-2 was an attempt to encode the "most common case" as you describe it. The problem is, in order to achieve this, Chinese and Japanese characters were crammed together (look up Han Unification) and were basically not usable. We are talking about around 1.5 billion people here. The fix was to add back the characters that had been removed, and go above the FFFF line.

As to why we need trading cards and smiley in Unicode, the reason is pretty simple: compatibility. The goal is to be able to convert all existing text data into Unicode, this is why DOS area block drawing are defined as codepoints. Emoji were added to add compatibility to the Japanese systems so that companies like Apple could enter that market with the iPhone, without this, iPhone users would not have been able to exchange messages with other users.

Remember that at one point in time, ASCII was the extended character set with unnecessary symbols like curly braces, this is why C++ compilers still have trigraph support

Apple buying the vendor for the fingerprint stack might have something to do with Motorola dropping the ATRIX 4G fingerprint sensor.

The ATRIX 4G was supposed to get an ICS upgrade. There was a "leak" of a partially functional version. My guess is that the licensing issues with Authentec/Apple broke down. Guess Motorola didn't negotiate any long-term contract options.

It's a shame about how AT&T handled pricing on the LXDE subsystem. The X server implemented on the NVidia framebuffer/compositing layer was pretty nice. In theory Android 4.2.2 should support non-mirrored HDMI better, so hopefully I can get a Linux desktop bigger than 1280x720 on this Galaxy S3.

It is not really once code per country, ISBN started with a code per language zone, and switched to countries when they realised it could not scale, so codes 978-0 and 978-1 are for english (this includes the mysterious lands of united kingdom and australia), code 978-2 is for french, and so does 979-10, 978-3 is for german, the followin 978- prefixes are assigned to various countries. Note that the code is not assigned to the language of the book, but the dominant language of the country / publisher. So a swiss publisher can have a 978-2 book in english.

If prices of ISBN codes were really a problem, people could just publish in France, where ISBNs are free. Anyways nowadays ISBN are just a particular class of GTIN/EAN so I suspect one could just buy an EAN (UPC) code.

If we hit the reset button, can we also fix ASCII? it is by no mean the minimal set most english speakers think it is.

Why do we need a character to represent to 'v' one after the other? You could write 'w' with to 'v' and handle the ligature where it should be handled, at display time. There are so few words in English with the sequence vv that it makes no sense to have the special case coded in the encoding.

Also could we handle the dots on the characters 'i' and 'j' like the diacriticals they are? there should be first the the dotless 'i' and 'j' and the some character to add the dots, like all other diacriticals. Also move out the currency symbols ($ and £), they can be represented as text (USD and GBP), no point in have silly symbols in there. Also remove BELL (11), having a symbol for a bell (2407) might be bloated, but having one for the sound of a bell is absurd.

By the way, why do we need different code points for upper and lower case? They are just variants of each other anyways

Unicode is certainly messy, but plain ASCII is not much better: the most precious 127 code points of utf-8 are basically wasted to display 32 characters and a bit of punctuation, that is pretty bloated for me, we are just used to it

I was a fan of Elite on the C64, I tried Oolite, and it is indeed an excellent port of Elite. I also found it to be no fun at all: requiring time I don't have anymore and lacking the richness I'm used to find in games nowadays. The other game I loved on the C64 was paradroid, there is also an open source port (free Droid), same problem. My expectations and sense of fun have changed in 20 years.

You would still have to prove that they are responsible for the hack. The fact that their legitimate (if silly) business benefits from some hacked code does not prove they are responsible for the hack.

Or turn the problem around: if one provider of telecom services is ever condemned without any other proof than the fact they benefit from a hack, the bad guy just change their business model to extortion.

but there is no guarantee that awk is present on the remote machine, unlike grep, which is ubiquitous and part of the standard base. See, awk isn't, which experience has told me, but not you.

Which century did you have this experience in? awk has been in POSIX since, uh, 1986? It's mandatory in the SUS and the LSB. Every "charge for each utility program" Unix has been swept from the face of the earth.

If you're talking embedded systems, you're talking about busybox quirks or worse, and it's not really a good thing to lecture people about that situation without caveats.

Cool, an ad where we can leave feedback! Well, I had a scottevest and I found the material to be poor quality, some of the pokets were torn after less than a year, which never happened to me with any other jacket in that timeframe (it usually take 5 years of heavy usage). Also the vest is heavy even when empty. I'm better off with a normal jacket and a small backpack (which is more convenient to store/retrieve things from than trying to remember you put thing Y in pocket 2364263426).

I saw similar magnetic connectors in household appliances in Japan before Apple used them for laptops: my rice cooker and the water heater both had them.

This is one of the reasons instruments on the LHC are duplicated: Atlas and CMS. Given the difference of energy, if the Higgs is found in one of the LHC experiments, it is doubtful that the experiment could be reproduced at Tevatron.

But we aren't all bozos on this bus, and pretending "everybody contributed to it" is not necessarily the best way to fix this particular problem, or to reduce the likelihood of this kind of engineering failure in the future. Understanding how this happened is important.

My elevator version of what happened: the bellhead model of a communication service is a reliable circuit-switched connection. "Reliable" sounds good, and circuits are a familiar model. But the Internet is based on a model of best-effort delivery of packets. Every product group experienced in Internet infrastructure knew horror stories about confusing TCP. New entrants did not know this, or had system design teams tilted towards bellhead decision-making.

Cisco has all the cool toys for queue management in their routers. Are they bozos? People who have even skimmed the Linux traffic shaping HOWTO are sensitized to the issues. They're not bozos.

I have a copy of the first edition of Comer in front of me (the 1988 one that talked about the inevitable transition from TCP to OSI TP4.) The advice to implementors of gateways tells you to read RFC 1009 very carefully, which has a bunch of congestion cites, including John Nagle's (he's downthread) RFC 970 explaining why infinite buffers are a disaster. These are foundational documents of the Internet, and sure, they're from 1987 and routing to a T1 by processing over 9,000 packets a second is no longer something you would need a supermini for (you probably get faster computers free with your breakfast cereal.) But scanning forward through the RFCs you'll see lots and lots of very pointed advice to the effect of "please do not confuse TCP or you'll be sorry."

So some of the people building the network hardware with these problems weren't alive when this was being figured out. They didn't do their homework; fine. The people running the companies designing and building the hardware don't have that excuse, and it was their job to either get a clue or hire one. Their customers are going to be the ones paying to fix this.

So if you're buying Internet infrastructure, you might want to look for companies (and more particularly, product groups) hanging out on nanog and participating in IETF, since although that's not proof their products are not fighting the Internet, maybe it correlates.

My current guess is that organizational decision-making was tilted towards bellhead thinking for a variety of reasons (stereotype: they dress better and do nicer PowerPoint architecture.) Skimming through documentation of bearers such as 1xRTT makes it pretty clear that the design center was "reliable pipe first, then put packets on it." Which makes perfect sense if your company has history in non-Internet telecoms--your senior people are the ones who shipped products that did reliable circuit-switched pipes. But that's just wrong if you're doing IP, and for reasons known in the Internet communications world for decades.

I've been trying to figure out whether I wanted to link some version of this to the blog posts. I figure it's safely out of sight here and won't interfere with the public diplomacy.