Should programmers learn machine code? - <AUTHOR>

I saw my first computer in 1978.  It was a Tandy TRS-80, and it was running what today we'd call a slide show.  It was, however, entirely in text and very, very simple graphics.
It had 16KB of RAM, and permanent storage was sound on a fairly standard external cassette tape drive.  I can still draw the waveform of a bit, and the start/stop patterns.  You could program it in a simple BASIC that had limited variables, and no subroutine parameters.
No parameters in subroutines!
But I was hooked.  I wrote two BASIC programs, then ran out of patience.  It had to run faster!  A 1.77 MHz Z80 running interpreted BASIC wasn't fast enough.
So I smashed the stack.  I won't go into the details, but I bootstrapped into assembler (the BASIC did have PEEK and POKE) and wrote a compiler.  The BASIC version, two copies of the machine code version, and the variables, all fitted into the 16KB memory.  Two copies because it wasn't relocatable, so I compiled to copy 1, used that to compile to copy 2, then machine-code saved copy 2 to cassette.
It was cool writing different variants of sort, then sorting the data that was in the memory mapped screen.  You could see the heavier items fall to the bottom in quicksort, or migrate one at a time to the top in a bubble sort.  It was pretty raw, and enormous fun.
Why do I tell you this?
Today at work I took a subroutine that was taking 171ms per call and making the GUI run as slow as a snail on valium, and re-wrote it to take less than 10ms per call.  The methods I used were straight out of the techniques I learned in that first 3 months of machine code programming (not assembler -machine code), and my colleagues couldn't really understand it.
There followed an impromtu "training session" in which I explained how CPU cores work, how machine code can be mapped to them, how assembly code matches machine code, and the way the instructions actually match the hardware, in some sense.
A lot of what I talked about is now outdated, it is, after all, 30 years old.  But the techniques are still applicable on occasion.  They were amazed that they didn't know this stuff, and intrigued as to how I do.
It's just what I grew up with.
Should programmers in C++, Haskell, Lisp, Python, etc, know these things?  Or are they really mostly irrelevant, becoming more so, and soon to be known only by true specialists and dinosaurs like me? <comment><USER2> The simple answer: Yes. The longer answer: Yes, absolutely.

As for the why of it:

No other programming language will give you the feeling that it is you that controls the computer as good as assembly ever will, other than the lucky few that get to program microcode.

Assembler is what it all eventually boils down to, it gives you a first hand view at the von Neumann bottleneck and how small the letterbox is through which the CPU views the memory.

After you get a good long hard look at that your programs will never be the same.

<comment><USER3> Also, understanding of machine language is key to understanding the underpinnings of operating systems and implementation of programming languages.

If you're missing those three, then you've got an important hole in your knowledge as a programmer: Machine language, Operating Systems, Implementation of Programming Languages.

Much of why computers and their software is put together in this was all clicks into place if you have an integrated view of those three.

</comment></comment><comment><USER4> I think the difficulty lies in the multiple meanings of 'programmer.'

My interest in programming stems from wanting to use them to solve problems, not from theoretical interest in how computers work. Most of my colleagues in the UW engineering department I was in learned just enough Matlab to get the homework done. I learned enough to program a solution to the homework. I originally learned QBasic to program a Mandelbrot-set generator on a 286, because I wanted to generate the Mandelbrot set.

Should a web developer learn machine code? I dunno. You can get pretty far in web development with a good head, some Railscasts and tutorials, and a bit of practice. Maybe the question is "When should a web developer learn machine code?" I think the answer to that question, if he/she is a working web developer, is, "When he/she has to, when it comes up."

For myself, I look at these--let's be frank--esoteric things like machine code, higher-order whatever, compiler-design, and so on and think, "That may be interesting, but I've got work to do and fun to have. I'll wait until I have to know it before I learn it." I've already had to learn about lambdas. Very fun stuff, but also very _useful_ stuff.

Now, should the macho programmer learn machine code? Of course. But the macho programmer should also be manufacturing his own computer chips as well, to better fit with his pure and obviously correct programming methods.

<comment><USER5> I'd agree that for web development, assembly is almost certainly something a typical programmer won't have to know. I'd argue that C is a good idea for various reasons, but that argument's been had already.

That said, "learn it when you need it" is problematic because of the case where you don't know what you don't know. In my own experience, I've learned lots of things and then thought back to previous problems and had little epiphanies on better solutions. People that don't experience that probably aren't improving very much.

Perhaps it would be useful if various communities (like webdev, etc) put together curriculum guides for "things you don't know you don't know, but should know." Of course, what should be on the list would be a source of bitter contention I'm sure.

</comment></comment><comment><USER6> While I wouldn't agree that programmers need to learn machine code, I would definitely recommend that they at least learn some ASM and poke around in a few programs with a decent disassembler. Seeing and understanding how a program actually interacts with the hardware at runtime was one of the biggest moments in my life as a programmer. The first time I successfully "cracked" a shareware program, my understanding of how computers worked increased a hundredfold.

Before multi-core processors became common, I had a major argument with another senior developer at work who completely believed that simply adding threads would speed up execution of his functions (that's what threads do right?!).

Edit: The point is, programmers don't know nearly enough about how their programs interact with the hardware they run on.

<comment><USER7> Really, not many people even think about what's in any level lower than the one they're working on.

Case in point: I once had a C++ program in which replacing malloc() with a wrapper that rounded up all allocations over 1kb to multiples of 1kb actually increased execution speed by 20%. Those may not have been the exact numbers, but that's the general idea. Guess why.

. . .

The program was allocating many large objects with small variations in size. The system default malloc/free implementation would work efficiently for small objects, but would store large allocations in a linked list, bucketed by size. In the worst-case (all objects are large and of different sizes), freeing n objects would take O(n^2) time. This program came very close to that ideal. The rounding prevented that worst case by using fewer buckets.

Of course, that version never saw production use. It was just used to demonstrate the nature of this particular performance problem.

</comment></comment><comment><USER8> Feel like I should mention: For people running a UNIX os with objdump, take a program written in C or C++, compile it with gdb's -g flag, then do:

      objdump -S your_program

This will disassemble it and interleave your disassembly with original source code. It's a great way to see what your high-level C gets compiled to, a great way to see how compilers work and a great way to scratch a low-level itch.

<comment><USER9> This was how I built my early reverse-engineering skills. I started off compiling my own C to x86 assembly and seeing what it mapped to, then I had some friends write little crypto routines in C and compile them, throwing the binaries over to me to hand-decompile. Can't recommend this enough.

I also have to recommend the book Reversing by Eldad Eilam if you're interested in low-level hacking from a reversing perspective.

<comment><USER2> There is another old series by Leventhal about learning assembler, he basically wrote the same book for many different processors.

And the x86 series reference manuals from Intel, if that's the CPU you're working with (a fair assumption).

<comment><USER10> I second the Intel reference manuals - they've been extremely useful on multiple occasions and have been great at helping me understand the x86 processors better.

</comment></comment></comment></comment><comment><USER11> Assembly language yes, machine coding as in flipping switches on the front panel is probably going too far. I suppose you dont really need to know how a cpu works to be a journeyman programmer, but I think to be truly innovative you need to know what lies at the heart of it all. If you know instructions, registers, L1 and L2 cache then you can muse about interesting and innovative problems. How can you think about really fast algorithms if you dont know about cache latency? How can you think about distributed functionality in a robot, if you dont know that everything goes through a single pipe in a processor? (OK a small number of pipes.) I know some kids who parleyed their knowledge of the difference between the latency of instructions in cache and those in memory into a significant company.

Some friends and I are going to start an old programmers' home, like the old sailors homes. Obviously we should include you as a charter member.

<comment><USER12> _I know some kids who parleyed their knowledge of the difference between the latency of instructions in cache and those in memory into a significant company._

That's interesting. Who? What? How?

</comment></comment><comment><USER13> I learned 6502 in the 80s and did a lot of x86 in the mid 90s and.. I'd say "not anymore." Sure, it's useful to get a _feel_ for it and have some experience with it, but I'm assuming "learn" in this case means a higher level of competency than just a broad understanding of it.

C is about as low as you need to know nowadays. x86 was critical to know in the 90s due to performance issues, but since the majority of software nowadays is running on some sort of VM or pulling heavily on frameworks (CLR, JVM, OS X's frameworks), it's _mostly_ pointless to use x86 in all but the most unusual of projects.

The only reason I'd still advise a basic familiarity with assembler is to rid the notion that C is as low as it gets - you can get totally different results from different C compilers (and even incompatible results in some nasty cases) and it's worth at least knowing there's something underneath there that you can take a basic look at.

</comment><comment><USER6> The Story of Mel... An inspirational story of what true hacking is about.

<http://www.pbm.com/~lindahl/mel.html>

<comment><USER2> that one should be required reading for any programmer.

<comment><USER6> Agreed. There are a few groups around who still keep this kind of spirit alive. Seeing what the guys in the demoscene can to with 64k is truly amazing, but what they do with 4k can blow your mind.

<comment><USER14> Or 64 bytes: <http://canonical.org/~kragen/demo/klappquadrat.html> (I wrote the explanation but not the code!)

<comment><USER15> Opera gives a Fraud Warning on that URL.

<comment><USER2> You shouldn't believe everything your browser tells you ;)

<comment> nor-and-or-not > Safari can't connect to the server.

I don't believe him.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Yesterday I was debugging a device driver for LCD controller using an oscilloscope. Low level programming might not be the hot tech these days, but there are tens of thousands of people who are good at it, and many were born well after you started with computers. I would maintain that learning it is not that hard, for an average, good, working programmer.

</comment><comment><USER12> I don't have this low-level background, but am increasingly coming to the conclusion that it matters a lot, and that the vision of high-level abstractions entirely divorced from hardware is a pipe dream. You can get away with it on easy problems but not hard ones.

Alan Kay says that people who are serious about software have to be serious about hardware.

<comment><USER17> I think it's good to know. However I use it very rarely.

<comment><USER2> I think if you really know then you'll be using it without even consciously thinking about it. You'll make sure that you don't allocate storage units across page boundaries, you make sure you access your arrays in the right order and so on.

The cumulative effects of that are huge, and it's more of a method of working than something where you take the assembler manual out. Just like an engineer is not going to go and re-learn the ins and outs of materials science when building a bridge, it is the solid background in materials science that guides him in his choices.

<comment><USER12> Well put. It's this intuition that I am feeling the lack of. It's wrong to imagine that one can create arbitrary abstractions for free in high-level languages and let compilers and fast hardware take care of the rest. That approach takes you so far, but when you run up against its limits you are really in trouble. That is most true when what you're working on is computationally hard somehow, but it also manifests itself in the reality that most software is simply slow (a handy example being the browser I'm writing this in, FF 3.5).

This is changing my view of programming languages. I'd like an environment where abstractions are built up in transparent layers that don't hide the underlying architecture, but still give you powerful operators to compose things. The standard options mostly require you to pick one or the other.

Put differently: rather than thinking of expressive power as being built up in layers that move the highest level ever further away from the lowest, is there a way to keep high and low relatively close together while still providing lots of expressive power? The closest thing to this that I know of are Arthur Whitney's languages. The latter are notoriously cryptic, but unless I'm mistaken they do provide both of these things: an execution model that is close to the hardware and a very high-level, logically scalable language.

<comment><USER2> Here is an idea:

A graphical environment where you can _see_ the program as it is running, with the memory map displayed in an arcade game style window.

I can imagine that such a tool would be a great eye opener.

Show hotspots in real time, move your cursor in to the memory map to get the 'hint' to display the label of the memory location at that spot.

An advanced version of it could show you the two layers caching next to the main memory and how data is flowing in and out of the caches.

I'm pretty sure that something like that is doable.

<comment><USER12> It's a great idea. I love it. However, there are only two ways I can see something like that getting built: the large way or the small way. The large way would be as a tool designed to work with one of the major languages/environments. It would have to deal with all the bloatedness that implies, plus the fact that those environments were never designed to provide this sort of transparency or hackability. It would probably be a large corporate project that took years and cost millions; this probably won't happen. The small way would be because one or more hackers decided to build something new that stayed close to the hardware and was designed for this sort of thing. That's much more doable, but puts you well out of the mainstream for a long time.

I wouldn't be surprised if people eventually come around to this point of view. It will take a while, though. The current thought is that parallelism will save everything. It could take a decade before people figure out that that isn't going to happen. Maybe then there will be a renaissance of going back and rebuilding things from the ground up. But I'm rambling.

"People who are serious about software have to be serious about hardware"... that Alan Kay has a gift for putting his finger on things.

<comment><USER2> I can see a way to build it fairly simply.

The object information is readily accessible when you compile your program with -pg, the memory map is accessible through /proc, it shouldn't be too hard to couple the one to the other and make a nice display. If you are clever about it you might even be able to fish out what memory is filled with what type of data, and colour the map accordingly.

No millions required, unix is pretty clean when it comes to stuff like this.

Some joker had written a shell replacement based on 'doom' where you could literally shoot the processes. You had to hunt them down first of course...

<comment><USER12> I see now that you're talking about the OS level where I was thinking more at the language level. Still cool. Let me know when it's ready :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> An emphatic _YES_. High level runtimes break, behave oddly, or do things that you wouldn't expect. Understanding how the machine works (and by extension, how the virtual machine works) is key to understanding:

* Why your program behaves the way it does

* Why your performance profile looks the way it does

* Gives you the skills you need to debug inevitable problems in your high level tools.

I highly recommend Write Great Code: Understanding the Machine:

[http://www.amazon.com/Write-Great-Code-Understanding- Machine...](http://www.amazon.com/Write-Great-Code-Understanding- Machine/dp/1593270038)

</comment><comment><USER19> It's worth knowing the fundamentals, even if you don't use them much. The law of leaky abstractions ([http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)) means that you will occasionally bump into a situation where knowing how the underlying layer works will mean you can solve a problem that someone else can't.

</comment><comment><USER14> RiderOfGiraffes: What were the techniques you applied, and why were your colleagues mystified? I assume you didn't rewrite the routine _in assembly_. It seems that you have some interesting evidence about the question you're asking, but you left the meaty part out of your story!

<comment><AUTHOR> Oh, gosh, where to begin ...

Actually, most of what I did are standard techniques that assembly programmers know, C programmers have seen, and web programmers don't need to bother with.

I can't actually post code here because it's commercial in confidence, yada yada yada, but I will mention the techniques.

Firstly, they were processing an entire image, then transforming it, then getting the part they wanted. We tranformed the program flow to be demand- driven, which meant that large amounts of the image weren't processed at all because they weren't needed.

Then we analysed the data and deduced that by taking logs we only needed a dynamic range of 6 bits. We therefore took the entire image into a byte map with the top two bits of each byte set to 0.

Processing 4 bytes at a time in words saved enormous amounts of memory access, and avoided register spills. Unrolling loops by the right amount meant that we stayed in cache, but had less overhead.

Once the processing had been re-worked, we looked at the assembly produced, and found that most of the time the processing could be separated into a double indirection.

Finally, by further reducing the resolution of the system, computing an approximation, then reworking those parts of the data where the errors were too large we managed to halve the work being done.

It was a good two days of analysis, and the code shrank by a factor of 2, but it's now tough to understand. We have documented the results. It's embedded work, and yes, we finally went to assembly to get the last 30% of performance.

Every part of it is standard in its field. I think some of my programmers hadn't created routines to work byte-wise eight bytes at a time in a 64 bit word, and others hadn't done the transform via logs to throw away unnecessary resolution. Another had never analysed unrolling a loop as compared with staying in cache. We used tricks such as (x & -x) to find the least bit of a number, although in 32-bit space that becomes something like (x & (!x + 0x01010101)).

And so on. A large collection of esoteric tricks, all at once.

Let me finish by saying that programs can't be made to run faster, they can only be made to do less work. An interesting aphorism when "optimised" code.

<comment><USER14> Awesome! The logs trick is one I hadn't seen before. Why were you using 32-bit registers instead of SSE registers? The CPU you're targeting doesn't have SSE? And how did you structure the demand-driven part — by 8×8 tiles, or a bounding box, or what? (I assume you didn't leave in multiple levels of function calls per pixel.)

<comment><AUTHOR> I can see there's a mistake in my reply - we were working on a 32-bit architecture for this problem. We didn't pack 8 bytes in a 64-bit word, we packed 4 bytes in a 32-bit word. Sorry.

And in short, our target CPUs don't have SSE. I've only been vaguely aware of SSE, although I used to program a Cray on occasion, so am familiar with vector processing. I must see if the SSE instructions can accelerate some of our other work which isn't yet critical, but may become so.

The demand driven stuff was done by taking 32x32 tiles in the target and reverse transforming each to the source, hence finding out which 32x32 bit tiles in the the source needed to be computed. Flags prevented redundant multiple conversions. The transformation doesn't preserve straight lines, so some care was required on boundaries.

<comment><USER14> Very interesting, thanks!

From reading a little bit of T90 documentation, SSE looks pretty different from the Cray vector stuff. It's little more than the kind of (x & (!x + 0x01010101)) kind of stuff you're talking about above, except with somewhat larger registers and a wider variety of instructions.

</comment></comment></comment></comment></comment><comment><USER20> ok, not quite as hard-core as to write my own assembler, but i grew-up with ZX-81's and C-64's, and like-wise: if you wanted speed, BASIC couldn't do it, and a C-compiler couldn't fit in the memory (IIRC, games writers cross- compiled any C on PC's).

And it's true: the best optimising compiler in the world cannot work out the intentions you had for your code -- sometimes choosing one type of algorithm will optimise quite differently from your intention -- and if you have even basic understanding of what's happening on the hardware, you're already ahead.

Funnily enough, in my last job I met someone who had the same sort of experiences, and understanding of the actual hardware, and we lamented that no-one was growing up these days understanding the low-level stuff, incl. bus dymnamics, interaction between I/O, memory and CPU, etc, etc.

Doubly interesting was in my current job, met someone who understood JVM byte- code as well as assembler, and he claimed it was key to understanding how to get truly great performance from Java.

<comment><USER6> While I'm not too sure that understanding the CAFEBABE stuff is truly helpful for improving Java performance, I definitely agree its helpful to know what's going on in there. Bytecode usually decompiles into very neat code since the mapping between the code and bytecode is very tight with most optimisations taking place in the JVM.

</comment></comment><comment><USER21> It's certainly worth understanding what's happening one level down from the level you work at, at least. Sometimes even lower-level effects seep through -- e.g., even if you're writing in something like Haskell it's probably worth having an understanding of memory hierarchy issues. I'm not convinced that "machine code (not assembler -- machine code)" buys you much over assembler, though.

I'd guess that much more software slowness comes from other failings, though. Poorly chosen algorithms that would make for slow performance even if written in machine code and microoptimized by experts. Forgetting that a random disc read takes millions of CPU cycles. That sort of thing.

(Most of the programmers I've worked with have been writing embedded stuff, or close enough to others who are doing so, that they have some exposure to assembler-level thinking. Though I expect those of us who grew up in the age of 8-bit micros could still teach most of them a trick or two.)

<comment><USER2> Machine code, the binary code that drives the decoding and execution logic in the CPU is certainly useful.

Once you have a thorough understanding of how to program a CPU and familiarity with the instruction set, you'll probably take a look at the output of your assembler to see what it is that it produces.

That and a reference manual will give you a taste for machine code.

As long as you do not use macros it is pretty straightforward to convert machine code back into assembler, macros muddle the waters here because a single assembler macro can generate lots of machine code.

There is value in machine code too, because the instruction set is created in such a way as to facilitate decoding by the simplest set of microcode to achieve a given amount of functionality. Silicon is expensive so it pays off to design your microcode and by extension the instruction set in this way. Machine code opcodes can usually be split up into 'fields'.

The elegance of microcode is something that has its own beauty, but it may be that that - just like machine language - is an acquired taste.

I realize riderofgiraffes wanted to make a distinction between learning assembly (which lots of people do) and learning machine language (which probably less people do), but since the one can be trivially translated in to the other machine language is more of an exercise in hand assembly and studying the layout of opcodes than anything else, it comes with the territory of anybody that takes assembly serious.

Unlike for instance "C", which you could be programming for a lifetime without ever looking at the assembly output.

If you used an assembler to translate your assembly program - without macros - into machine language and you then ran the resulting dump using nothing but a reference manual and a pile of paper you'd effectively be executing machine language. They go hand in hand.

But learning assembly (usually) comes first.

If you want to go one step further you can create your machine language programs without the aid of an assembler, I once knew enough 6502 and 6809 opcodes and operands by heart to do this for programs that were longer than was probably normal, even today I still remember a couple of them even though I haven't had any use for any of that lately, I should probably 'garbage collect' ;)

I have found that particular skill to be less of value because as soon as I could I wrote an assembler to do those pesky branch computations for me.

The main driving factor here was the cost of an assembler, on pocket money it was a lot cheaper to go to the library and look up the opcodes then go home and program the thing instead of spending a years worth of 'income'.

Hand assembling small bits of code (say a subroutine less than 50 bytes long to speed up a piece of code when no assembler was available) got me some pretty scared looks by people that I met though ;)

The benefits of machine language over assembler are there, but the 'return on investment' is probably diminishing at that point. Many people would argue that that already goes for assembly, obviously I'm not one of those.

</comment></comment><comment><USER22> An understanding of how of your processor works is quite useful for any programmer, but I don't think learning machine code is worth the effort for most people.

</comment><comment><USER23> No not all of them. I think there can be a tenancy to think the way that one learnt to program gives the best grounding: this is a bias. For my money there are different types of programmer and depending on what sort of project you are doing you might want different mixed. That can mean knowing both your strengths and weaknesses and those of your colleagues.

By far the best attributes of programmers are the want to constantly improve their code and experience. However sometimes a wealth of experience can lock a programmer into a fixed way of thinking. I know quite a number of C++ programmers who seemingly don't seem to get OO for instance. Others may not approach a problem in the best way.

You journey seems to imply should new programmers follow your path to get an understanding of machines. A lot of this technology is not relevant. Multicore systems are fairly modern, and hacking java bytecode is probably just as good preparation as hacking a Tandy. In face many of those old microcomputers were much simpler that even some VM architectures.

It sounds like you may have been hired into a team precisely because of this sort of experience you have. However not every optimization these days is a low level optimization. I note the YouTube architecture and how much of the service was/is written in a scripting language.

It wouldn't take long to find an opensource project that you could easily make use of these skills. Far from being a dinosaur there are whole industries that still use this sort of knowledge: but perhaps not on the desktop.

</comment><comment><USER24> Actually, Stanford recently redesigned their computer science curriculum. Intro programming (CS106) does Java and C++, and then the notoriously difficult CS107 does low level C, Assembly, and some machine code

</comment><comment><USER25> At some point in your career I think it's nice to sit down with Assembly just so you understand what's going on down there. But I don't think a programmer should do that until they have a rock solid understanding of modern day programming.

The reason I say that is because modern languages have abstracted most of the direct interaction away. So a preoccupation with what's happening at the assembly level can be more of a distraction if your language of choice isn't already second nature to you.

</comment><comment><USER26> I'll show my age here and say that in my CS program, we had (like many) a 'final project' where we assembled a wire-wrap computer from a Motorola 68hc11, some ram, rom and a handful of logic gates, then wrote a rudimentary os in assembly. Even then the 6811 was woefully obsolete. The lessons were timeless.

<comment><USER27> Your final project is today's automotive hackery. :)

It might be "woefully obsolete", but a derivative of the HC11 is in an engine control unit (ECU) from a 90's-era Mitsubishi model that quite a few folks, myself included, take a hobby interest in as means to making our cars go a little faster than is reasonable or was intended, on the cheap.

Another platform (that I have a much stronger personal interest in) is SH4-based. 256k of ROM (1M on newer versions of the car), 256k of RAM (512k on the newer version), and that's all you get to control a modern fuel-injected, variable-timing four-cylinder engine in real time.

This "old stuff" is still very applicable, depending on the field; the automotive industry is wrapped tightly in a time distortion field. ;)

</comment></comment><comment><USER28> I believe you got the wrong conclusion from your story. They don't need to know low-level details because you do. Must they also understand payroll, marketing, sales, and floor-mopping just to work as a php programmer?

<comment><USER2> No, because payroll, marketing, sales and floor-mopping do not help you to become a better programmer in PHP. But knowing some assembly definitely will. Especially if you go so far as to have a look at the paging mechanism and cache structure of the cpus that you are using.

</comment></comment><comment><USER29> Understanding how all the components in a computer system work is important to being a good programmer, especially if you're doing work that is performance sensitive. Memorizing a particular instruction set probably isn't important, but a good programmer should understand the basics of processor architecture and performance. If you know that, you can always learn whatever ISA details you need on the fly, in the relatively rare case that you need them.

</comment><comment><USER30> No, you don't have to know machine code to appreciate parsimony or performance.

</comment><comment><USER31> Anyone know what intro class in uni would be a cool intro to low level programming?

I'm experienced with LAMP and bits of C++\java.

<comment><USER32> Maybe a course like "Computer Architecture" would be what you're looking for. At U of Illinois, they start with logic gates and go from there.

</comment></comment><comment><USER33> How would one go about learning machine language for, say, x86? I already know a fair bit of assembly.

</comment><comment><USER34> _"... Should programmers in C++, Haskell, Lisp, Python, etc, know these things? ..."_

Learning machine code for programmers is what Latin is to to reading and writing.

<comment><USER9> _Learning machine code for programmers is what Latin is to people._ FTFY.

Knowing machine code isn't an academic endeavor for many programmers, much like knowing Latin isn't an academic endeavor for doctors. Understanding the machine at the lowest level is essential for kernel, compiler, emulator, and embedded development, as well as software reverse-engineering. It may be a good idea for many programmers, but for a subset of us, it's mandatory.

<comment><USER35> On the other hand, a doctor need not know all of Latin (especially the fiddly bits about case and conjugation), but enough to pick out the roots of words they come across. While I'm sure there is a small subset of doctors who actively study medieval literature for, say, bits of age-old wisdom that do hold a grain of truth, for most practicing physicians, they merely ought to have a grasp that, say, renal refers to kidneys, etc.

Similarly, I don't think programmers ought necessarily be able to compose particularly good machine/assembly code. I'd suspect, however, that having been exposed to it at some point will make one be able to handle a broader range of situations better.</comment></comment></comment>


Open source needs business revenue to survive - <AUTHOR> http://www.computerworlduk.com/toolbox/open-source/open-source-business/news/index.cfm?newsid=19598 <comment><USER2> No, it doesn't. Profitable open source businesses are a good thing (imho), but open source projects will continue to happen and continue to grow (although perhaps not as fast) even without them.

</comment><comment><USER3> I'm getting bored of ex-MySQL guys pontificating. Your one-hit-wonder days are over and, tbh., it wasn't even that good a product.</comment>


Stabilizing a product in distress - <AUTHOR> http://iosmak.wordpress.com/2014/02/10/stabilising-a-product-in-distress

<comment><USER2> What an outstanding article.

The "Identify one or two simple reasons..." point reminds me of the grand master of turnarounds: Gerstner. When he got the job I called him "the cookie guy" because what the hell did he know about computers (not much). But what he did know was how to turn the supertanker around.

Everybody expected a grand plan and after he did a walkabout and met everybody and learned what the company was doing his decision was: don't change much, just keep at it. (general derision from the press ensued).

He then went and fixed a bunch of widespread problems that fucked EVERYTHING up and so almost everything started to work properly.

Rather amazing.

<comment><AUTHOR> It's hard-earned knowledge. I have had the privilege to work with Ivan and couldn't pass posting it here because it is an awesome piece. What he outlines is equally applicable for anything that involves a lot of people. It all boils down to fixing the people issue. It is interesting that many times you do not even have to change the people to make the machine work.It almost always comes to lack of experience, lack of leadership from above, unclear goals and denial you have a problem (which is due to the lack of experience).

You brought an interesting point and I have observed it myself too. At many occasions teams would be on the track to improvement but they would crumble because of pressure from above. When a kid can't even walk, regardless of how hard you push it, it can't start running. This applies to engineering teams too.</comment></comment>


Detroit: Bankrupt city turned corporate luxury brand - <AUTHOR> http://www.theguardian.com/money/2014/may/14/detroit-bankrupt-brand-ad-chrysler-nostalgia <comment><USER2> I'm so torn by all these comments about whether Detroit has 'bounced back' or not. On one hand, it certainly seems like salaries, wages, rents, and prices are rising in the Detroit metro area, on the other hand parts of the city are in really bad shape.

My own perspective is to not focus on how to classify Detroit's status in relation to other cities and metrics, but to focus on what Detroit is. It's an eclectic area where poverty, middle class, and affluence collide. There are creative communities that butt right up against dangerous areas. It's a great area to bike since certain times of day cars are few and far between, and there is an upbeat sense of happiness in some communities. There's not much more to it other than it's the people's town and the behavior of individuals will have a lot to do with how Detroit fares in the coming years.

</comment><comment><USER3> It's bouncing back big time. It's going to take 10 or more years for the whole city, but it will be unrecognizable in the central city in the next few years.

I say this because when I go riding my bike in Detroit on Monday nights 2,000 people ride with me. That's the kind of thing that makes people move in.

Hole in the wall restaurants have an hour wait. Big name restaurants take reservations weeks in advance.

Minor minor minor minor league soccer teams draw like 2,500 people.

The brand is strong. People are going to use it. There is a ton of energy down here and a shit ton of people who live right around the city who will move in once conditions are right, and they are becoming right for the hipsters and college kids.

<comment><USER4> Are you one of those critical mass riders who shuts down Campus Martius for a few hours a month?

'Cause if you guys could stop and let traffic through on our way home from work, that'd be really helpful. You could pass out pamphlets and get more riders that way.

<comment><USER5> The whole point is to stop traffic, make people get out of their cars. Cars have taken over most cities, this is people pushing back.

I think you may miss the point.

<comment><USER6> Are you guys _literally_ shutting down traffic for a few hours at a stretch? 'Cause that's a really shitty way to gain public support, and self-righteously informing people that you're doing them a favor by "getting them out of their cars" is only going to make it worse.

I have, BTW, ridden a bicycle exclusively for 18 years, and I've always enjoyed Critical Mass (our local rides top out around 50 people). It frustrates me how many of my fellow cyclists seem determined to shoot themselves in the foot, PR-wise.

<comment><USER4> I hadn't heard of Slow Roll. They might be better at handling traffic than the one Critical Mass ride I saw. They had several thousand riders going through a roundabout. It looked spontaneous as they had no detours posted, and a few cars were stuck in the loop for about an hour. They ride at the same time each (week? month?) so I just remember to not drive through that part of downtown on Fridays in the summer.

Really, though, I've looked into similar things, and can't understand how they're able to do it next to a police precinct without posting detours and without being fined or traffic controlled. But, it's Detroit. There are probably 10 cops covering downtown at any time, and they might not have the resources to police traffic on a Friday evening.

That said, I'm actually interested in this. Did you guys have to go through city hall and set up the detour routes and get permission from the affected businesses to lay down your route? The city I tried to set something up in would have allowed it, but there was a lot of paperwork and it was smaller than an organized ride.

<comment><USER7> In Atlanta, critical mass got up to 300+ riders before the city/police finally got tired of the illegal blocking of intersections. (They call it "corking") Atlanta police had 10-20 motorcycle cops follow the ride and pull over anyone who broke the law (running red lights, etc.) for a couple of weeks and the popularity quickly dropped off when people realized they had to still follow traffic laws. It still goes on every month, but it's more like 50 riders now.

There are also of course plenty of legal rides/events that get permits, police escorts(sometimes free), etc. We have something called "Atlanta Streets Alive" that shuts down several miles of large streets every few months to only pedestrian and bike traffic, allowing people to walk and play in the streets with no cars. Permits are required, off-duty police have to be hired to direct traffic at intersections etc.

</comment></comment></comment></comment></comment></comment><comment><USER8> Shinola is using leather from the Chicago tannery Horween, that was discussed on HN last week...

[https://news.ycombinator.com/item?id=7705512](https://news.ycombinator.com/item?id=7705512)

[http://www.shinola.com/journal/what-horween- leather](http://www.shinola.com/journal/what-horween-leather)

</comment><comment><USER9> there seems to be an attitude that what happened to detroit was not related to policies and politics. i respectfully submit that significant lasting change in any system requires change in the environment.

<comment><USER10> It was definitely racially motivated. That's where the schism began; back at the height of Detroit when poor blacks from the South were encouraged to come to Detroit to work the assembly lines.

Also in the disruption of the Big 3 when faced with foreign competition (thought IIRC, this is related to policies and politics because the Big 3 were protected by import controls for a while).

<comment><USER11> I've saved a very informational Reddit comment giving a nice summary of The Fall of Detroit:

[https://gist.github.com/shmup/11354626](https://gist.github.com/shmup/11354626)

</comment></comment></comment><comment><USER12> No matter what you have to say about Detroit, good or bad: It's not that simple.

</comment><comment><USER13> I don't see how this would work, unless there are some nice suburbs/towns just outside Detroit, or companies allow a lot of remote work. Otherwise, you'd be hiring, have interested people up until you say the word "Detroit", then never hear from them again. Personally, I'd rather live somewhere I'm not likely to be mugged walking around the corner to the shops.

</comment><comment><USER14> Detroit has bounced off the bottom. While we might exult in the ruin-porn of Detroit, it is a city on the mend, and is really an interesting city full of significant potential. I say that as a Canadian who travels to Detroit from the Toronto area, never feeling a moment of fear but enjoying some great restaurants, entertainment, and sports.

Go Lions!

<comment><USER15> It is interesting how the international view of Detroit differs from the domestic view of Detroit. Americans, as far as I can tell, view Detroit with what strikes me as hostility almost. Not all... but a lot of Americans that I have heard speak on the issue. And I say that as an American. Whereas elsewhere in the world, the view is... a bit different.

I think the "grit" brand positioning fits... since most of the brands trying to tie into Detroit are luxury. I think it will work well. But I don't think you could market many things to the average American using Brand Detroit.

Maybe cars ... that Eminem Chrysler 300 commercial was pretty good.

Just saying that the view of a Canadian, or Frenchman, or a German of Detroit will, in all likelihood, be different from the view of an American of Detroit...

Even though none of the people holding the opinions French, Canadian, German or American have actually ever visited Detroit.

<comment><USER14> _Americans, as far as I can tell, view Detroit with what strikes me as hostility almost._

You don't have to go far to find Canadians who view Detroit as a North American Mogadishu. Such an opinion has a strong correlation with racism, it's worth noting: Detroit must be the perilous worst because it is held to represent black America.

As to the "never actually visited", do you claim that most, or even a _remote minority_ of Americans have "actually ever visited Detroit"? Of course they haven't. They laugh and point and repost and share the ruin porn because, ha ha, look at Detroit.

In any case, it was a pretty bizarre claim to use in response to my post given that I expressly said that I go to Detroit almost regularly. Indeed, "Canadians" in Southern Ontario almost certainly know more about Detroit than the bulk of Americans, for obvious geographical and practicality reasons.

Now maybe I'm not going to the "real" Detroit in some people's opinion, in that I am in built up urban areas and affluent suburbs, but it is a part of the whole of Detroit.

<comment><USER15> "...do you claim that most, or even a remote minority of Americans have "actually ever visited Detroit"?..."

???

I said that most of the people who have opinions on Detroit... American or not... have never been there.

I'm curious as to what exactly you are refuting ??? Or if you are just agreeing with me ???</comment></comment></comment></comment>


Beginners' Guide to Concurrency and Parallelism in Python - <AUTHOR> http://www.toptal.com/python/beginners-guide-to-concurrency-and-parallelism-in-python <comment><USER2> Finally someone who knows what they're talking about!</comment>


Chrome will finally eat less RAM from this December - <AUTHOR> http://thenextweb.com/google/2016/10/10/chrome-less-ram/ <comment><USER2> Most browsers these days treat RAM like it's an infinite source. Just because RAM is cheap doesn't mean a simple no-nonsense website should gobble up 200MB of RAM!</comment>


Xamarin opens beta to unknown new product - <AUTHOR> http://blog.xamarin.com/call-for-beta-participants/

<comment><USER2> I agree with Keith, I am hoping that they are getting ready to allow us to have one source code base that can be converted/compiled to run on all platforms. Very similar to what Codename One does with Java.

I was actually just getting ready to start developing my app in Codename One simply because I would only have to learn one framework and could have one source code base. Switching to Java from C# wouldn't have been too much of a hassle cause they are kissing cousins.

Anything is better than having to code in JavaScript! Don't let us down Xamarin - C#, UI Abstraction layer, Xamarin.Mobile, GUI Builder for drag-and- drop design. That's what is needed in order to remove the growing pains from switching to mobile development. Make it happen Xamarin!

</comment><comment><AUTHOR> The NDA asks an interesting question at the end about Mac vs PC preference.

Given Xamarin's recent mono.mac release, their targeting of a much more PC heavy developer set (C# people), their attempts to keep monotouch/droid simply add-ins to monodevelop...I am going to assume this is a new IDE aimed at cross platform mobile development.</comment>


Why Uber cares safety while rejecting fingerprint-background-check? - <AUTHOR> http://www.mystatesman.com/news/news/local/qa-what-austin-voters-need-to-know-about-the-prop-/nq9YN/ <comment><AUTHOR> I first read the ballot and was totally misled, Uber is promoting safety on all its ballots/ads/etc, then why they refuse fingerprinting? They tricked the wording so much that makes people believe "no fingerprint-background-check is more safe", which is the opposite, hate that, vote NO to whatever Uber wants for me.</comment>


Explainer: 'Stablecoins' in spotlight as Facebook unveils Libra cryptocurrency - <AUTHOR> https://www.reuters.com/article/us-crypto-currencies-explainer/explainer-stablecoins-in-the-spotlight-as-facebook-unveils-libra-cryptocurrency-idUSKCN1TJ1T6 <comment><USER2> I wish there were a bit more explanation provided on this paragraph:

> "Most are backed on a one-to-one basis by mainstream assets like the U.S. > dollar, while others are collateralized by baskets of cryptocurrencies. Some > use algorithms to maintain stable values."

Particularly the last two statements about "baskets of cryptocurrencies" and algorithms. I've only got a basic understanding of how cryptocurrencies work, does someone with a better understanding know what they're referring to here, and how backing with other crypto currencies would prevent speculation from massively inflating/deflating a so called "stable" cryptocurrency?

<comment><USER3> There are several projects exploring different algorithms for managing crypto- collateralized stablecoins; they all involve fairly complex feedback loops. MakerDAO aka Dai is the most prominent one and quite a bit has been written about it.

[https://medium.com/makerdao/stablecoins-collateralization- ty...](https://medium.com/makerdao/stablecoins-collateralization- types-2a860624dcd3)

[https://medium.com/reserve-currency/our-analysis-of-the- make...](https://medium.com/reserve-currency/our-analysis-of-the-makerdao- protocol-4a9872c1a824)

[https://prestonbyrne.com/2018/01/11/epicaricacy/](https://prestonbyrne.com/2018/01/11/epicaricacy/)

[https://cointelegraph.com/news/dai-has-been-struggling-to- ma...](https://cointelegraph.com/news/dai-has-been-struggling-to-maintain- its-1-peg-but-the-makerdao-community-believes-it-will-soon-be-cryptos-default- stablecoin)</comment></comment>


Hong Kong protester role-playing game suspended from Google Play Store - <AUTHOR> https://www.hongkongfp.com/2019/10/10/revolution-times-hong-kong-protester-role-playing-game-suspended-google-play-store/ <comment><USER2> The app is now available to install from the developers twitter account [https://twitter.com/of_yarns](https://twitter.com/of_yarns)

There's a link to the apk stored on S3.

I've been playing it a bit, it's an interesting games with a lot of thoughts by the author on branching the story based on your actions.</comment>


The Home Computer Museum - <AUTHOR> http://www.homecomputer.de/

<comment><AUTHOR> A very old website, one of my favorites, that I thought would be suitable for sharing here. Please take your time to enjoy the images, in particular the exhibition photos of the museum :)</comment>


Apple to Close iPhone Security Hole That Police Use to Crack Devices - <AUTHOR> https://www.nytimes.com/2018/06/13/technology/apple-iphone-police.html <comment><USER2> It's frustrating that you never hear the pro-unlocking scene actually looking past their own noses. Like back when you could bypass a linux login screen by pressing backspace 28 times. Obviously that's a problem, but could you imagine if police departments all over the country got pissed when that bug was fixed and started complaining that they couldn't use the exploit themselves? Like they're the only ones smart enough to use the exploit and nobody else would ever do such a thing for malicious reasons. It's so short sighted.

<comment><USER3> An issue which wouldn't exist if Apple provided access for people with warrants.

<comment><USER4> The problem is, how do you build a back door that can only be used by people with valid (and just) warrants?

You really can't go down your line of argument without answering thar

<comment><USER3> You centralize ownership, the same way it has been done since the dawn of the internet. Even Intel can securely update your microcode.

<comment><USER5> Yep, and private keys are never compromised.

Aside from the many, many known cases where they are: [http://legacydirs.umiacs.umd.edu/~tdumitra/papers/CCS-2017.p...](http://legacydirs.umiacs.umd.edu/~tdumitra/papers/CCS-2017.pdf)

<comment><USER3> As best as I can tell, if you don't trust OS or microcode updates, you can't trust your phone _at all_ unless you airgap it or somesuch.

<comment><USER6> Very true. Everyone should know their TNO, Trust No One. As far as I can see it's the only way to really operate in the world of computer security that we live in.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> > and all the kids we can't put into a position of safety

"For the children!" They can't think of a good reason to have access to all these phones so they blantantly use an idiom so tired that it's practically a joke.

<comment><USER8> I read that too, but it's quoted from a guy whose job is to protect children. The full quote:

> "If we go back to the situation where we again don't have access, now we > know directly all the evidence we've lost and all the kids we can't put into > a position of safety," said Chuck Cohen, who leads an Indiana State Police > task force on internet crimes against children.

<comment><USER9> >> all the evidence we've lost and all the kids we can't put into a position of safety,

There are two type of child abuse imagery: the new and original stuff that points to a kid currently being abused, the one can can be rescued, and the enormous mass of old material that forensic investigators have seen literally thousands of time before. Actual new abuse material that could lead to the rescue of a child is thankfully very rare. While these phones could lead to arrests, the likelihood of them leading to the rescue of a child is negligible.

Once upon a time the bulk of images on phones were originals taken by the phone. Now "phones" are really just internet machines and the images they are looking for are essentially browsing history and stuff saved from online sources.

<comment><USER10> > While these phones could lead to arrests, the likelihood of them leading to > the rescue of a child is negligible

I think you're ignoring some aspects of how the US criminal justice system works. Arresting a child abuser is one thing; they have to be tried in court and found guilty by a jury/judge. Criminal cases especially have a high requirements to prove guilt since they are very serious charges. So even if unlocking the phones may not help save actual children from abuse, I _think_ what the guy means is that you can get more convictions for these child abusers who have been arrested and prevent future children from being abused.

Note that I'm not stating an opinion about the ethics of reducing security of phones, only pointing out what the person meant when he said that doing so prevents child abuse.

<comment><USER9> Then he would not have described moving children to places of safety. He would have said something more like preventing future abuse. Talk about physically moving children is rather dramatic and specific.

</comment></comment></comment></comment></comment><comment><USER11> I highly recommend this 2016 paper by Stephanie K. Pell: "You Can't Always Get What You Want: How Will Law Enforcement Get What it Needs in a Post-CALEA, Cybersecurity-Centric Encryption Era?".[0] She's a former prosecutor from Florida, who now teaches at West Point.

She agrees with security experts that maintaining such lawful access, against pervasive "strong" encryption, would require the introduction of vulnerabilities, such as backdoors or key escrow. Which would expose users to malicious adversaries. She argues, basically, that law enforcement has become lazy.

She also raises the possibility of lawful hacking for smartphones, "infecting them with malware capable of capturing voice communications and keystrokes before they are encrypted." That brings to mind the FBI's use of network investigative techniques. And of course, all those NSA tools.

0) [https://scholarship.law.unc.edu/cgi/viewcontent.cgi?article=...](https://scholarship.law.unc.edu/cgi/viewcontent.cgi?article=1306&context=ncjolt)

</comment><comment><USER12> Doesn't it seem strange that they're not patching the actual exploit, only mitigating it? Do they have no idea what the actual bug is? Is the usb interface fundamentally insecure?

<comment><USER13> This approach mitigates the class of vulnerability, neutering the effect of this one and any similar future vulnerabilities.

This approach makes sense, since they do not know what this specific vulnerability is.

<comment><USER14> > since they do not know what this specific vulnerability is

How do you know this? I'd be shocked if they don't have one or more of these devices themselves and have it completely figured out.

<comment><USER15> No way would the makers of the device sell one to Apple - they probably have strict measures in place to only sell to police departments, with contracts in place to prevent re-selling.

Apple would have to buy one on the grey market, which they may be unprepared to do

<comment><USER16> > Apple would have to buy one on the grey market

No, they would have to pay someone to do "research" for them and figure out the vulnerability. They would pay that person enough to buy one on the grey market and figure out how it works, keeping their hands clean.

</comment></comment></comment></comment></comment><comment><USER17> > "They are blatantly protecting criminal activity, and only under the guise > of privacy for their clients,"[Hillar Moore, Baton Rouge District Attorney] > said.

I understand a Law Enforcement point of view of having access to private data in order to prosecute criminals. I disagree with that point of view, but I would never say that point of view is a guise to implement a surveillance state.

<comment><USER18> That quote jumped out at me too.

Like, does he actually believe Apple is using "privacy for their clients" as an excuse to accomplish their true goal of protecting criminal activity?

<comment><USER19> It sure looks that way. 'If you've got nothing to hide you've got nothing to fear' must be gospel for these people.

</comment></comment></comment><comment> munk-a This article is written in a terribly slanted style bringing up constant adversarial comparisons involving apple and law enforcement. There is an objective point of view to the article but it bundles in a lot of quotes and references that are highly slanted.

I am not someone who assumes all NYT articles are slanted, but this one is bad.

</comment><comment><USER20> Why do we only hear stories like this about Apple and the iPhone? How secure is Android? Is Google taking the same approach to protecting their users?

<comment><USER21> Google is definitely starting to take security more seriously with the Pixel: [https://www.blog.google/products/android-enterprise/how- pixe...](https://www.blog.google/products/android-enterprise/how- pixel-2s-security-module-delivers-enterprise-grade-security/)

<comment><USER22> I'd argue they, as a company, always took security pretty seriously, but never privacy.

FDE was pretty late and performed slow on early Android, among other issues.

</comment></comment></comment><comment><USER23> > _The Indiana State Police said it unlocked 96 iPhones for various cases this > year, each time with a warrant, using a $15,000 device it bought in March > from a company called Grayshift_

And what were the results? How many people did those 96 iPhones allow Indiana to bring charges against? In how many of those cases did Indiana prevail? And in how many of those was the evidence on the phone necessary?

<comment><USER24> These are the wrong questions to ask. There's no doubt that total surveillance would result in more crimes being solved, and more criminals being successfully prosecuted. It's not a question of whether the technique is effective enough that it should be allowed.

The question is can the government be trusted with a backdoor into our personal devices that "only they" can use? Should the people trust their government to only use that access lawfully, and can the people trust their government to protect that access from unlawful outsider access?

Since we've seen nothing but incontrovertible evidence, throughout history and to this day, that government cannot be trusted with this level of access to our personal devices (lives), then I can only hope that Apple and companies like it will fight to provide us with secure devices, and that our courts will protect our right to strong encryption to protect our personal data.

<comment><USER25> I see this line of thinking a lot in tech circles, but you really have to divorce this issue from the digital world. Imagine the exact same argument is about a safe instead of a phone. The government would simply request a warrant and then work on brute forcing their way into the safe.

If you have the same objections when using a safe, the answer to the problem has nothing to do with technology because you believer there is a fundamental flaw in the US criminal justice system. You aren't going to be able to consistently defeat the government by repeatedly trying to outpace them technologically. You have to instead change the laws that govern their actions.

If you think the rules should be different for a safe and a phone, you need to be able to explain why digital evidence should be treated differently than physical evidence?

<comment><USER26> The government is allowed to crack open a safe with a warrant. The government is allowed to crack open an iPhone with a warrant.

What does either of those things have to do with decrypting things found inside either the safe or the iPhone?

If the FBI found coded papers inside a safe, they could try to decrypt those papers, but couldn't compel the owner to assist them.

Security flaws are fair game for law enforcement. Secure encryption without exploitable weaknesses will probably defeat them even in the presence of a court order.

</comment></comment></comment></comment><comment><USER27> I have nothing to hide. I don't intend to do illegal activity with my phone. I also do not want a government entity to be able to access my phone or device simply because they can. I am also _very_ skeptical of any government entity that uses "because child molesters" as valid reason to shame a company for respecting privacy.

</comment><comment><USER28> The most surprising part for me is that iPhones have been relatively easily hackable by having access to the data port. That doesn't seem in-line with the high security advertised. What about the inaccessible hsm and all that other jazz?

<comment><USER22> The company didn't release the details of how their exploit works, but it is believed it is an automated brute force mechanism so it's actually attempting to bypass security by trying passcodes over and over, not breaking encryption. This is another method to slow down brute force attempts.

</comment></comment><comment><USER29> It took a while... I wonder if Grayshift have their next hole already lined up so that business can continue as usual...

<comment><USER30> If this fix disables the data port when the phone is locked, presumably all future zero-days will be blocked.

<comment><USER31> Naw, the next 0day might rely on Bluetooth being enabled even while the phone is locked, for example. Or even the cell radio being enabled. There's always some vector for attack.

(Even if it's none of these, the next exploit might be "we can decap the secure enclave and read/manipulate data on it with an electron beam")

</comment></comment></comment><comment><USER32> Isn't one of the main sources of data the iCloud backups?

<comment><USER33> When I was doing forensics for the police, 9/10 times if we had an iPhone we couldn't get into there'd be an unencrypted iTunes backup. Didn't even need to go to Apple for it, it's all local.

Wouldn't get everything from it, iirc it's photos, bookmarks, contacts and documents as well as some app storage (WhatsApp, notably).

<comment><USER34> Seeing that the last time that the only way you could back up your phone was via iTunes was before the introduction of iOS 5 in 2011, the chance of finding someone with an iTunes backup is slim.

<comment><USER14> Plenty of people are cheap and don't pay for iCloud storage which means if you want any backup at all it's local.

<comment><USER34> I have four devices on my account and I can back them all up with the 5GB free account. It doesn't back up your apps - just your data

<comment><USER14> That's great for you, but most people have enough photos and videos that 5GB isn't enough for a single device, let alone four. For a similar reason this is why many people complained that Apple continued to ship 32GB phones for so long, it's just too small for most people.

<comment><USER34> I use Google Photos and iCloud photo syncing. Pictures and Videos are automatically downloaded to my Windows computer.

[https://support.apple.com/en-us/ht205323](https://support.apple.com/en- us/ht205323)

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> The more I think about this issue the less interested I am in the extreme of either side. The government shouldn't have unfettered access to our devices, but I can't think of any other product in the history of the planet that gave people the ability to hide information so completely that the government could never look at it. To those that argue that our phones are an extension of our minds, that is both a bad thing and fetishizing our phones. Finally, couldn't I argue that my diary or journal is an extension of my mind (certainly more so than a phone)? Yet diaries and journals can and have been subpoenaed.

<comment><USER36> > any other product in the history of the planet that gave people the ability > to hide information so completely that the government could never look at > it.

Any volume-level encryption?

<comment><USER37> Or anyone's who come up with a half-decent code that's stored only in one or two brains. There are various medieval alchemical manuscripts which have never been fully deciphered.

</comment></comment></comment><comment><USER38> _> an hour after the phone is locked [...] In order to transfer data to or from the iPhone using the port, a person would first need to enter the phone's password. _

An hour seems like a long time?

On Android (at least, on my device) the USB port is always charging-only. For data transfer you must always unlock the phone and accept a notification for MTP/PTP mode.

<comment><USER39> You don't have to hack into an Android phone if you are the police. The data is available to you in multiple places. (Including the phone.)

That's why this semi-adversarial relationship exists principally between Apple and Law Enforcement. Not necessarily Google or Samsung and Law Enforcement.

</comment></comment><comment><USER40> for enough money, pretty much anything can be backdoor-ed if it hasn't already. The FBI, CIA NSA,. etc have a huge trove of 0-days for this purpose. It's like "I thought TOR made me anonymous" ha you thought wrong.

</comment><comment><USER41> >In order to transfer data to or from the iPhone using the port, a person would first need to enter the phone's password. (Phones could still be charged without a password.)

So how long before the NSA has it cracked with power signal analysis?

<comment><USER42> If we could ban parallel construction than any NSA exploit would be rendered worthless for domestic criminal prosecutions.

<comment><USER39> There's a ban against law enforcement planting evidence on innocent detainees. That ban hasn't really stopped police departments across the nation from doing that very thing.

[https://www.nola.com/news/index.ssf/2008/09/city_settles_law...](https://www.nola.com/news/index.ssf/2008/09/city_settles_lawsuit_against_n.html)

[https://www.nytimes.com/2018/02/06/us/baltimore-police- corru...](https://www.nytimes.com/2018/02/06/us/baltimore-police- corruption.html)

Etc etc etc

I'm fairly certain a ban on parallel construction would not do you much good.

</comment></comment></comment><comment><USER43> Perhaps then its high time we encrypt all personal computers as well by default.

<comment><USER44> Ah yes. Windows 10 has a built in drive encryption. It should be enabled by default.

(little do they know, it sends the encryption key to microsoft)

</comment></comment><comment><USER8> If guns had the same safety mechanisms as the iPhone, maybe we'd see fewer shootings. You know, register a gun to an owner, not allow anyone but the owner to fire the gun, etc. (yes, I realize ownership is already registered, but you can circumvent registration through various means)

<comment><USER45> It's also simply not practical to apply these mechanisms to guns without making them less safe or reliable.

A gun must always work when needed for protection - it's not like software where it's ok to be "down", rebooting, or having battery troubles some of the time.

<comment><USER46> > making them less safe

That's a very spun definition for "safe". Any individual gun is _far, far, FAR_ more likely to be used to commit a crime than deter one.

<comment><USER47> That depends on how you define "used". And furthermore, while it _may_ be true for guns on average, it's not true for _any individual_ gun. You are confusing individuals for averages.

</comment></comment></comment></comment><comment><USER48> I always see headlines about this for iOS. What about android? Is it crackable?

<comment><USER49> Yes, easily.

</comment></comment><comment><USER50> Is that the one they use to remote exploit iphones? Or is that a backdoor?</comment>


Memoranda (a contrast of Jobs's and Ballmer's styles) - <AUTHOR> http://daringfireball.net/2008/08/memoranda

<comment><USER2> _[Ballmer's] mockery of Google's search as "a white page with 10 blue links" indicates that he has no idea why Google has been so successful. I'd wager that if anyone is ever going to gain on Google in search, it will be by presenting even more focused results — less clutter, fewer distractions, more emphasis on making the results easily scanned._

Hmmm, reminds me of something Paul was saying the other day about ideas he'd like to fund...

<comment><USER3> Take a look at Kosmix.com

Ignoring relevance for a sec, which display of results looks better? Kosmix by a mile. I think that's what Ballmer means when he says he wants to move beyond 10 blue links. Amidst the aura of "FAIL", one nice thing Cuil had was that you didn't really need to scroll down to see all the results. There's room to beat Google in displaying results better, and that's what Kosmix, PG, and Ballmer are all trying to do, each in their own way.

I don't think the company that beats Google will do it by "out-Googling" them.

<comment><USER4> The home page linked me to <http://www.kosmix.com/topic/In-N-Out> as a sample search.

Is that really superior? If I were in middle school, doing a research paper on In-N-Out, I could see the appeal. It seems fairly humming with information. Certainly it feels like it could fill a poster board.

Mostly, it seems to be trying to anticipate my _next_ search related to In-N- Out. Did I really mean "In-N-Out videos"? Did I mean "where's the nearest In- N-Out"? Did I mean "what does 'animal style' actually mean?"

But really, if I had wanted any of those things, wouldn't I have used those as my search terms? As it stands, I find the page a little confusing; I don't know where to look amidst all that second-guessing.

</comment></comment></comment><comment><USER5> There's a big difference between the two memos. Jobs' email is "guys, we messed up, let's learn from it". Ballmer's email is to fire up the troops.

I think the different purposes of the two memos explain the difference in styles. It's not a function of the two's personalities.

</comment><comment><USER6> "which means Microsoft had more revenue and nearly twice the net profit of Apple and Google combined"

Wow, I thought Google was having more profit than Microsoft already. Why is everyone pointing Microsoft as dead and Google as the leader then? At least it's not the case yet.

<comment><USER7> nobody is saying microsoft is dead. but their peak is almost certainly behind them. they've already lost their leadership role, and their actions as of late have convinced most of us that they have nowhere to go but down.

they are well on their way to duplicating ibm's progression into a profitable but not terribly newsworthy tech company.</comment></comment>


Show HN: Vimer – Convenience wrapper for gvim/mvim --remote(-tab)-silent - <AUTHOR> https://github.com/susam/vimer#readme <comment><AUTHOR> Here is a brief description of the files from the commit log:

There are two scripts.

* vimer.cmd -- Batch script for Windows

* vimer -- Shell script for Linux and Mac OS X

I have been using these scripts for about six years now. I wrote them when I was working on multiple desktop environments, and I wanted a uniform and convenient way to open a file for editing in GVim while navigating directories in a shell or a file browser. I also wanted to ensure that while doing so the desktop does not become cluttered with too many editor Windows.

The scripts solve the problem of editing files from the shell. The Windows script is also capable of creating context menu options to edit files from Windows Explorer. The README.md file contains detailed documentation on how to create similar context menu options in Linux and Mac OS X.

I am releasing these scripts and the documentation now under the terms of the MIT License in the hope that these might turn out to be useful for others who use Vim the way I do.

More details are in the README: [https://github.com/susam/vimer#readme](https://github.com/susam/vimer#readme).</comment>


March 10: Meet YC partner Jessica Livingston in Berkeley - <AUTHOR> http://www.foundersatwork.com/dalloway.html <comment><USER2> It's been on my calendar for about a week now. I'll be driving over to Berkeley tomorrow morning to spend the day. Will you be there for her presentation, Paul?

<comment><USER2> Ah, your website answered my question. Looking forward to it.

And of course, I'm going to want you to sign my copy of the book as well!

<comment><USER3> highly recommended to everyone who can to attend this event. jessica has learnt ALOT from interviewing all these founders and she can relay the experiences fantastically well.</comment></comment></comment>


My thoughts on Do Not Track and online privacy - <AUTHOR> http://playtomic.com/blog/post/56-my-thoughts-on-do-not-track

<comment><USER2> I pretty much agree. Raising awareness is a good thing. However, as far as actual implementation, Do Not Track seems about as useful as the Evil Bit. All it means is that well-behaved services have agreed to not track you when you've flipped this switch. What about the not-well-behaved services? It seems that potential danger from them is even greater.</comment>


Europe should forget Google and investigate its own shortcomings - <AUTHOR> http://www.ft.com/cms/s/0/6425979e-07b0-11e6-9b51-0fb5e65703ce.html <comment><USER2> Why not investigate both?

</comment><comment><USER3> This reeks of propaganda.</comment>


Steve Jobs is a drug addict with no honesty and no integrity - <AUTHOR> http://www.washingtonpost.com/business/economy/steve-jobss-unflattering-fbi-file-mentions-drug-use-265-gpa/2012/02/09/gIQAza8d2Q_story.html

<comment><USER2> Can we have a less inflammatory title in respect for both somebody who had an enormous positive impact on the world and has passed.

the article does not call him 'a drug addict with no honesty or integrity'. That is just poor link bait.

I'm not even a fan of Jobs, but this kind of labeling isn't what HN is about.</comment>