johanbev's comments

Contrary to some sibling comments in this tread, I'll recommend getting the type of guitar that you want to play to learn on as well. There are several kinds of guitar. The three most distinct types are classical guitar (nylon or gut strings), acoustic (steel strings) and electric guitars, which again can be divided into hollow and solid bodied types.

All these istruments are pretty different, both in physical appearance, sound and of couse also playing technique, required skills, reportoire and so on. Of course, if you are really good at one you can pick up another type more easily. However, the guitars sound and play so different that it's impossible to get good at electric guitar by only practicing classical guitar. All these types of guitars are really distinct instruments.

If you want to play electric rock, get a strat or tele of maybe even an LP. If you want to play electric jazz, get an electric hollowbody guitar. If you want to play folk-rock singer-songwriter or country types, get a steel stringed guitar. If you want to play classical guitar, get a classical guitar. I've seen countless of times people being handed cheap classical guitars when they want to play like Bob Dylan and Neil Young (etc) do. The result is almost always that the guitar goes in the closet after a few weeks and the interest dies down, which is pretty damn sad.

More expensive guitars will likely be much easier to play on and might sound better. However, I woudn't recommend spending great amounts of money on your first guitar. It is certainly possible to get great guitars for less than 1000$.

Most heavily optimizing compilers do strange things to the code. You wouldn't want to debug an -O3 program, just as you probably wouldn't want to debug with TCO turned on.

Luckily, in the lisp and scheme families (possibly also other image based PLs), it's easy to mix compiled (and optimized) and interpreted code. Whenever i run into a bug such that i need the debugger to fix it, I always replace the compiled function with an interpreted version first, making it much easier to debug. What you get in the stacktraces is the same as you read on the screen.

In most lisp implementations, this maneuver can be performed completely on line, you don't have to restart the program or recompile anything but the function under inspection itself. When the runtime signals an exception or fault, just tell lisp to interpret the suspect function. Then move up the stack to the function that called the suspect, and restart that stack frame et voilá, bob is your uncle.

I have to admit guilt here :-) Nice that someone found it too. +1 for GEB.

While the author talks about free software in general, it seems more to me that he really means Ubuntu and Unity and perhaps common desktop applications found in that "ecosystem". What's the usability of bash? GCC? Emacs? And perhaps more importantly, for whom is the usability measured? The linux-ecosystem is mostly used by programmers. It's natural that the user interfaces tend to reflect this. One of the main reasons i have linux on my computers is exactly this, I really don't want the user interfaces of Windows or OS X.

Problems and solutions are described, but exactly _how_ to implement these solutions isn't stated very clearly, and I'd hesitate to call these suggestions "solutions" because, to be brutally honest, it's all empty talk.

Furthermore I feel like many of these solutions come at odds with the foss-culture in general. If I'm giving away my time and code for free, I really don't want a project manager or a designer to tell me what to do. I'm going to do what feels interesting, or I'm going to implement features that I need. If someone else can use my code too, then that's great. If not then that's ok too. To me it's strictly hobby basis. I don't get wages, and I don't have "customers". I'll contribute because it's fun or because I want to honor the idea that I should contribute back changes and improvements I've made to software that I got for free.

Of course, this could be very different if I were employed and paid to make software that coincidentally also was free, but I'm not. Maybe this blog post was aimed at Canonical and their employees, or the practices of big projects like GNOME. If so, then maybe he could have the decency to say so, instead of going about "solving" other peoples problems that aren't really there.

They are obviously not professional enough. Either the MB team, or the range supervisors, or anyone else in that chain.

If your range is situated so close to populated areas that you can fire a projectile from a makeshift cannon out of the bounds of the range, then get a bigger range. Or a smaller gun. I have no idea how big their range is. However, it was apparently not big enough.

I don't know if the ball hit the hill or the sky or a bird on the way or anything else that might have happened. I weren't there. I also obviously understand that they didn't plan for the ball to go though those houses. However intentions does not change facts. Neither do regulations nor safety procedures, nor requirements.

If you cause an accident then you havent gone to the utmost of efforts in preventing it. The utmost of efforts might also include not doing it at all.

Apparently not big enough then. This was a lucky case. Wern't and apparently couldn't have undone any bodily harm that was caused.

If they indeed were several kilometers from anyone else, then they have miscalculated the ballistic trajectores so gravely that it's completely mindboggling to think of how these guys were allowed to play with explosives in the first place.

While I do like some of the MB Episodes, I'm not a fan of blowing up things with oversized explosions in general. Please note that explosives are dangerous. Leave it to professional use. Playing with fire will eventually get you burnt.

Accidents do happen, no one is infallible, but one should really go to the utmost of efforts when it comes to blowing stuff up or launching heavy projectiles into the air at great speed. At least if accidents happen because explosives were used for something useful, say, construction, then one could at least think that the damage or bodily harm was for a greater good, even though that is by all means a meagre comfort. However, when these sort of things happen for the entertainment (and the profits of the show, mind you!) of others, then something is really really wrong.

I hope they are judged harshly for this incident. If they are blasting cannon balls through peoples houses and cars they have no control of what they are doing. Sending balls of cast iron through habitated areas cannot be dismissed as an "unfortunate incident". In my country (Norway) you'd immediately get arrested and charged if you fired a live cannon outside a big millitary shooting range. I certainly hope that their celebrity status won't impede justice in this case.

Please note how the "other" category consists of nearly half of the downloads. I would say that this adds a lot of uncertainity in this dataset. Without knowing the distribution of the OS-es that shows up in "other" this data is pretty much meaningless.

Searching isn't the same as querying. -Q is for operations dealing on the _local_ repository. -S synchronizes your local repository with the remote repository. In a way installing could very well be -Si (-S --install), but installing is the default action in -S mode instead. Pacman is maybe somewhat idiosyncratic, but I find it very useful and simple once you get the basics.

That's just how CLI apps work, there is nothing elitist about it. Its "cd" and "ls -la" and "cat", not "change-directory," "list-directory long-format everything" and so on. The learning curve might be steep, but it's well worth it, especially for those of us who "live" in a shell.

In the particular case of pacman, I really like the design of the arguments, in particular the top level ones. -S is for syncing, -R is for removing, and -Q is for querying and so on. Nice!

Your graphs make it very hard to compare the performance of the different collectors. What about putting all of them in the same plot, making that logarithmic, and include cumulative time (on a separate linear axis)?

That would be splendid. I'd even pay more if i can get room for my legs, but much more importantly have the opportunity to actually lean back in the seat and not break my neck... In otherword have a neckrest that's not designed for 150cm tall people.

Indeed. I refuse to read this. Haskell is probably awesome, but this site is clearly not. Time to get noscript running again...

Most norwegians are not religious. The stats are skewed in direction of Christianity because everyone is a member of the government church per default. That doesnt mean they go to church, nor does it mean they are religious at all. Christianity has had a great cultural impact, true, but I woudn't say that it is part of a "norwegian identity" today, at least not a very prominent one.

How moslems, which several of the victims were, could be stigmatized much by this is beyond me. I would rather say that FrP and the extreme right will take a blow...

However, they are extremely expensive to build and keep running, and (perhaps) even more vurnerable than battleships which atleast had armour. And modern silent submarines, for instance those of the Swedish, German, and Norwegian navies reportedly often "sink" modern US and UK carriers in war games.

The main difference between chess and Jeopardy is that Watson has to interpret ambigous (and awkwardly presented) "answers" and interpret what will be a suitable "question" to that. Both these two are really difficult. Watson needs a lot of natural language understanding across all lingusitic domains to even be able to search its databases and rule engines and what have you.

Chess, in contrast, is a totally deterministic game and the game state can easily be fed into a computer. That computers are able to beat humans at that comes as no surprise.

> If you speak Dutch, you also speak accented Flemish and broken Afrikaans. If you speak Danish, you can also understand Swedish and Norwegian.

It is true that these languages are really close. But I woudn't say that danes in general understand spoken Norwegian or Swedish (though Norwegians usually do understand the others better). If you speak Danish as a foreign language, I'd be really impressed if you could have anything resembling a natural conversation with a norwegian or a swede.

Aaahhh, ofc, now I see why that wouldnt work. Guess I learn something every day :)

Wouldn't that still be a finite state automata?

You can create a submachine representing the regular expression transition conditions, and just attach that at the state you wanted, resulting in a finite state machine.

Of course this doesn't hold when you are talking about non-standard regular expressions, and it's probably a nice feature to have when creating the automata, but IMHO it still sounds like a silly idea when CFG-tools like ANTLR and YACC are available.

So what exactly then is the definition of understanding, vs being programmed to act like one understands? Do I, for instance, understand pain when I remove the hand from the hot water, or is it because the reflexes in my brainstem are programmed to? Or do I understand mathematical concepts like the monads I use in Haskell when I probably will fail horribly to descripe them adequately or manipulate them in a proper mathematicial setting?