wreckimnaked

nice work!

one minor suggestion: I couldn't find any reference to the timezone used to collect/display the data, therefore I was unable to have any deeper insight from your awesome visualization. Could you make that information clear on the visualization or the info page? ;)

TL;DR: after establishing an almost undisputed OS monopoly through OEMs in the Americas, Europe, Asia and Oceania, Microsoft is now looking forward to also trap most users from Africa on their first computing experiences by selling them refurbished cheap smartphones and PCs running an insecure and patchy OS under the umbrella of pushing development forward for their own good.

I wouldn't like to play a game of Risk with those executives.

Way too fancy. Why not a single link with no animations or mouseover events?

nice idea! I only missed a link to the related wikipedia articles for each entry.

Nice idea!

Also, some metadata aggregation (title, author, tags, date published) capabilities wouldn't hurt anyone.

I'd say that the choice of Linux over BSD on those cases has to do with hardware support. Writing drivers and supporting a wide range of devices would increase up a lot the development time for Chrome OS, for instance.

Embedding Javascript is fairly easy with Qt[1], so I assume that many applications built on top of it may use it.

1: http://doc.qt.digia.com/qt/qdeclarativejavascript.html

I'm also an early adopter: I have 8 users for free. I also always thought of the free plan of Google Apps as a deal too good to be true.

Nice post; it'd be even better if the content displayed (a db seed?) was the same, making comparisons easier.

They can. Some people just need to put more effort on it than others.

I refuse to believe in such an argument that some people just can't do something. Some people just need _more_ time to get around the art way of thinking. In the case of music it maybe has to do with lack of early (as a child) exposure to more intricate music forms.

More complex programming also involves the grasp of a not evident way of thinking, so carrying on with your argument some people just can't understand why it doesn't work as expected.

When comparing the Intel 64 [1] and ARMv6[2] instruction sets that's a quite trivial assumption. The difference on the number of instructions implemented by those architecture reflects well the complexity gap between both.

Also, there are many other details that make targeting ARM much easier, for instance the bootloading process on ARM is more straightforward with no BIOS or EFI involved[3].

1: http://download.intel.com/products/processor/manual/325462.p...

2: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

3: http://www.keil.com/download/docs/52.asp

> How to handle Interrupts in C? Will they perform as callbacks that await some return values or do I have to use inline assembly to process them correctly;

Not to disappoint you, but you should try doing some more low level programming or dabbling with some existing OS code to have an idea how this kind of programs look like. Maybe having a look at Minix for a reference of simple OS?

Have you thought about targeting ARM? Its architecture may be way less trickier than most Intel CPUs.

Well, good luck with that. Worst case scenario, you'll end up reading lots of interesting resources.

People tend to think that everything that Apple does is part of some kind of masterplan. They're humans too, and this is clearly a feature missing on their development environment.

just read the reddit discussion. I'd say that MPD is more UNIX-y than your approach for a music player; still I appreciate your effort to build well defined requirements for your project

Awesome! Didn't know about those, thanks for the tip.

What about MPD? Most of the describe features/requirements are already there.

It would be really interesting to have one of those, a physical building with proper archiving and curatory.

About the fear losing our knowledge of good and bad practices, open source software itself can serve that purpose, most major projects being well documented with both development manuals and discussions from the community.

At least the food on the Indian AC trains is not that awful.

Last time I configured Infinality I remember the example config file being very well explained about the possible options. Try installing it and reading your /etc/profile.d/infinality-settings.sh

> Artists, writers, musicians, engineers, carpenters

You should draw a clear line between those professions. All of them are "producing" professions, but the first group (artists, writers, musicians) do not have to maintain the technical responsibility that the latter (engineers, carpenters, programmers) has to.

This _technical responsibility_ brings a lot of the "negative" said on the article; actually, that's not "negative" it is "not good enough".

Lua is very popular with most game developers.

Nice idea. Maybe a zoom-in / zoom-out control would be interesting for gameplay.

I don't see how Python docs are terrible. Any doc is a help() away from you on any REPL.

Awesome! I'd be happier moving around using WASD keys.

Well, scipy/numpy is quite relevant in the Python ecosystem; it's not something you can ignore when talking about the language. Like Rails to Ruby, numpy is quite a big feature of Python.

Lush really seems pretty neat, actually your post motivated me quite a lot to take a closer look at it.

The habit of disdaining something that recently gained a considerable amount of popularity.

I agree with the article and the author seems like a reasonable and experienced programmer, but the Common Lisp comparisons just felt like hipsterism to me.

Indeed. My main point was that programming C requires more knowledge about the "layers" underneath its execution than higher level languages such as Ruby.

This article is OK when defending the "right tool for the right job" statement in the middle of the present Clojure hype that is going on, but this perfectly coherent discussion just gets swallowed by the author's apparent underground syndrome.