If I believe the data is going to already be mostly sorted why wouldn't I just use insertion sort?

If you have an appropriate Android device Google Now will (apparently) display information based on your current context (e.g. if your phone learns where work and home are it might display information about traffic jams on the route home around the time it believes you will be traveling). You need a logged in Google account to use this feature.

OK Google is a way of using your voice to interact with your device (or Chrome web browser). So if I have the appropriate phone and it's been set to listen I can say "OK Google" and it will activate an app/mode where it will accept further voice input. On the Android phone I saw (and in my Chrome web browser on OS X) I can then ask it "What's the weather like?" and it pops up some weather related information and speaks back "It's ten degrees in ". Sometimes when you ask it questions just does a web search other times (on the device) it would start applications (e.g. mail) and so on. You do not need to be logged into Google to use this feature.

...but not without a price. If you can mathematically construct your program then you can prove that it is free from defects providing enough assumptions hold (the specification is correct, the tools used to build it are correct, the proof of correctness is correct, you had enough money/time/skill to do the process etc). For the time being, it's not possible to formally most programs that have already been written in mainstream languages so other techniques like testing will remain useful tools.

From Eric Blake's bug-bash post

bash -c "export f=1 g='() {'; f() { echo 2;}; export -f f; bash -c 'echo \$f \$g; f; env | grep ^f='"

If you see anything like the following:

bash: g: line 1: syntax error: unexpected end of file
bash: error importing function definition for `g'
1
2
f=1
f=() { echo 2

you're still vulnerable. There may be other issues the above does not cover.

You can already ask some compilers to do what you are asking - it's just often not on in shipped builds.

At compilation time warnings can be generated for out of bounds accesses that can be determined statically. Clang has -fsanitize=bounds, GCC has -Warray-bounds.

As an Anonymous Coward pointed out, it can be hard to detect runtime allocations overruns at compilation time. For these something like Clang's AddressSanitizer (GCC has added it too will help but at a cost of both time (slow down factor of 2) and space which is why you're unlikely to find it enabled on your precompiled SSH server binary. It's true there are cheaper checks (such as GCC's FORTIFY_SOURCE) that are less thorough/specialized that are often enabled by distros.

My understanding is that Apple have done the work to make it viable to use LLVM for certain levels of Javascript JITing so it is now feasible to use LLVM to compile long running dynamic code. Said code needs to be long running to a) build up information about the instructions being run b) offset the overhead of compilation.

ACT has a JPEG recompression test which clearly shows a bunch of compressors making a JPEG smaller. Even better - there's a great paper by the author of packJPG talking about how to compress a JPEG losslessly using the technique teppples described...

Sometimes you don't even need to change the file format - optimization can be applied to already compressed gzip/deflate files (which PNG uses) which can be used to create a more optimal deflate/gzip file. See tools like DeflOpt and defluff (DeflOpt can sometimes make even zopfli encoded files smaller).

Any Turing complete language can mimic any other Turing complete language (but at a price) so if your language supports condition driven loops you effectively have GOTO and IF. However if we see GOTO as syntactic sugar (and thus an efficiency optimisation/control flow obfuscator) wouldn't the combination of continuations and exceptions get you what GOTO can achieve?

Whether you consider this issue is hype depends on your answer to "if a tree falls in a forest and there's no one to observe it..." thought experiment.

The author of LZ4 has a summary with regards to LZ4 (both LZO and LZ4 are based on the LZ77 compression and both contained the same flaw) - that the issue has not been demonstrated as being exploitable in currently deployed programs due to their configuration (a rather angrier redacted original reply was originally posted). So at present this issue is severe but of low importance. If a way is found to exploit this problem on currently deployed popular programs without changing their configuration then this issue will also be of high importance but since this issue has now been patched hopefully newly deployed systems wouldn't be vulnerable.

Moreflicks lets you see what's available on multiple streaming services based on various "best of" lists (e.g. it's unlikely Netflix will ever tie in to the IMDB top 250 but Moreflicks does) and even has support for countries like the UK. It's sad to see an ecosystem like this being removed without replacement...

Unless your graphics driver provides a full 3D stack (userspace GL libraries down to kernel drivers) you will be using Mesa on Linux. You are probably thinking of Mesa as purely a software renderer whereas it is also used as a frontend to open source 3D drivers and uses DRI to provide access to the hardware's acceleration.

I've yet to see binary any drivers use Mesa.

This is one of those questions that's going to keep being asked... Perhaps one day I'll be fast enough to get a first post on this that people actually read...

Link summary from last time:

• Stack Overflow's books every programmer must read question (locked since 2012).
• Top Programming Books a more diverse list.
• Top 100 Programming Books by sales stats.
• Top Programming Books a more diverse list than the above.
• Reddit has a Must Read Programming books thread.
• In this Stifflog 2006 interview with Yegge, Torvalds, Hansson, Norvig, Thomas, Van Rossum, Gosling, Stroustrup and Bray.
• One of the Kernel Hacker Bookshelf series on LWN recommends Unix Internals.
• Joel Spolsky's list of books programmers need to read.
• Your Favorite Tech / Eng. / CS Books Slashdot thread from 2008, my comment listing my favourite books.

General comments

• A few people have volumes of Knuth's Art of Programming on their shelves (but it's harder to find people who have read all of them).
• One of the consultants who taught at my University said that the Mythical Man Month and Peopleware were good. I've read these too and can also recommended them (although they are more about managing programmers rather than programming per se). The consultant also recommended Design Patterns (although he said not to read the book cover to cover but rather to just be aware of them so you could refer to them later).
• I've heard the "Dragon Book" (Compilers: Principles, Techniques, and Tools I think is the 2nd edition) being talked of favourably.
• Many people seem to recommend reading Godel, Escher, Bach (I'd say it's about mathematical thinking)...

I've noticed which book answers tend to fall a bunch of categories:

• Books that talk about software engineering/management/teams.
• Books that talk about programming languages.
• Books that talk about Computer Science.
• Books that improve your mathematical thinking.
• Books that programmers like but aren't programming/maths at all.

If you're going to ask someone "which book?" try limit the categories they should give you an answer for...

There's a comment at the bottom of the article by David Poole that links to a post talking about OpenGL driver quality on desktop Linux and mobile Linux. The summary from that blog post is:

• Vendor N closed source desktop Windows/Linux - Excellent. Near perfect.
• Vendor X open source desktop Linux - Good. Highly responsive to bug reports but updates get to users slowly.
• Vendor I closed source desktop Windows - Good but lacking useful features.
• Vendor A1 closed source desktop Windows/Linux - Mediocre. Unresponsive to bug reports.
• Vendor A2 closed source mobile - Bad. Buggy, vendor knows there are issues but doesn't fix them, driver limits performance forcing others to implement workarounds.
• Vendor Q closed source mobile - Bad. Buggy, vendor is unresponsive to bug reports.
• Vendor P closed source mobile - Unknown. Driver does not publicly support high enough version of OpenGL ES.