ttuominen

Luddites weren't against technology. “They just wanted machines that made high-quality goods and they wanted these machines to be run by workers who had gone through an apprenticeship and got paid decent wages. Those were their only concerns.” https://www.smithsonianmag.com/history/what-the-luddites-rea...

Exactly. The OP correctly argued that libre practically implies free-as-in-beer, but I think the point of the distinction is to argue that free-as-in-beer doesn't imply libre. So it's a useful distinction.

I must say your blog seems like a an excellent resource, thanks for what you are doing!

I've found emacs-fu useful. http://emacs-fu.blogspot.fi/

According to the article, that's just part of it. They specifically pointed out cases where identical resumes with different names yielded different outcomes. (Where the names had strong associations with different ethnic backgrounds.) Now, statistically, different ethnic backgrounds will have an effect on people's lives, but for an individual, the parent's question might still be relevant.

This reminds me of the time I bought an old 1972 issue of Rolling Stone magazine on eBay to be able to cite the Spaceware article (also available online) [1] in my bachelor's thesis on Smalltalk as evindence that the culture at Xerox PARC was somewhat unorthodox in the seventies.

[1] https://news.ycombinator.com/item?id=5548719

Android also has decent command line tool support and a build system based on Ant. I'm not a huge fan of ant, but the default setup works all right and is extensible. I've mostly managed to stay inside Emacs for Android development.

PythonTurtle (haven't tried it though) https://github.com/cool-RR/PythonTurtle

It should be noted that globally, fossil fuels are also heavily subsidized. [1]

[1] http://www.washingtonpost.com/blogs/wonkblog/wp/2013/03/27/i...

It was just a good excuse to talk about our favorite games. I haven't played any of the Double Fine games yet, but to my knowledge they haven't made any classic point-and-click graphic adventures - before the kickstarter-backed Broken Age that is [1]. I hear the old talent is still evident in the DF games though, and they seem to be story and character based.

[1] http://www.brokenagegame.com/

Yeah, gameplay wise they're like manually solving a makefile's dependencies. Of course we know the whole point is not in the structure of the solution but in the written content of the story. It's in the way the game world starts living inside the player's head, where all of the action is. I remember thinking about some FOTA puzzle during a bus trip for several hours without even having the game available.

I also read it, and I think you summarize it well. I'd like to add that the author's main aim seems to be in revealing a strong technocratic tendency underlying O'Reilly's thought. The technocracy is shown for example in the naive assumption that political decisions can be calculated algorithmically with enough data and intelligent algorithms. According to the author, O'Reilly hides the political claim that small government is good behind technological newspeak about governments providing only the essential APIs for the private sector to build on. In coining new terms for old ideas he is ignoring the vast literature of political and philosophical thought discussing these matters and gaining the support of hackers for a political agenda. And, most importantly, dismissing tough ethical and political decisions by claiming that government is some kind of an optimization problem.

I'm not sure if he convinced me regarding O'Reilly specifically (haven't read O'Reilly enough), and I agree with others about the repetition and bad style ("crazy talk"?). But some actual thoughts were hidden in there.

For CPU profiling, the Android Open Source Project includes both oprofile and Linux perf tools in the source tree. You would need to compile your own kernel and Android to include them. Some options need to be set in the kernel config to enable support for processor hardware events for profiling. Additionally, you need to compile the profiled code in ARM mode instead of Thumb for perf tools to be able to unwind the stack traces. Oprofile might work without kernel hardware support, I'm not sure.

I don't know about shader profiling. GDB is apparently supported for debugging, haven't used it: http://www.kandroid.org/online-pdk/guide/debugging_gdb.html

EDIT: By the way, depending on the accuracy you require, you might want to take a look at this poor man's profiler that Mike Dunlavey has been advocating: http://stackoverflow.com/questions/375913/what-can-i-use-to-... It doesn't require compiling the operating system, you can just send a kill signal to your process multiple times and examine the stack traces from the logs. It may or may not be enough for your needs.

You're right, and I have to clarify that I don't necessarily agree with the idea that new display technology is the real cause of this new trend. But I do think we will be able to get better results from simpler, minimalistic designs with better resolutions.

Trying to make the best out of the argument, I think you could put it this way: discrete, identifiable vector-like shapes with sharp edges (not only straight rectangles but also rotated ones and other shapes - he also emphasizes typefaces) do require a sufficient pixel density to look good. Skeumorphic photo-like bitmaps fool the eye by hiding the low pixel density using low contrasts between pixels (with natural looking gradients and anti-aliasing). I'm reminded of this when I look at classic 2D video game graphics from the nineties, they make this style really apparent. If it was only about flat rectangles, I'd agree. But I also think this seems to have really started with mobile Windows and the flat single-color rectangles.

Many features, not all: https://lwn.net/Articles/514901/

This, and also Android's overall userspace design is kind of idiosyncratic. I'm sure there are other legitimate designs of a Linux-based mobile OS, which don't rely so heavily on Java and a virtual machine. Ubuntu will be Qt-based, for example. That throws out the possibility to reuse the Android application framework.

I would absolutely love to see Ubuntu and others (Jolla) succeed. Unfortunately I'm also highly skeptical they will. The reason is that currently their marketing story seems so far removed from actual consumers: think about the fact that they're even trying to sell the idea of an operating system, not a complete product. This seems really backwards compared to the evidently successful Apple model. Granted, they are probably having discussions with manufacturers right now, but we'll have to wait for the results. I'd be happy to hear somebody refute this argument!

Minor point, but technically a JIT compiler doesn't replace an interpreter. The latter is still there (written in assembly nowadays), and the VM has to trace hotspots and balance the cost of run time compiling vs. the cost of normal interpretation. Of course a JIT code cache helps to avoid the compilation overhead.

Yes, and QML (declarative syntax + Javascript logic) for UI-heavy parts or even complete apps. http://en.wikipedia.org/wiki/QML

I agree: within the Android ecosystem and even within the ARM family, bytecode provides portability: you don't have to compile and distribute apps for different versions of the ARM architecture.

It's paradoxical however that to increase the portability of certain types of apps across mobile ecosystems, eg. iOS and Android, and now Ubuntu, your best bet can be to write the portable part in native C or C++, bypassing the Dalvik layer using JNI/NDK. This is apparently the common way to make cross-platform mobile games.

On memory consumption: I haven't made any measurements, but the Android .dex bytecode format has been designed with low space requirements in mind. See http://www.youtube.com/watch?v=ptjedOZEXPM . However, all apps run in their own VM process, with lots of common structures shared with them using an initial shared VM process and clever forking.

I always thought one of the main original motivations to use Java was because it's so well spread among developers. Since in the early days before the JIT compiler, there must have been a really obvious overhead even with the interpreter hand-coded in assembly. But they must have wanted to use a well known higher level language with good IDE support etc.

Ubuntu mobile apparently uses Qt: "It uses QML to give you a really slick, easy development experience for native apps with engines in C or C++, and JavaScript for UI glue that isn’t performance critical. We also give you full native OpenGL, which the top games companies are using to make incredible games." It seems actually pretty nice for developers: http://developer.ubuntu.com/get-started/gomobile/

My sources tell me that Busybox is actually not included in at least vanilla Android. Not in the AOSP tree at least (just checked (v4.1.2)). I'm not sure if OEMs have included it in actual products, but why would they have? I might be wrong. There are separate installers available to get Busybox on a rooted Android device. https://play.google.com/store/apps/details?id=stericson.busy...

They have a version of the Ash shell, Berkeley licensed, with the original notice by Kenneth Almquist. The Busybox Ash is also derived from the same origin.

As others have pointed out, they also have their own libc.

Most of these decisions seem to have been made to avoid using the GPL outside of the kernel. And a custom libc seems to entail that patches have been necessary to enable some of the standard GNU based tools they do have. If I understand correctly, mainly because of Bionic, you often can't just take a standard piece of Linux userland software and make it work without modifications or without including the GNU libc.

Also because of avoiding the GPL, the hardware driver model is different, with most of the driver logic being in closed source userland code.

The filesystem layout is non-POSIX-like, the way the user accounts and processes are handled is non-standard, they have their own dynamic linker, etc. Not to mention that a large part of the system relies on their Dalvik (Java) virtual machine, with a large application framework implemented in C++ and Java through JNI.

I'm not familiar with the embedded Linux landscape, so I don't know if this heavy avoidance of the GPL is common there. But I do know Android does not resemble GNU/Linux for these reasons.

Android is far from a typical Linux distribution. In addition to custom kernel features (see https://lwn.net/Articles/514901/ ), most of the rest of the system hasn't got anything to do with GNU or GPL and is structured very differently from a typical distribution. O'Reilly's "Embedded Android" is a great source on Android internals.

I'm not saying Android isn't good for Linux. I also do appreciate the ability to read and learn from the source code and modify it.