The article is mainly about using telepresence and computers to pilot a ship. But other than piloting, what else do humans do, and how automatable is it?

For example, how often do people have to repair ships while under way? During a storm, do people ever have to run around fixing chains that are working loose, or fix a leaking seal and set up pumps to pump out a flooded compartment?

I don't know the answers to the above questions, by the way. I don't know much about cargo ships.

Even if we still need humans for some tasks on a cargo ship, perhaps not too far in the future, we might have telepresence robots that can do the tasks.

Now I feel silly. In my P.S. I said he missed my biggest peeve, when actually he started his rant there. By the time I reached the end of his rant, I guess my tiny brain had already forgotten it.

So feel free to point at me and laugh. Sorry about that.

There's an old saying: To gain knowledge, add something every day; to gain wisdom, get rid of something every day. I'm not sure exactly how that is supposed to work (where does the wisdom come from?), but clearly you can choke your life if you accumulate too much stuff.

And that's really true for mobile apps, which can choke your phone. Two years ago my wife's phone (Android 2.x) became unusable, and I discovered that she had installed five or six dozen free apps, and many of them had installed service daemons. (Why do workout tracking apps, cookbook apps, or lightweight games need daemons?) She made an effort to purge down to just the apps she needs.

Even if you assume that the phone can handle all the apps, they still add chaff for you to sort when you are looking for the app you actually want to run.

P.S. Jeff Atwood's rant was good, but he missed one of my pet peeves: I will click on a news story link in a blog or Slashdot or something, and the linked site will pop up a banner: Hey! Don't you want to install and use our mobile app? Why no, web site I have never heard of before, I really don't want to download and install your app. I just want to read the one story, and at the moment I'm reconsidering even that.

I'm not a video expert, but I did write an H.261 codec once.

I don't think it's practical in a VP9 decoder to save time by cutting quality. The Huffman decoding stuff all needs to be bit-exact. The DCT is pretty standard; you would just get a fast implementation of DCT and use that.

I suppose you could sleaze the mixing and filtering steps but the results would probably be so horrible that nobody would want to see it... part of how video decoding works is to refer back to previously-decoded images. The way "motion compensation" works is to say "this block is like this other block over here, but moved over by x pixels horizontally and y pixels vertically and with a few pixels updated". This means that if you sleaze the decode, it can have an effect on later frames.

(H.261 could only do motion compensation that referenced the previous frame. VP9 has 8 different reference buffers and any one frame can encode references to up to three of them! And they'd all better contain properly decoded images.)

So, my guess is that they just did a great job of tuning their code and the quality is good.

Also, the spec says that VP9 was deliberately designed to enable parallel decoding; maybe the FFMPEG implementation takes advantage of that. See section 3.2.1, "Frame-Level Parallelism".

http://tools.ietf.org/html/draft-grange-vp9-bitstream-00

I didn't think it was really strange, but a while back I saw some desktop computers running Firefox on Ubuntu in a coffee shop. This was the old GNOME 2 desktop, so it worked almost exactly like Windows, and the customers in the coffee shop just used the computers and it wasn't any big deal.

I have set up multiple family members, including both of my parents, with Linux computers. I seem to be the guy who gets called when a computer melts down with malware, so I'm motivated to get people off of Windows and onto something else.

These days my go-to distro is Linux Mint with MATE. I might switch back to Ubuntu once MATEbuntu is available... on the other hand, I have hopes for Cinnamon, so maybe in the future I'll be using Linux Mint with Cinnamon.

But for non-geek users, I definitely don't want a poor rip-off of Mac OS X (i.e. Unity) and I definitely don't want the desktop that is just different from anything else ever made (GNOME Shell).

The MATE desktop has the smooth polish of man person-years of work and the input of usability studies, and it's IMHO the best choice for non-geek users.

According to TFA, this will be a huge photovoltaic plant. But as I understand it, solar thermal is more efficient, and for a large centralized project like that, I would have expected solar thermal.

http://en.wikipedia.org/wiki/S...

Does anyone know why they are going photovoltaic for this project?

Photovoltaic certainly does have some pluses: it's simple, no moving parts. But for a project of this capacity I should think they would go for the most efficient solution.

Plus a thermal solution with molton salt would provide a nontrivial amount of storage, for power after dark.

So, what am I missing? Does India have lots of factories making photovoltaic cells or something?

Linux still needs a baseline distro for developers to target.

I think Linux has one now; it's called SteamOS. I've said this before:

http://games.slashdot.org/comments.pl?sid=4252825&cid=44926779

John Carmack has talked, in the past, about the insane difficulty of packaging games for Linux. There are so many distros out there. Well, SteamOS solves that problem.

I predict that game developers who support SteamOS will not accept bug reports filed against any other distro; instead they will tell the user "it runs fine on SteamOS, so tell your distro it needs to get compatible."

I am fine with the above, as long as SteamOS is free and open. Well, it is. So I think this is the best possible news for Linux gaming.

Using the "wayback machine" feature at archive.org, we can look at old GNU web pages.

Here is a link to a January 2007 version of a GNU web page that describes the "License of Guile".

https://web.archive.org/web/20...

License of Guile

This consists of the GNU GPL plus a special statement giving blanket permission to link with non-free software. As a result, it is not a strong copyleft, and it is compatible with the GNU GPL. We recommend it for special circumstances only--much the same circumstances where you might consider using the LGPL[1].

[1] In the original, the word LGPL links to a page called "Why not LGPL". Here is an archive.org link that goes to that page as it was in January 2007: https://web.archive.org/web/20070105122245/http://www.gnu.org/philosophy/why-not-lgpl.html

So nobody pitied your choice to agree to prevent users from controlling their computers ("I once worked on a project where part of the technology stack came with a legal requirement to take steps to prevent customers from reverse-engineering").

Well, it's not as if I asked for pity from anyone, including you.

I worked on a consumer-electronics device that happened to have a cheap embedded computer inside it. One feature was to play DVDs. So yes, my soul must forever bear the black stain of having worked on a DVD player that legally licensed the technology to unscramble the CSS protecting DVDs. (You know, the dark secret you can buy on a T-shirt. But go figure, large companies would rather sign a legal license than be sued.)

And nobody pitied you complaining that you couldn't find developers who were willing to be taken advantage of themselvesâ"giving you code in exchange for nothing ("so LGPL was just as radioactive as GPL").

There's that "pity" word again. Where did you get the idea I was looking for some?

We couldn't use LGPL code. So we didn't use the LGPL code. We used something else. I'm not crying about it. I'm sorry that I seem to have upset you so badly.

Or perhaps it was your namecalling (code licensed to not let you hurt others is "radioactive") that helped drive them away.

I apologize for not writing dry, lifeless prose that is inoffensive to all. But I don't apologize very much. I think most people understand that "radioactive" is just a metaphor that means, in this case, "must be avoided".

So, a question: in your mind, selling a DVD player to a customer is "hurting" the customer?

Tell me, I'm curious. Microwave ovens contain embedded computers. Modern cars and digital watches and pocket calculators all contain embedded computers. Do you have source code for all of those embedded computers in your life? If not, do you only drive cars from the 1970s or older, only use a slide rule and an abacus, only wear mechanical watches? In fact, do you own a device that can play DVDs?

Do you feel that the guys who wrote the embedded software in these things should feel guilty over all the "hurting others" they have done?

Do you think that I should feel guilty for working on a DVD player?

It appears that the Guile license situation has been simplified: Guile is now LGPLv3.

In the past, Guile was GPL with a "linking exception". I found a Wikipedia page about this, which still mentions Guile as an example.

http://en.wikipedia.org/wiki/GPL_linking_exception

But isn't that why libraries are (or should) be licensed under the LGPL, so that there are no "viral" issues? You're not even allowed to link to an LGPL library?

RMS doesn't really like the LGPL. The first L used to stand for "Library" but these days it stands for "Lesser" to indicate its proper place. RMS would rather all libraries be GPL. (Of course, RMS would rather all software of any sort be GPL.)

https://www.gnu.org/licenses/why-not-lgpl.html

LGPL actually contains some strange provisions that can be a deal breaker. For example, LGPL requires that you take no steps to prevent your customers from reverse-engineering your software. I once worked on a project where part of the technology stack came with a legal requirement to take steps to prevent customers from reverse-engineering, so LGPL was just as radioactive as GPL.

IMHO, LGPL is not a good license and should go away. It should be replaced by the GUILE license, which is simply GPL with an exception: linking the library does not in any way invoke the viral GPL features. So, if you fix bugs or add features in the library, you must share your code so other users of the library gain the benefit; but you are free to link the library with proprietary software if you wish.

The above will not happen, as RMS and the FSF consider the viral aspects of GPL to be a feature.

For software, the marginal cost of distributing the extra features disabled is pretty close to zero. It's all just bits being copied.

For a car, the car maker is still paying for the seat heaters, still paying factory workers to install those heaters, but not always being paid back by the end-user. Makes no sense.

And as a consumer, I want a simple and reliable car. I don't want my seat heaters to have a "DRM AUTHORIZATION FAILURE" error message and refuse to work when I need them.

My impression is that the most expensive part of the car are the batteries (probably costing more alone than a low end Honda)

As I understand it, yeah, the most expensive part is the battery. Electric motors are not that expensive.

I'm pretty confident that battery costs will come down significantly. Even if no significant technology advances come along to help, battery costs should come down as demand picks up and production scales up.

http://tech.fortune.cnn.com/2013/11/04/electric-car-batteries/

An electric car has a major up-front cost, but then low cost of operation (electricity is cheaper than gasoline) and low cost of maintenance (electric cars are simpler than conventional cars: no transmission, no radiator, etc.). If fracking hadn't driven the cost of gasoline down, electric cars might be in higher demand right now. Especially where I live, because we have cheap hydro electric power.

Tesla cars are really expensive, but they keep doing things like this. "Worried about the battery catching on fire? Okay, we will insure you against that for no additional charge. Worried about your garage charger catching on fire? Okay, we will give you an upgraded charger for free."

Anyone with a Tesla car is an early adopter, and paying a lot for the privilege. But Tesla really is doing their part to take care of the early adopter customers.

And this is why their overall strategy is brilliant. Start at the high end of the market, make money while building technology and infrastructure, and then come out with a new-gen car that costs less. Meanwhile they have fewer customers to take care of when issues like this pop up, and they have the money to just deal with it.

I can't wait until Tesla hits the Ford/Honda price level.