demallien

I'm not sure what you expected scientists to do. None of the "traditional wisdom" was confirmed as true, it all had to be tested and was considered suspect until such testing had taken place.

On top of that, traditional diets had shortcomings. It's hard to produce enough calories for today's population to survive, without a larger proportion of those calories coming from grains.

Faced with this change in the food landscape, and with faith in traditional wisdoms rightly shaken, nutritionists have been basing their advice on reasoning from first principles, and preliminary results. They got it wrong badly. But at least we were on the path to a better understanding of nutrition. It's been too slow, and nutritionists were not skeptical enough of preliminary results, but lucky us, these are problems science knows how to fix.

At least my Mac recognizes and uses a second monitor when I plug it in, unlike the bloody Fedora 19 box that I use at work. And don't get me started on that second graphics card that the system can't figure out how to use! And the wifi Just Works(tm), unlike the Ubuntu laptop that I had before that.

When I think about it, I struggle to find a single useless class from high school. If anything, I regret mostly that I didn't make enough of the opportunities that my school provided me - I really regret not having put in the effort in art classes for example.

----------

To me abstraction above the hardware is like condoms. Some people say "Use three condoms, its better". I don't want a literal C64 -- just the complete open simple access... but 64-bit and 3Ghz and multicored. I don't want it to run on a 386, just x86_64.

Compare that to today. There was nothing to install. It was all already there. There wasn't even an environment to launch, you booted into the REPL. You didn't have to hunt for tutorials on the internet, everything you needed to get started was in the manual that came with the computer. And everything in that manual was appropriate to the computer. You didn't have to worry about having the wrong version of dev environment, making the tutorial incorrect.

That's not to say that programming hasn't improved in other respects. I could spend years trying to build a basic TCP/IP stack on that old 8bit computer, which already comes pre-installed on a modern computer. I can grab a free copy of just about any language I've heard of. Huge numbers of libraries freely available allow me to stand on the shoulders of giants. But, nothing available today approaches the simplicity of that old 8 bit system for learning to program...

So, problems with the iPad Air are not particularly surprising. The shift to a 64 bit OS is a difficult thing to get perfect on a first go.

That said, they really should have nailed the discrete GPU kernel panics on rMBPs by now. That's been going in fir a couple of revs of the hardware and is unusual.

I see what you mean, but I feel that this misses out an important fact - a lot of those speed increases are only available if you modify your code to use an optimized path. Memory I/O is a classic example - it has sped up a lot but only if you make sure that you aren't generating cache misses on every memory access. Branch-prediction-friendly code is another good example that can make a huge difference to the performance of a system.

That means that a lot of the performance gains that we have achieved (not all, certainly, but a substantial chunk) are not necessarily made available to naively-written code. It is not terribly surprising then that we sometimes struggle to achieve the speed-ups the hardware has made available to us.

This problem is only compounded by the fact that performance is one of the leakiest things going when we are talking about abstraction layers. It makes things extremely difficult to think about because you need to know intimate detail of your entire software stack, which these days is huge, if you wish to effectively optimize your code.

Humans beat up on some invading aliens that got their interstellar tech from one such reboot library, and then go and invade Earth. We win because their knowledge is deep but narrow, and we exploit that.

I have since repented. I find autotools (with occasionally a script of [ruby|python|perl] to handle something that would otherwise be tricky to do in make or m4, which is then called by the makefile) works a treat. Just don't try to do anything tricky in the auto tool files - as I said, boot anything exotic out to a separate tool.

Also, any discussion of build tools without also discussing package management is but half a discussion.

Or when I was in a small town in Virginia with a friend, we were in a shop, and discussing whether the museum there would be open the next day. The shop assistant overheard and offered to call them for us. Even people in DC were wonderfully polite and friendly! So much so that I'm heading back for another holiday in a couple of weeks time.

If, on the other hand, I have said nothing other than "I'm not speaking without discussing with my lawyer first", it's much easier for your legal counsel to paint you as just a cautious individual, rather than someone that is trying to cover up a lie.

tldr, "don't talk to the police" is also good advice in Commonwealth countries, not just the US.

Again, I have the greatest respect for Linus's achievements, but I personally feel that he uses the power those achievements have bought him to be a bully, and that gets no respect from me.

It's clear that that the kernel dev guys and Kay have a history. I wonder if Kay would have been more open to accepting change requests to systemd without Linus's bad behaviour. It bears thinking about...

Similarly, you can reduce the complexity of routing calculations by applying some constraints. You will potentially lose the possibility of an optimal solution, but you will gain a far faster compilation time. As always with engineering, it's a trade-off.