Even in the realm of "GNU/Linux" not everybody uses bash (some use zsh, for exemple).

And that's only the portion of users running an actual "GNU" userland.

Then you have the embed world using Busybox (with uClib, etc.) and co for the userland (which has its own simplified shell).
And then you have Android (which runs a completely different user land by Google, like Bionic for a C library, a different message passing bus, and most of the things usually handled by deamon running in userland, handled by java-like code on a java-like VM).

And the other way arround: you have other Unice (OS X, various *BSD) which obviously do not run Linux kernel, but do run bash.
OS X, for example, was affected by bash.

such things were also reported by people who got caract surgery. Some type of replacement synthetic lens were more transparent in the UV and suddenly people started to see UV. (Some replacement were way too much transparent in the UV and could damage the eye by not protecting it enough).

Both are "UV" in the sense that they are above the violent band. But they're not the same wavelenght.
Blacklight UVA: is just slightly above the the violet band, with wavelenght shorter than 400nm
Germicidal Lamps UVC: is way above the violet band, with wavelenght around 280nm (e.g.: around wavelenghts most likely to be absorbed by DNA and other critical biological structures - thus damaging the germ cells).

Cones can detect UVA (it's just usually blocked by the eye's len).
Cones cannot detect UVC (and would probably just die if exposed to it).

With OE, sniffing data doesn't work.
OE will encrypt the tiny bit that interests you, in the middle of an otherwise plain text connection.

So by simply passively listening to packets, you won't be able to gain access to the juicy parts, they will be the (only) encrypted part.

OE can prevent incident like google car which recorded sensitive information while logging data packets from non secure Wifi. Or attacks like FireSheep passively listening to clear text cookies in a internet café

But currently OE apparently lack any authentication scheme. so it's trivial to throw a MITM attack.

OE isn't competing as being an alternative to HTTPS. (Https is the real deal if you want security).
OE is trying to be a tiny bit better than plain text over HTTP, and currently is a little bit better at preventing accidental eavesdrop.

Which CPU are you talking about?

The huge power hungry multi-core x86_64, optionally assisted by massively parallel GPUs (running opencl) that sits on your desk ?
well decoding high res video is a walk in the park.

The small diminutive ARM designed to be as power efficient as possible that is in your pocket?
much more problematic. it won't pack enough power for higher resolutions, and in the cases were it *DOES* manage to code the video real time, it's going to kill the batter really fast.

The situation of VP9 isn't that different than H.265
- desktops work well enough even without dedicated acceleration
- smartphone are limited by the current lack of acceleration (well except the few latest phone which slowly start to get H265 hardware) due to CPU limits and battery life.

The problem is that currently you can go to the nearest dealer and buy them.
They don't exist yet. There are just prototypes being developed here and there.
They need to be developed (which requires having a huge database to learn from).

Also, the problem of buying car from another company (say Google if their robo car is the first to be mass produced), it that Uber would become dependant on Google's whim. If their future business model rely on a service powered by robo cars, it would a bit risky to entirely depend on an external company for said cars.

The point of Uber, apparently, is to beat others in the development of autonomous cars. Not to depend on anyone else. Make their own robo car business.

And they have a similar mass of useful data out of which to build the car's intelligence. Which was graciously provided by the hipsters using the service, who never consented to be part in an AI research in the first place.
The kind of data log that used to enable the controversial god-mode, can also be used to build a very precise model of "how are the driver managing to navigate inside city centers ?"

From what I understand how this is supposed to work, it's the opposite:

I think it's: you type a simple *http* address, the website behaves like a plain normal one. (so no https address, nothing misleading you into thinking you are using secure https website)
But when you submit data to it, the browser will automatically switch on-the-fly to an alternate, encrypted route, so the data is sent encrypted to a alternate destination handling encryption.
It's not a full blown https, but it's better than nothing.
Think of it as "https-lite" for sending data. Designed for server which can afford having a full blown https stack.

Except, that the thing is so much simplified that there aren't enough checks in this protocol. So a third party could use the feature to re-route data to their eavesdropping infrastructure, instead of re-routing it to an encryption feature on the original http server.

My "portable online life" has been an Ericsson T39 (that outlast it's intended time by decade)
combined with successive models of PDAs from Palm.
Add in foldable keyboard for the PDAs and you get a small laptop replacement.

Only started using smartphone when switched to WebOS powered smartphone by Palm.

The combo has a few advantages:
- better life battery
(phone is very efficient as it doesn't to much beyond being a phone. It's as simple as you can get, and can last a week on a charge.
PDA isn't constantly online and thus is also low energy requirement. specially the older one could last a long time between charges)
- separate PDA used to be more offline oriented (think google maps over 3G/4G vs. dedicated map application with locally stored maps. very useful when you travel abroad).
- redundancy (typically, one would sync contacts over bluetooth or irda between the 2 devices. If one dies or gets stolen, the other is till working).

Feature phones as old as the Ericsson T39 (note the absence of "Sony" this old piece predates the merger) were already able back then to work as GRPS modems over infrared, bluetooth, or USB (but the USB cable was expensive and rare, so bluetooth then).
And this antique only has a couple of text lines on screen.

Note that feature phone used to have cameras too. Feature phone introduced camera before even smartphone where started.
Same goes for a lot of other things you mention (email, games, alarm clock, calculator, etc.)
I think games and alarm are the two first features built into phones.

Partially solved by several techniques. For example, one available backthen on the a fore mentionned Ericsson (still available on all subsequent Sony-Ericsson feature phone) - volume rocker works as a kind of "shift" key. Using combination of volume + number gives you directly the letter you want instead of repeatedly pressing a letter. Gets a bit time to get used to it, then works as fast a typing on a keyboard.
Some provided external keypads (again Ericsson had a "chat board": full qwerty keyboard), if your finger arent's too fat, it's fast than a virtual keyboard.

The whole MP3 craze began much earlier before Apple re-invented it with their brand of players. As soon as MP3 player stared being popular, phone started offering the function, some phone even had a dedicated separate physical interface for that. Close the clam shell: you have buttons and a small monochrome screen to handle playing your music. Open the clam shell: feature phone with color screen.

Can you actually think of a phone that DOESN'T have a lit up screen? People have been using it as improvised sources of light for as long as I can remember.
The only thing brought by modern smartphones is *white* light (as they can abuse their flash for that, where as old monochrome phone screen tended to have blue, green, orange, etc. backlight color).

8k iMac: depending on the specs of the iMac, that might means that they have managed to increase the pixel density (high DPI).

8k in it self doesn't mean anything. You have to factor in display size, viewing distance, etc.

And there is ONE FIELD that is going to benefit immensely from higher densities: VR!

VR is typically a field of application where you are viewing a relatively small screen (Occulus tend to use typical smartphone displays. Older VR headsets like eMagine 3D visor had even smaller display, like a finger's nail per eye) from a very short distance. (Just next to the eye ball).

Even at the current ultra-high resolution/pixel densities, that are over kill for a normal smart phone screen (1080p FullHD in a smartphone is more than 300DPI), when looked that close still is very pixelated (this FullHD is blown up to cover your *entire* field of view. That end up being not that many pixels per angle of view, even if keeping into account the varying resolution due to the simple len's distortion). (= Unlike older VR headset that used simple rectangular screens to convey a simple rectangular picture and relied on complex and expansive optics to keep the rectangle distrosion free, Occulus rift use a very simple (and cheap len) that completely distrorts the picture and compensate using a shader that draw a "pre-distorted" picture on the display. They don't convey a rectangular picture, but a pin-chusion picture with more pixels spent at the center than the periphery - thus higher resolution in front of you. Still pixels are visible).

So even if it ends up being overkill for the iMac, increasing production of high density displays has nice side effects on the occulus rift.

Question: How do you jump start research into car robotics when you're not Google and thus don't have a huge mass of knowledge about all the roads gathered by your google cars and google maps program ?

Answer: You get a ton of hipster to drive for you, record their trajectories/behaviours (remember "god mode" ?) and use their knowledge as a starting point to populate your initial database.

Come to think of it, Palcohol shouldn't get attacked in the US in the name of protecting children from booze.
It should be attacked for false advertisment:

"Power alcohol" isn't powdered alcohol. It's a fuck ton of useless sugar powder with a tiny bit of ethanol sprinkled in.

It should be called "Powder+alcohol".
Or "Powder Sugar (may contain traces of ethanol)".

We're still years before selling actual robo-cars.

Still, lots of car makers are packing radars and cameras in the cars. To be used as lane tracking, collision avoiding, etc.
They are sold as extra feature, and work (legally and in terms of responsibility) as form of more complex adaptive auto-cruise (it self just an evolved auto-cruise) as the cars in generation before.
The driver is still the one who is theoretically in charge of the car. Except that now the driver get a big bunch of electronics to watch out and assist

There is a real reason to pack more of it: featuritis! Now auto-maker A can boast that their car does even that few things B & C that the other auto maker aren't doing yet.

One is producing over priced pocket computer, sold a trendy and hip way to get distracted by checking twitter, and posting annoying fb status updates about your health.

The other is an over priced piece of micro mechanics sold as a substitute of jewelry (the origin of the boom of switch watches).

Smal LED screen vs. small piece of gold.

Yeah, confusion is very likely.

Trust me, it's okay. Been there, done that. And basically any plastic bottle would to the job. If you're afraid that the space-age-plastic lining inside your collapsible sport-gear hitech bottle would react badly to ethanol, well just take a simple soda/soft drink/water/whatever bottle: any used 33cL or 50cL bottle will do the job, no problem.

As opposed to carrying a few kg of powdered sugar ?!? Do the math again: either you use a small plastic bottle filled with standard 40-60% booze (or 75%-95% aka 150 to 190 proof in your units - of everclear. If you live in a country where those things are easily sold).
Or you carry the equivalent of several packs of sugar powder, several kg ?!

Yup, you're not loosing volume and weight to a little bit of water that can't be used for drinking.
Instead you're losing volume and weight to a fuckton of sugar polymers cycles. Which basically are just as useless to rehydrate you as the water mixed in the alcool.

Or if you only want to take only a reasonnable amount of powder, well great for you, but that's basically equivalent of a very small plastic flask (the kind that are sold for transporting liquids in airplanes. or the kind in which you get test samples of think in drugstores). Which is really negligiable in size.

Go back to my quick math. For the equivalent of 1 AA battery worth of ethanol, you need to add a few times more volume (1 deck of card and a half) of powder.
Even if the ethanol is diluted 1:1 (because that the highest you can get, welcome in Europe), it still *way much more* space saving and weight saving than the powder. Not as in "we're a few mg better", but "it's a fraction of the place that the powder takes".

For me it's a no brainer.

That's basically a plastic bottle. It's as simple as it can get. Mass is negligible compared to the content. Comes in various size (big range of capacities. Small 100mL flask sold nearly every were as a mean to transport liquids on airplanes within allowed limits. Standard 33cL and 50cL bottle of water and soda, once empty recycle it to transport your booze). They tend to be rather solid.

Also, ethanol evaporates easily. In case you *DO* manage to damage the container (like falling with your back pack on a pointy rock) just let it dry.

(It's pratical experience transporting 60% grand-pa-distilled brandy in plain plastic bottle)

Power: you'll get either a big pack (think pack of flour or sugar) which might leak in a backpack. Or you'll get a carton with individually sealed small bags (think like individual teabags) which adds even more inefficiencies (as if the huge mass of powdered sugar isn't enough).

(Again, pratical experience with chocolate powder)