How about some Android graphics true facts? - <AUTHOR> https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

<comment><USER2> It appears to me that this article is trying a little bit too hard to paper over the poor UI performance of Android compared to iOS or WP7, and making up excuses for less than optimal drawing performance.

It doesn't say _why_ GPU rendering isn't much faster than CPU rendering on Android, it doesn't say why using OpenGL adds 8 MB to the RAM overhead to a process (something I can hardly believe by the way), it glosses over the fact that even though you _could_ render some things at 60 fps using just the CPU, that still means these CPU cycles can't be used for anything else, it doesn't mention the fact that GPU rendering is almost always more power-efficient than CPU rendering, and it doesn't differentiate at all between _what_ can efficiently be rendered by the Android hardware rendering and _how_, besides making the distinction between compositing and 'rendering in a window'.

The final comment about memory bandwidth also makes little sense when talking about CPU rendering vs GPU rendering. Most mobile GPU's use some form of tile- based deferred rendering that allows the use of dedicated on-chip local buffers and efficient caching, to greatly reduce RAM bandwidth pressure. If anything suffers from constrained RAM bandwidth, it's CPU rendering.

From a technical perspective this article is a very naive analysis, at best.

<comment><USER3> >It appears to me that this article is trying a little bit too hard to paper over the poor UI performance of Android compared to iOS or WP7, and making up excuses for less than optimal drawing performance.

I'm surprised that many people are still bashing UI responsiveness/performance. I've held and played with many devices (including, but not limited to, iphone 3 and 4) and I can't really say what's bothering so many people. For me, every android device that I've used in the last 2 years feels fast and responsive. I'll just go out and say that it's a non-issue for mainstream user.

<comment><USER4> "I'll just go out and say that it's a non-issue for mainstream user."

Might also be why the "mainstream" is primarily using Apple iPads/iPods/iPhones vs the myriad of Android devices available.

What bothers people is that when you swipe from screen 1 to screen 2, there can be a > .5 second delay. It doesn't feel remotely "natural" for something that you're physically touching and supposedly interacting with.

<comment><USER3> >Might also be why the "mainstream" is primarily using Apple iPads/iPods/iPhones

I don't believe the reason for that is UI responsiveness (also, I don't agree with your 'primarily' assessment, but let's not chew on that). In my opinion, the differences are so small that UI performance just isn't an issue. There are other areas where iDevices are noticeably better compared to every competing device.

>What bothers people is that when you swipe from screen 1 to screen 2, there can be a > .5 second delay

Hm, I don't remember that ever happening to me in the last ~2 years with two devices that I've used most: nexus one and motorola defy. But ok, I grant you that it _can_ happen. So what? I've also seen an iPhone freeze completely.

<comment><USER5> _Hm, I don't remember that ever happening to me in the last ~2 years with two devices that I've used most: nexus one and motorola defy. But ok, I grant you that it can happen. So what? I've also seen an iPhone freeze completely._

That's funny. I use a Nexus S on a daily basis, and compared to my primary phones I've used over the last 3 years (iPhone 3GS, 4, and now 4S), the touch screen is awful.

The incontrovertible truth is that every mainstream Android device on the market, including the newest SGS2's, have this annoying 500ms/20 pixel touchscreen 'slop'. And it's annoying as hell. It makes the touchscreen and all the widgets feel slippery. It ruins the built-in android keyboard (I can type at 40+ words per minute on the ios5 touchscreen keyboard, and I need swiftkey if I want to type that fast on android).

Ignore this all you like. Those of us who want something better know where to get it.

<comment><USER4> But you're forgetting the other big screen criteria people have: "not from Apple". Once you factor that in, the Android platforms all fare much better. :)

<comment><USER6> Or rather, not from a monopolistic company bent on calling users criminals for accessing their own devices.

But yeah, if you agree that that describes Apple to a T, or maybe a P, then "Not Apple, (or Microsoft, or ...)".

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Those are some nice technical details and it's right to correct them when someone gets them wrong.

They ultimately, however, don't matter†. If scrolling on one device makes me want to throw the device at the wall while on another device I don't even notice that I'm scrolling, then that's a problem.

I'm looking forward to trying out an Android 4.0 device to see whether I still want to throw it at the wall. That's the only thing that matters to me. (Lagging is only part of the problem and occasional lagging really isn't a problem. What always annoyed me much more was the delayed reaction. I swipe, nothing happens, the page scrolls. That's extremely annoying.)

—

† They obviously do matter. Different implementations lead to different results. But only talking about the implementation and ignoring the results misses the point.

<comment><USER8> It blows my mind that people can't understand that scrolling "feels right" is a show-stopper feature for a touch interface.

Meanwhile, at Apple, they would have got it right in version 0.1, and Steve Jobs would treated that as prototype quality and made the team do 10 better variations.

<comment><USER9> Apple makes compromises, too. On the original iPad scrolling can be really laggy (probably only after installing a couple of apps, so you won't notice it in the store).

Meanwhile, the current generation of dual core Android phones have hardly any lag issues anymore.

<comment><USER4> Somewhat agreed. It _can_ be laggy, but on mine it rarely is (but it does happen). However, it's never consistently choppy when scrolling.

So... laggy sometimes, but still smooth scrolling.

Every Android device I've tried (just tried a couple tablets at a Best Buy this week) have been consistently laggy (response times to swipes) and choppy scrolling.

<comment><USER10> Actually the first time I used an iPad I was blown away by the smoothness of scrolling in web pages, and it still holds up really well today IMO

<comment><USER9> Yes, because the scrolling is very well supported by hardware. But you will notice the slowness when you are zooming in/out of pages (the font smoothing takes about half a second). But Apple got it right compared to Android, and you are right that even today the iPad holds up well, considering its hardware (reminds me of the C64 which was able to smoothscroll because of hardware support, while the PC didn't manage it at that time)

</comment></comment></comment></comment></comment></comment><comment><USER11> Android's graphics problems are not due to a lack of hardware acceleration. They're due to poor architecture.

The reason iOS is so silky smooth is because each view in UIKit is backed by a CoreAnimation layer which will be a pixel buffer in hardware. This means that if you move a UIView in iOS, no new rendering needs to be done of stuff that was "uncovered" by moving the view since each UIView has the full contents of its view stored in its CALayer. All that needs to happen is all of the layers are composited in their new positions which hardware will blazingly fast. However, as I understand it in Android, each Window (containing multiple Views) is one pixel buffer in hardware. Each view then draws in to that. This means that if you move a View in android, another view will be "uncovered" and since that area of the screen isn't stored somewhere, it has to go down the view tree rendering the now uncovered area of the screen. Even if that rendering is hardware accelerated, it's still going to be muuuuuch more work that just recompositing all the layers on the screen as in iOS, I mean imagine if there's text uncovered there? That's not going to be quick.

Now, there are downsides to iOS's approach - it uses a bunch more memory. But the upsides are basically what makes iOS good - all those silky animations. Android's just getting to a similar level of smoothness, but mostly only through better hardware.

(Caveat: How android works may have changed since I last looked, but that just makes the mystery of lack of smoothness even more interesting ;-) )

<comment><USER11> Did a bit of investigating. It seems you can make Android views use layers as iOS does. But it's off by default (maybe because of this OpenGL using 8MB of memory per process thing).

(Further reading: [http://developer.android.com/reference/android/view/View.htm...](http://developer.android.com/reference/android/view/View.html#getLayerType\(\)) )

Edit: Also, I missed where she said that in her post: "Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application's windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default".

Unfortunately only the the Samsung Galaxy Nexus has Android 4 and I'm not sure there's anything other than a few tablets that have Android 3?

<comment><USER12> Turning on hardware acceleration doesn't cause all Android views to be FBO- backed. You still need to toggle the layerType to LAYER_TYPE_HARDWARE on each view, as far as I'm aware. I think the G+ post is a little disingenuous in that regard.

Google suggests toggling between LAYER_TYPE_NONE & LAYER_TYPE_HARDWARE pre/post animations. This need to actively manage view cache behaviour probably leads to developers being unaware of what to do.

<comment><USER13> If you want to enjoy both smooth scrolling and responsive input method in a webview, you need to juggle between those layer types.

LAYER_TYPE_HARDWARE enables smooth hardware-backed scrolling but glitches badly when the soft keyboard is visible (no resizing/panning of the webview, multiple seconds of delay between key type and text updates inside textfield forms).

LAYER_TYPE_NONE makes scrolling in the webview unbearably stuttering, but at least the soft keyboard becomes responsive, the webview pans correctly to show the field in which you're inputting text, and the key types are instant.

On top of that, there is the problem that you don't have access to keyboard show/dismiss events, so you have to inject javascript code to catch those in every page you plan your webview to display. This is at least the case on the Motorola Xoom and the Acer Iconia tablets running the latest versions of honeycomb.

<comment><USER14> There must be a different underlying issue there. Showing a keyboard view should have no performance implications on a web view. Similarly drawing text into a texture tile should not take "multiple seconds of delay".

</comment></comment></comment></comment></comment><comment><USER15> Is this a defense for Android's poor responsiveness (often blamed on a lack of hardware acceleration), or is there some other context I'm missing?

Doesn't this make Android look even worse? I.e., "Android already has hardware acceleration but still doesn't seem to perform very well" means any hope of flipping some magical GPU acceleration switch and instantly fixing the problem is gone.

<comment><USER16> The context is a bunch of people going around pretending they know why Android behaves the way it does, when in fact they have no clue what they're talking about. It's not a defense of anything, it's just injecting facts where there has been a distinct lack of them.

</comment></comment><comment><USER17> So, in summary, "We have hardware acceleration, have had it for a long time, but it isn't the reason android interfaces are almost universally clunky. We actually have no idea why that is."

I don't use any apple products but I get tired of Google touting how much better 4.0 is when most people are locked into phones running 2.2 or 2.3 for years into the future.

<comment><USER18> A lot of the 2011 phones should be updated to Android 4.0, and the ones who bought them in 2010 will upgrade next year to Android 4.0 phones.

<comment><USER19> [http://theunderstatement.com/post/11982112928/android- orphan...](http://theunderstatement.com/post/11982112928/android-orphans- visualizing-a-sad-history-of-support)

</comment></comment></comment><comment><USER20> From the article:

 _There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let's be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We've already blown our per-pixel budget, and we haven't even composited the separate windows to the final display yet._

I find this bizarre. Are all of these drawing operations using alpha blending (using translucency)? If so: is that strictly necessary for the entire area of all of them?

If they aren't using blending, why on earth do they have so much overdraw? The GPU could reduce that to touching each pixel exactly once by using the Z buffer and drawing in front-to-back order.

<comment><USER21> I thought you raised an interesting point and posted your comment over there. Romain Guy answered : 99% of the drawing operations performed by the UI involve alpha blending. We have optimizations of our own to limit overdraw (for instance layers generate meshes to avoid blending completely transparent fragments). So there's overdraw, just not as much h nS

</comment></comment><comment><USER22> I'm really, really sick of hearing Google engineers saying that there's nothing wrong with Android rendering. No offense, but post like this one makes them looks like idiots.

Just put any newest and fastest Android phone with dual-core CPU next to iPhone, or even worse WP7 which essentially works on two years old hardware, and everyone can see the difference. I don't care if it's software or hardware, I'm not interested in excuses about the work in the GUI thread. What I'm care is - the phone is something I touch. If I don't have immediate response to my gestures, the device is useless to me. As simple as that.

<comment><USER16> You seem to have read a much different post than I did. Where did she say there's nothing wrong?

The post is relating facts about "how graphics rendering works on Android", it says so right at the top. I see absolutely nowhere that it says anything like "there's nothing wrong".

<comment><USER23> It seems that when you've decided what the article says before you read it, it makes forming opinions (and avoiding cognitive dissonance with respect to your existing ones) a lot easier.

</comment></comment></comment><comment><USER24> [offtopic] Isn't saying "true fact" redundant? Unless it's _true_ , how can it be a _fact_? [/offtopic]

<comment><USER25> I believe it's meant to be ironic, in other words taking a poke at the so called "facts" that people generally toss around (although that doesn't make it less annoying).

</comment></comment><comment><USER26> So I'm guessing that the reason iOS home screen scrolling is faster is because it has much fewer things to draw?

<comment><USER13> I wonder if it has anything to do with the Delegate pattern used in iOS vs Android's Listener pattern when it comes to handling continuous touch events on the main thread, rather than the rendering speed.

<comment><USER27> i think this is probably the most accurate thing that can be said. thank you for posting this, do you think the linux scheduler subtleties / server- process-optimization may add to this?

<comment><USER13> I'm afraid I have absolutely no knowledge of these. I'm more of a high-level self-taught app dev, things that happen under the hood go far above my head most of the time :)

</comment></comment></comment></comment><comment><USER28> Will Android 4 still redraw everything when rotating the phone instead of animating?

This is not only a bad experience for users but also is one of the most difficult parts when developing Android apps.

</comment><comment><USER29> Relevant to this discussion is this video:

[http://www.google.com/events/io/2011/sessions/accelerated- an...](http://www.google.com/events/io/2011/sessions/accelerated-android- rendering.html)

</comment><comment><USER30> The comments in these gadget threads are so polarized, it's positively toxic.

<comment><USER31> Not enough people have read an understood pg's essay on ID. People are making the gadget a part of themselves so they behave irrationally about it.

</comment></comment><comment><USER32> Not to be a jerk... But this still doesn't address why every Android home screen _I've seen_ (including new 4.0 devices) looks like a laggy piece of shit when sliding around between different screens.

<comment><USER33> How can you say "4.0 devices" (plural) when there is only one announced 4.0 device, which is stunningly smooth in the video and in actual use?

I think you're just repeating the meme of "lol Android graphics are bad" which hasn't been true for at least 2 years, even with relatively weak phones (like the Optimus _X_ )

</comment></comment><comment><USER34> I seem to recall hearing that one of the main drivers of people's preferences for Android or iOS scrolling is how far you have to move your finger before scrolling starts. The delay in space, rather than in time.

I can understand why Andoid would have theirs set as they do, but I also understand how someone used to iOS could find it unpleasant.

<comment><USER35> That actually changes in Android 4.0 (Tested ICS on my Nexus S.. scrolling nearly instantly starts)

</comment></comment><comment><USER36> Why is it that OpenGL adds any overhead? I doubt this is the case on iOS.

</comment><comment><USER37> Hardware rendered vs software rendered??? :/

It's all just software. The only thing that matters is how fast it is.

<comment><USER37> Downmodders: Can you explain why?

My point is, software is rendering the graphics. Either it's software running on one chip, or it's software on another chip. That's irrelevant. What matters, is how fast the graphics are rendered.

<comment><USER38> There is a big difference between hardware and software rendering. Software rendering has you plotting each pixel individually and writing to the framebuffer. Hardware rendering uses specialized APIs and hardware to dramatically speed up drawing and transformation functions.

<comment><USER37> No, they both involve software, writing to a framebuffer. (By software, I mean code - software/firmware/etc).

A crappy 'hardware' accelerated GPU can be slower than a 'software' framebuffer write.

My point was that saying "It's hardware accelerated" is meaningless marketing speak.

<comment><USER12> Indeed, Apple's Mac OS X QuartzGL framework (GPU accelerated drawing/rasterisation) is slower than the equivalent CPU-based Quartz framework in may cases.

You're being shafted by downvoters who don't really know what they're talking about.</comment></comment></comment></comment></comment>


Can a £15 computer solve the programming gap? - <AUTHOR> http://news.bbc.co.uk/1/hi/programmes/click_online/9504208.stm

<comment><USER3> I think its an interesting project, and if they can actually produce it as inexpensively as they hope (or even twice that - $50 is still a good price point!), I think it will be useful in schools simply because kids will be able to own one themselves, bring it home etc, which I think will inspire (at least some of) them to learn more and do more interesting things with them outside of the classroom. As somebody in another HN post about this said: "get technology into as many hands as possible" - this is certainly a great thing!

However, I think the statements in the video about how computers have become much more complex and that is why people aren't learning to program them at a young age is incorrect. BBC Micros and ZX Spectrums (and Commodore's and Amigas and all the rest) were, IMHO, _not_ easier to learn with compared to todays computers. They were actually much less accessible and therefore attracted the type of people who were able to learn. Smaller audiences of more capable people (because the less capable people were never attracted to them in the first place) gives the illusion that they were simpler and easier, even when they weren't.

Todays computers are usable by just about anyone and most people are exposed to them in some way through games, social networking, websites.. whatever. The amount of people learning to program is probably a lot higher today than it ever was as the barrier to entry is so much lower (going from something as simple as Scratch, to web development with Javascript, to Ruby and Python and Processing - a lot of simple, yet powerful, tools (with instant feedback) are now available), its just that the percentage of people learning to program out of all the people using computers is now a lot lot lower.

I don't see how this device would be able to make it any easier than a full blown computer (once somebody found and installed the software for the kids) except that 1) it will have the tools preinstalled and 2) it will be inexpensive enough that each kid can be given their own one creating a sense of ownership and hopefully inspiring and encouraging them to do cool stuff with them (which in turn means they learn more).

TL;DR: This thing does have potential, but I think they (at least the people who made the video) are focusing on the wrong thing (bringing back the 80's of computers and programming because they feel it was simpler back then, while I believe it is a lot lot simpler _now_ ).

<comment><USER4> Having been there and having done that and still being involved, I respectively disagree. It was simpler in virtually all respects. I watched people of all different levels of interest and education (house wives, grad students, math majors, art majors and so on [notice no comp sci---there wasn't such a program]) learn to program in a subset of IBM BAL---this before any of the various micros you mention existed. Later when such things became available I was lucky enough to watch a very much larger audience teach themselves what they needed to know in order to accomplish what they wanted to do. And all of this before the internet had escaped the clutches of DARPA. In most cases, all that was available was the machine and the documentation that came with. In sum, I know what it takes to be creative now and I know what it took then. I would suggest that at best, it might be a draw. My bias would like to say that the good old days were better, but given the richness of today's environment, in fairness I have to come down squarely in the middle.

<comment><USER3> As I said in my other reply[1], I suspect it _seemed_ easier out of necessity. Today, you can turn on a computer and it can be useful and provide value without needing to learn to program or how the machine works. Back then, you more or less had to learn about the machine or about programming to really get much value from the computer. Necessity is the mother of invention. I think I was much more inventive and creative with my programming when I first started out because I didn't know what was possible, so to do the crazy advanced things I wanted to do, I was forced to be creative and try weird and wonderful things and use my computer or programs in ways they weren't really designed for. I learnt a lot because of this. Now I can just reach for an existing solution and not learn a thing, because I now know where to look or what to try. I'm not sure the raspberry pi can hope to achieve this. In fact, besides the low price point and the fact that they have solder points for general purpose I/O (which I think could be a huge selling point and benefit to learning - physically connecting things to it should help motivate and inspire kids), it is still a complex modern processor running a complex operating system (Ubuntu) and doesn't really have anything other modern computers don't have.

Either way, I'll ask this: Why do _you_ think people found it easier to learn to program back then than it is now?

[1] <http://news.ycombinator.com/item?id=2622880>

<comment><USER5> I think you both raise valid points.

I think the 80's home computers were objectively much simpler than modern computers. And therefore it was easier to gain deep understanding how it worked and then how stuff can be accomplished with it. On the other hand, modern computers are almost impossible to understand at the same level, but then it is not necessary to do so. We have operating systems and compilers that take care of lots of stuff, and therefore modern computers are easier to use, and probably have gentler learning curve.

The necessity and motivation are also a important factor. If you are doing small stuff (like hello world etc) then the work feels much more compelling when it transforms a "useless piece of plastic" into a "magical box that does awesome stuff". With full featured linux distro, you already have "magical box that does awesome stuff" and your own work doesn't really add anything to it.

<comment><USER6> The problem is that kids today don't think of a computer as a "magical box that does awesome stuff". Nowadays, computers are just tools. They're not special; they're everywhere, and they can be used to do boring stuff, or useful stuff, but they're definitely not regarded as "magical", any more than a car is, or a TV. This is probably a depressing thought to those of us who remember a different time, but it was inevitable.

</comment></comment></comment></comment></comment><comment><USER5> I think Raspberry Pi is missing the point by running "normal" Ubuntu Desktop on it, and having such limited connectivity.

Stuff that I'd add:

* (Ethernet) networking. Or at least some serial ports. Or some way to plug two or more of these together (something over USB maybe?)

* USB hub. First of all, using male USB connector as host port is just plain ugly. Secondly, if USB hub is a requirement to actually use the computer (as it seems to be currently), why not have it built-in?

* Analog video and sound output. Doesn't need to be HiFi, composite video and builtin DAC will be fine.

What I would change/remove:

* Ubuntu. Instead run some minimalistic system that boots directly to simple REPL, and allow more powerful programming somehow (inline ASM?).

* The SoC is huge overkill. And imho way too complex for a beginner to understand. Of course if you plan to teach just some high level language that hides all the hardware from you then it doesn't matter, but then the hardware wouldn't matter at all, and just using some off-the shelf x86-box would yield same results.

* Few GPIO pins are good. Arduino shield compatibility would be great.

tl;dr. I would make the computer more like self-hosting arduino and less like gimped generic ubuntu box.

</comment><comment><USER7> OK David this is cool and all, graphical Linux desktop on a USB stick, but please keep working on Elite 4 [1] , it's been a long wait so far...

[1] <http://en.wikipedia.org/wiki/Elite_4>

<comment><USER8> With Duke Nukem going gold, it can only be a little longer _.

_ for values of little not exceeding Braben's lifetime.

<comment><USER7> yes, DNF going gold is definitely a good omen, apparently Frontier are committed to getting 'The Outsider' out of the door before they can focus on Elite 4 full time though. So I'm not holding my breath...

(sounds like a really promising game though) ref: <http://frontier.co.uk/games/outsider/>

</comment></comment></comment><comment><USER9> The company that employs me has a Linux-based product that allows you to connect extra monitors and keyboards to single computer and have multiple logins on the same computer. We have equipped a computer lab with this configuration and the students use it write applications with Eclipse, browse Facebook. It is not too complicated for them.

This is the page (its in Bulgarian, but Google translator does an excellent job):

[http://translate.googleusercontent.com/translate_c?hl=bg&...](http://translate.googleusercontent.com/translate_c?hl=bg&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&tl=en&u=http://otb.bg/sumu&usg=ALkJrhh9ukAZbQLBelQERLVYV4jm1838gw)

Feel free to ask away if you are interested, we have contacts on the website :-).

</comment><comment><USER10> A £15 computer sounds cool, but programming can be done in your web browser. Just write some javascript and let the whole world instantly see your creation.

<comment><USER11> Yeah but you only need to spend £15 on the computer to fire the web browser up on now.

<comment><USER12> The misleading thing about the '£15' Raspberry Pi is that the main peripheral I/O is via USB, so to get this device on the 'net you must factor in at least another £17 minimum for a powered USB hub and USB network adaptor - and then we have a £32 USEABLE computer. It would have cost about £2 to add an RJ45 Ethernet adaptor to the basic design so I hope this will be considered in due course (I have contacted the developers about this)

</comment></comment></comment><comment><AUTHOR> The official website is <http://raspberrypi.org/>.

</comment><comment><USER13> Fair warning, auto-starting multimedia ad.

<comment><USER14> Where's the ad? It's the BBC website.

<comment><USER15> Users of the BBC website outside the UK get served ads.

<comment><USER16> Not if they are using Adblock Plus with Easylist.

</comment></comment></comment></comment><comment><USER11> A history lesson for those either too young to know, or not from the UK. This will explain a few gaps.

Back in the day (i.e. around the late 80's) we used to have PROPER computers in schools in the UK that everyone had free access to. My particular school had a large network of BBC Master[1] and Acorn Archimedes[2] machines - <USER2> proprietary platforms but OPEN with respect to documentation and doing what the hell you liked with them. In fact, Acorn, the manufacturer would tend to shove all the hardware reference and programmers guides in the box with the machines (you could not break the software on them). They ALL had BBC BASIC (very advanced variant of structured BASIC) with an inline 6502 or ARM assembler and most of the earlier machines had analogue and digital IO you could just stuff things into. They were all networked together as well and could talk to each other.

We were ACTIVELY ENCOURAGED to build stuff that plugged into these (rather than the recent policies and AUPs that students have to live with) and write software to control things and even modify the operating system at will. We built a massive transit shuttle system based on Lego, we build automated cranes, we build light sequencers, we built anything we damn wanted and were applauded for it.

Most of the software devs I know in the UK (other than the young and really old ones) tend to have cut their teeth on this kit.

Then there was the introduction of the PC which destroyed all this in favour of "security", "acceptable use policies", "black boxes", "no documentation" and "vendor lock in".

Mr Braben was a pioneer of these machines [3] [4] and is held close to the heart of many people. He wants the education sector to go back to these days (rather than the utter corruption that Research Machines, BECTA and Microsoft have destroyed everything with recently) because he truly KNOWS what is good for the industry i.e. people who know how stuff works and are free to understand.

Ironically, on a slight tangent, my children have Linux machines in their school these days rather than Windows, which is used for administrative functions only. It'll only be a few years before my eldest discovers gcc.

[1] <http://en.wikipedia.org/wiki/BBC_Master>

[2] <http://en.wikipedia.org/wiki/Acorn_Archimedes>

[3] <http://en.wikipedia.org/wiki/Zarch>

[4] <http://en.wikipedia.org/wiki/Elite_(video_game)>

<comment><USER15> The BBC micros were one side of the coin, perhaps the more respectable and middle-class side.

Round my way, it was Sinclair all the way, because they were cheap. The ZX81 is perhaps the archetype - they sold 1.5 million units, mainly to people who had no idea what they would do with a computer. At £69.95, it was cheap enough to be an impulse buy for most people, cheap enough that kids saved up their paper-round money.

A lot of early buyers ended up building their ZX81s from a kit (because it was £20 cheaper) and learned a lot. Even for those that bought it pre-assembled, there wasn't much to do but learn. The unexpanded ZX81 came with just 1kb of RAM and no bundled software, but it did come with a spiral-bound "Teach Yourself BASIC" book. The keyboard was covered in markings for BASIC shortcuts.

At the time, several magazines consisted of little more than printed source code, mainly for games, that you could type in yourself. These programs were invariably rubbish, but a mag was at least a quid cheaper than the cheapest of games on cassette so they sold shedloads. You'd spend an hour typing it all in and fixing all your typos, only to realise that it was a hopelessly boring game. Fiddling about with the source code was the most interesting thing to do.

The more enterprising kids realised that they could do better and earned a bit of pocket money selling programs to the magazines. The really enterprising kids knuckled down and wrote a retail-quality game, which in the mid-eighties you could do during the summer holidays. The origins of a large proportion of the British video games industry can be traced directly to a teenager, a Speccy, a blank tape and a particularly gloomy August.

<comment><USER17> > At £69.95, it was cheap enough to be an impulse buy for most people

Not to detract from the rest of what you say, but I think you might have a skewed idea about how much spare cash "most people" had in 1981.

<comment><USER15> We could argue endlessly over that, so I won't. The point stands that relative to other micros, Sinclairs were _really_ cheap. The BBC model B launched at £335 but was sold at £399. The 'cheap' Acorn Electron launched in 1983 at £199, by which time you could get a ZX81 for under £40 or a 16k spectrum for £99.

<comment><USER11> And they sucked.

Which is why we did all our playing at school on the BBC's :)

</comment></comment></comment></comment></comment><comment><USER18> Offtopic: I just noticed that the bbs' videoplayers volume goes UP TO 11!

<comment><USER19> It's... one louder, innit?

</comment></comment><comment><USER20> No.

The first generation of kids that never knew a time without Internet access, much less computer access, has recently cleared university, and they don't know programming. Thinking they'd have learned to program had they had a £15 computer (rather than the £500-£1000 one they/their family did have) doesn't seem likely.

<comment><USER21> Those are first-world kids, with rich parents.

A $15 computer is obviously not targeted at that market.

<comment><USER22> A very reasonable statement. This is not, however, the argument made in the video. They are explicitly talking about the UK's future.</comment></comment></comment>


Japan Heads Toward $1M Salaries in Battle for Tech Talent - <AUTHOR> https://sfgate.com/business/article/Low-Wage-Japan-Sees-100-Million-Yen-Jobs-Amid-12801068.php <comment><USER2> The interesting question is what proportion of all programmer salaries are going to the highly compensated. It might be the case that most salaries are decreasing even though a small number of people are getting these multi- million dollar paychecks.</comment>


Silvaco will appeal 'tainted software' case to state Supreme Court, CEO says - <AUTHOR> http://www.law.com/jsp/article.jsp?id=1202458169745

<comment><AUTHOR> For background, Silvaco Data systems makes chip-testing software. A competitor, Circuit Semantics Inc., misappropriated, modified, and resold Silvaco's source code, and were successfully sued for this. Intel and some other manufacturers who had bought and used CSI's software (but did not have access to the source code) were asked to stop using it by Silvaco following that judgment, but refused. Silvaco sued, lost, appealed, and were denied.

Referring to an 8,000 page appendix of legal reference material entered by Silvaco's attorneys, which duplicated the court's own record and included 27 copies of a 103 page index to its own contents, Judge Rushing grumbled that 'Seldom have so many trees died for so little.'

Background: [http://www.law.com/jsp/article.jsp?id=1202457477366&Inte...](http://www.law.com/jsp/article.jsp?id=1202457477366&Intel_Off_Hook_for_Buying_Tainted_Software) Appeal Court ruling: [http://scholar.google.com/scholar_case?case=1115553154677364...](http://scholar.google.com/scholar_case?case=11155531546773644177&hl=en&as_sdt=2&as_vis=1&oi=scholarr)

<comment><USER2> My reading of the law.com items and reading/skimming of the judgment suggests that Silvaco Data needs to get better lawyers and probably needs to listen better in general.

<comment><USER3> Who the hell would want to live in a world where supplier error or even malice would screw innocent third parties downstream in the supply chain? That would be hideous in today's IP soaked technical landscape.

<comment><USER2> Perhaps a company that can't retain its technical staff?

Hmmm, perhaps that thought goes further, maybe their lawyers are lousy because they can't retain good ones who will push their novel (and as you point out insane) legal theory?

<comment><USER3> Yeah, we need a neologism for companies pursuing crackpot legal theories, betting their entire company on the outcome. This feels like a SCO trial part II.

<comment><USER2> The bulk of _SCO Group v. The World_ (them vs. IBM and Novell) wasn't as I recall based on crackpot legal theories, their problem was that the facts weren't on their side. I.e. they didn't own UNIX(TM) and IBM didn't do anything illicit with UNIX(TM) anyway.

That's in part why it took/is taking longer, there have to be findings of fact which a judge can't do (Novell's summary judgment win on ownership was reversed, so they had to put it before a jury, where they won).</comment></comment></comment></comment></comment></comment>


Your A/B Testing Isn't Working Nearly as Well as You Think - <AUTHOR> http://www.wired.com/opinion/2013/11/what-to-do-when-ab-testing-doesnt-allow-us-to-c-enough/ <comment><USER2> So A/B testing does not work because people using it don't understand the underlying statistics and don't have a large enough sample size. So the solution is an even more complex test with even more variable? Makes sense to me.</comment>


Lua 5.2 Released - <AUTHOR> http://www.lua.org/work/doc/#changes

<comment><USER2> No, it's not. It's _BETA_ release.

<comment><AUTHOR> My apologies. I didn't realize that it was a beta release - I found the link with the embedded anchor tag, so I missed the massive header up top.

And by the time I saw this comment, I couldn't edit the title. Apologies to everyone who was misled.

</comment></comment><comment><USER3> They drop all existing libraries, frameworks and modules into the trashcan, by dropping module and package.seeall from Lua 5.2.

I don't think that this is a good decision, especially as several of them have no maintainer, no documentation, and forks on different websites.

One could also see this as a chance, to throw away all those badly documented libs that are without regression test, and restart a clean repository of modern Lua 5.2. But I don't think so, when looking at current Lua code.

<comment><USER4> Lua's draw is not in its libraries (beyond a core set of very awesome GEMS). The stuff that is important is actively developed and will be ported forward if there is indeed an issue. Rarely can you go trolling for a library with a long line down rigger and find a good fish. Many libraries are out of date, the rocks system needs improvement. The addition of the bitops into core is very much welcomed.

These changes look really good. I would love to see someone make a CoffeeScript to Lua compiler.

My main area of concern is when the wonderful Mike Pall will port LuaJit to 5.2 when it is released.

Maybe in Lua 6 they can default to local vars and add list comprehensions.

Lua ranks up there with SQLite in awesomeness.

<comment><USER5> I would also like to see a CoffeeScript compiler (it has a pretty good Haml compiler already), but more than that I'd like to see an LR parser generator so we can write those compilers more easily.

I have half of one now, it will take an already-built parser table and run it against input to make a tree, but I haven't had the time to finish it and make the actual generator.</comment></comment></comment>


Deep neural network written from scratch in Julia - <AUTHOR> https://github.com/jostmey/DeepNeuralClassifier <comment><USER2> All of these machine learning news is making me regret not taking math seriously in my undergraduate studies. I am beginning to get bored doing web development.

Time to peruse Khan Academy and befriend Math.

<comment><USER3> Here's a crash course on high school math for coders: [http://minireference.com/static/tutorials/sympy_tutorial.pdf](http://minireference.com/static/tutorials/sympy_tutorial.pdf)

<comment><USER2> Cool! I did not know such a library exists.

</comment></comment></comment><comment><USER4> The Readme actually clarified a lot of things for me that many longer texts skip over - why ReLU's are used (they prevent vanishing (or exploding) gradients), exactly how dropout works, why there is "momentum", etc.

I'm still not sure why he uses softplus instead of ReLU though. The implication is that it is better to have a smooth function, but is it? And does the benefit outweight the extra computational burden?

Also, the code is fantastically short.

<comment><AUTHOR> One could separate the training data into a validation and training set. Then you could try both the ReLU and softplus to see which performs better. I have no idea which type would---I just liked the idea of using a smooth activation function instead of a jagged one.

</comment></comment><comment> Ono-Sendai Why don't these library authors ever attach performance information? How many training runs per second etc..? How many weights processed per second?

<comment><USER5> From the README, under the performance section:

> This package is not written for speed. It is meant to serve as a working > example of an artificial neural network. As such, there is no GPU > acceleration. Training using only the CPU can take days or even weeks. The > training time can be shortened by reducing the number of updates, but this > could lead to poorer performance on the test data. Consider using an exising > machine learning package when searching for a deployable solution.

It seems the main aim of this software is educational, not production use.

<comment> Ono-Sendai Just because it doesn't run on the GPU doesn't mean it can't be fast. At least they acknowledge it's slow.

<comment><AUTHOR> Actually, I added that disclaimer on performance because of your first comment. I realized people were getting the wrong idea about my little example, and were thinking this could be used in place of packages like Caffe, Torch7, Theano, TensorFlow, ect...

</comment></comment></comment></comment><comment><USER6> I really hope someone writes a few good machine learning tutorials in Javascript (preferably ES2015). Many people use it for everything else other than machine learning stuff. Wouldn't hurt to not having to shift to another lang when dealing with ML.

</comment><comment><USER7> With so many deep/machine learning frameworks around, which framework would you put your money on? I use Theano but it makes life difficult when it comes to debugging

<comment><USER8> Why choose? Write Keras and switch to whichever takes your fancy at the time.

<comment><USER7> Doesn't Keras work with TensorFlow and Theano only?

<comment><USER8> Yup but those are the only libraries for Python that'll use the GPU. The rest are mostly CPU-only (PyBrain, quite slow as a result), built on Theano (Lasagne, pydnn), very specific to a particular problem (Caffe) or written in a non-compatible language (Torch).

Given that it supports 2/3 of the big general purpose libraries, it's good enough.

</comment></comment></comment></comment><comment><USER9> Can this take advantage of CUDA ?

<comment><USER10> Short answer: No.

Long answer: Looking at the code, this is written in pure Julia and nothing in place for running on a GPU. You could (re)write it but I'm guessing that's not what you meant when you asked.

Look at Mocha.jl if you want a Neural Network implementation in Julia that can run on a GPU: [http://devblogs.nvidia.com/parallelforall/mocha-jl-deep- lear...](http://devblogs.nvidia.com/parallelforall/mocha-jl-deep-learning- julia/)

<comment><USER11> Short answer is actually: maybe!

The bulk of the work done in this code (in terms of FLOPS and, likely, wall- clock time) is going to be in BLAS-3 operations in the feed-forward and back- prop steps. That is, almost all of the work is done using Matrix-Matrix multiplies and in-place arithmetic/transcendental functions.

CUBLAS[1] will allow you to run these types of operations on your GPU at highly accelerated rates, without much more effort than replacing your BLAS library with a new binary. Additionally, if you want finer granularity control over what gets done on the GPU, there are other libraries[2] which provides a direct interface to CUBLAS.

[1] [https://developer.nvidia.com/cublas](https://developer.nvidia.com/cublas) [2] [https://github.com/JuliaGPU/CUBLAS.jl](https://github.com/JuliaGPU/CUBLAS.jl)</comment></comment></comment>


Blazor, a New .NET Single Page Application Framework - <AUTHOR> https://www.youtube.com/watch?v=GI_9g9lZpik <comment><AUTHOR> I'm particularly interested in Razor [1].

And I suspect there will be situations in which you want a mix of client-side and server-side. I wonder if they're working on that, too.

[1] [https://www.youtube.com/watch?v=GI_9g9lZpik&t=30m49s](https://www.youtube.com/watch?v=GI_9g9lZpik&t=30m49s)</comment>


Buttsss: A Case Study - <AUTHOR> https://modus.medium.com/buttsss-case-study-a8d35f604c1b <comment><USER3> While I believe this is a clbuttic in the making, I have to wonder about the professional appropriateness of such a thing, especially in $CURRENT_YEAR.

<comment><USER4> Exactly. These butts are highly problematic. They promote an unhealthy and unattainable butt image. We need more butt diversity, more real butts - <USER2> butts, old butts, slagging butts.

<comment><USER3> How it will play out in reality is, a female presenter who presents a slide with a butt in it will be considered to be indulging in "lol so random XD" humor and given a pass, but if a male presenter used a similar slide it would be a CoC violation, the punishment for which is a summary ban from all open source conferences forever.

</comment></comment></comment><comment><USER5> I'd love to see a correlation graph showing the time this was posted to HN, and the server load on the Slack-emoji image-importing service. Pretty sure these are going to become hotkeys in a lot of workplaces.

<comment><USER6> I sure hope not. I can't think of anything more inappropriate.

</comment></comment><comment><USER7> Wish this had existed at the beginning of my career.

<comment><USER8> It's a shame it has come at the tail of your career, instead. :(

<comment><USER9> pun intended?

<comment><USER8> My puns are almost always intended.

I would go so far as to say that punning is my superpower.

</comment></comment></comment></comment><comment><USER10> Does anyone know what app the kanban board screenshot is about 25% of the way down the page?

<comment><USER11> That's using Notion! [https://www.notion.so/](https://www.notion.so/) It's a notes app with which you can do a lot of cool stuff!

I know, cuz I'm the author. lol

</comment></comment><comment><USER12> My new goto for animated buttsss.

</comment><comment><USER13> OMG this is excellent.

</comment><comment><USER14> How did this trash make it to the front page of HN?</comment>


10 Theses About Cancel Culture - <AUTHOR> https://www.nytimes.com/2020/07/14/opinion/cancel-culture-.html <comment><USER2> > So liberals or centrists who fear the left-wing zeal for cancellation need a > counterargument that doesn't rest on right-to-be-wrong principles alone.

The only solution to cancel-culture is to fight entitlement and promote scientific thinking. The main danger of current decade cancel-mobs lies in how they vew all "problematic" thoughts as a pure evil that taints all reasoning derived from it or that lead to it.</comment>


John Dvorak: Apple Should Pull the Plug on the iPhone (2007) - <AUTHOR> http://daringfireball.net/linked/2011/08/11/dvorak

<comment><USER2> What so many folks never get is that the joy of John C. Dvorak is that he's a curmudgeon -- and in a world full of tech bloggers who fall under the spell the newest shinny object that's always a bit refreshing. Sort of having slightly bitter coffee with your sugar filled pastry. He makes a perfect foil for sunny Leo Laporte (which is why he is always a great guest on TWiT).

<comment><USER3> > _is that he's a curmudgeon_

No, he's a troll: <http://scripting.com/2006/06/09.html>

edit: sorry arn, I was revising the post while you were writing yours. The scripting.com link above does have a link to the original .mov video, your Youtube link will likely have better compatibility with non-Mac users.

<comment><USER4> here it is on youtube <http://www.youtube.com/watch?v=gOHzHVF-4Mg>

</comment></comment></comment><comment><USER5> Ah, John Dvorak. I seriously think you'd be hard-pressed to find a man who is so wrong so much of the time and be so well-paid for it.

<comment><USER3> > _I seriously think you'd be hard-pressed to find a man who is so wrong so > much of the time and be so well-paid for it._

There's always Rob Enderle...

</comment></comment><comment><USER6> What people saw back then is that Jobs was selling a phone. When in reality Steve was selling a post-pc device that could also make phone calls. That's why the usual fashion cycle didn't apply.

<comment><USER7> The categories are still quite confusing, because Apple's products stubbornly fail to fit cleanly in any of the old ones.

Is the iPod Touch a phone? No. Is it more-or-less like an iPhone? More, rather than less. Is the iPad a PC? No. Does it replace a PC? Yes and no. Does it replace an iPhone? No and yes.

It's reminiscent of the elder days when "microcomputers" were new, and one could have an extensive debate over whether a microcomputer was a real computer or just a toy. In the long run, of course, the very word _microcomputer_ died out.

</comment></comment><comment><USER8> He's wrong, but eerily prophetic too -- all the reasons he says that the ipod was successful are the reasons that the iphone was successful (I do disagree with how important advertising was, though).

He just didn't realize, living in the moment, that all the existing smartphones were crap. Just as people pre-ipod did not realize that all the existing MP3 players were crap.

It's not until you see how much better something can be that the blinders can come off.

<comment><USER9> _He just didn't realize..._

Watch that Youtube video posted here by arn. He wrote it to get hits, not to represent his actual world view.

</comment></comment><comment><USER10> "The problem here is that while Apple can play the fashion game as well as any company, there is no evidence that it can play it fast enough."

John Dvorak was right about the trends, he was wrong about the company. Apple can play "the fashion game" better than any other consumer electronics firm. With the iPhone, they've played fast for a sustained period.

</comment><comment><USER11> It's pretty amazing that there's only one iPhone and iPad at a time. Sure, there's updated versions, but there's only one size and form that Apple promotes at any time. They don't do this with their desktops and laptops or even iPods. I can't think of any other leading device with such a "take it or leave it" mentality that a large share of people conform to.

</comment><comment><USER12> This just reminds me that, like Derek Sivers says so well, you can't predict the future.

</comment><comment><USER13> I wonder if there are any John Gruber posts predicting Android to be a complete failure...

</comment><comment><USER14> Hindsight is 20/20

<comment><USER15> In 9 years, we'll look back on today with 2020 hindsight.</comment></comment>


Ask HN: Recommendations for "24hr" work chairs? - <AUTHOR>

Hi HN,
I am in need of a new comfortable chair for when I work/is at my desk. I spend pretty much all my wake moments in front of my desk at home, working and coding in general.
I have problems with my back (it's straight, no curve) and I can really feel I should have invested in better office equipment (Chair especially).
So I thought I would ask you/HN, see what recommendations or even just hear what you are using as your go-to chair and maybe even table? Hopefully this may help others as well.
I currently have the "MARKUS" from Ikea, but I found it to be very uncomfortable for my neck sadly.
I hope you guys and gals can help with some recommendations for a new chair, I know nothing of chairs or which brands to even consider or stay away from.
Thanks in advance! <comment><USER2> This[0] was an enlightening article when it comes to selecting a chair for everyday use.

Whats more important is that you need to go to your general practitioner and get checked up on what is really bothering your back rather than making assumptions.

Secondly go to a experienced physiotherapist,(only if your general practitioner has said you should go to one)she/he will figure out what is wrong with your back.

Lastly, make health your number one priority, if your body is not 100% you won't be able to be as productive as you want to be. Simply perform exercise and eat nutritious food, it should help.

[0] [http://blog.codinghorror.com/investing-in-a-quality- programm...](http://blog.codinghorror.com/investing-in-a-quality-programming- chair/)

<comment><AUTHOR> Appreciate the info, will give the article a read. I guess you are right, better see my doctor, he did tell me once I should see a physiotherapist due to my back. Maybe now is a better time than ever.

Thanks!

<comment><USER3> That is an excellent article, but is now 6 years old. The market for ergonomic work chairs doesn't change quickly, but it isn't glacial either.

Take a look (and more importantly, try out) more recent offerings from Humanscale, Herman-Miller, Steelcase, and the like as well as the ones in the article.

</comment></comment></comment><comment><USER4> I can't help you with the chair other than to advise going out and sitting in a few until you find one you like, but I can suggest getting a silicon wrist rest [1]. I spend most of my time typing (only 8 to 10 hours) and I find they really help me avoid neck and shoulder pain.

[1] [http://www.amazon.co.uk/Fellowes-Crystals-Keyboard-Wrist- Sup...](http://www.amazon.co.uk/Fellowes-Crystals-Keyboard-Wrist- Support/dp/B00006B8IN)

<comment><AUTHOR> Thanks for the tip on the wrist rest.

I would love to try a lot of chairs, sadly there is limited places where I can (and they do not really have a lot to try).

It's just so I have some brands to maybe look into further before going out to try (if I can find them).

Thanks!

<comment><USER5> I understand this completely - I'm in Norway. Sometimes the choice isn't there.

I don't actaully have chair suggestions - I think the actual choice is personal. I have a preference for more of a lounge chair for my computer desk because a good one has back and neck support as well as the room to adjust and sit comfortably, even if that means I'm in lotus position on my chair. Not only that, but it seems more likely that you'll be able to test the chair first. I suppose that many people would miss the wheels, but if you can find one that swivels, the wheels don't seem to matter as much. You might be able to install casters (didn't see those in stock at Ikea, but the hardware store had plenty).

I do have suggestions that might help you until you find 'perfection'. Back in the states, I remember seeing lumbar support cushions. Something like this might just make your current chair bearable or at least buy time - and you can use that general shape to help guide your next chair. It is possible you can make one as well. You might try adjusting the height of your screen if your neck is hurting (even if this wasn't an issue before).

Good luck on your chair search.

<comment><AUTHOR> Yes, it's not exactly easy finding a big place with a lot of chairs to try out here, heh (Denmark), specially without a car.

Thanks for the tip, if I cannot find any chair reasonably quick I will try get a cushion to at least help me while I search.

Appreciated!

</comment></comment></comment></comment><comment><USER6> Heya,

I also have a niggling back but no problems since I went for standing desk: [http://www.fastcompany.com/3028686/my-year-at-a-standing- des...](http://www.fastcompany.com/3028686/my-year-at-a-standing-desk-and-why- ill-never-go-back)

Maybe give it a go in between sitting for long periods. Positive side effect: improved touch typing.

<comment><USER7> Good tip. I've been looking seriously as some standing desks. But is it exhausting to stand for a full day? And what do you do footwear wise? Is barefoot standing the way to go?

Thanks!

</comment></comment><comment><USER8> I've always bought cheap generic office chairs but recently picked up an Herman Miller Aeron. I am honestly surprised at how much of a difference it makes. I use the Aeron at home and have a generic $150 office chair at work and I am really hating it after getting the Aeron.

They are pretty expensive so you might check on Craigslist for a used version, that's what I did.

Also, you might try a standing desk. I've heard/read great things and will be getting one pretty soon.

</comment><comment><USER9> Have you tried standing? Perhaps alternating standing and sitting (in addition to an awesome chair) would help.

I switched to standing a few months ago, and it took me 6 weeks to build up strength so I can get through a day without pain. I do find I have more energy now toward the end of the day.

</comment><comment><USER10> I bought an exercise ball. It really did help strengthen my core. The "best" part was that, you know how people say you shouldn't be sitting down for too long? The exercise ball was so uncomfortable that I was forced to talk a walk every 45 minutes or so.

I don't know if people with back issues should take my advice though.

</comment><comment><USER11> I have an Ergohuman. YMMV, but when I tried a standing desk, I ended up with backpain around my kidney area/lower lumbar region, so I went back to sitting. So I finally put down some money for an Ergohuman and no complaints since then

<comment><AUTHOR> I had that happening as well, with the pain, so I switched between standing and sitting.

I'll give the chair a look, thanks for the suggestion!

</comment></comment><comment><USER12> I recently got a Steelcase Think and love it. My previous chair was a Herman miller Aeron and I find the Think to be better in just about every way. It was also half the price of an Aeron.</comment>


Microsoft: Users Spend 2 Billion Minutes a Day on Skype - <AUTHOR> http://www.eweek.com/cloud/microsoft-users-spend-2-billion-minutes-a-day-on-skype/

<comment><USER2> And now we can complain about Microsoft when something is broken. Hey Skype, what happened to all the landline phone numbers I used to have in my address book?</comment>


Go in a Microsoft Shop – Documize Dev Blog - <AUTHOR> http://dev.documize.com/go-in-a-microsoft-shop/ <comment><USER2> Well, at least not something weak/dynamic, so why not.</comment>


Pancake Lego Robot: Makes The Geekiest Pancakes - <AUTHOR> http://www.bitrebels.com/design/pancake-lego-robot-makes-the-geekiest-pancakes-ever/ <comment><USER2> Here's the maker's description of how it works: [http://makermig.blogspot.com/2011/06/how-pancake-bot- works.h...](http://makermig.blogspot.com/2011/06/how-pancake-bot-works.html)

Manually entering motor coordinates seems a little low-level to me. If I had that hardware, I'd love to make a visual pancake design UI for it.

<comment><USER3> Would you actually? I think most people would be surprised by how much money exists at the intersection of crafts+tech. I know a company that added a thin software layer to off the shelf hardware and built a $500MM business on that. If you want to know more shoot me an email.

</comment></comment><comment><USER3> Along the lines of pancake art, this site is amazing:

<http://www.jimspancakes.com/>

This guy hand makes them all, but it would be cool to see the technology in this post applied to a similarly creative endeavor.

</comment><comment><USER4> Vat of pancake batter + z axis actuator + laser on the gantry = 3D pancakes

</comment><comment><USER5> Lego Mindstorms is a fantastic platform for exploring robotics. This project seems to have to used Python, which ends up giving you an easy way to control your creations!

Technically, it is possible to hook Mindstorms with ROS (robot os). I tried but got stuck at some point. Anyone managed to get it working?

<comment><USER6> I wonder if there is a good way to hook it up with this: [http://www.ted.com/talks/tan_le_a_headset_that_reads_your_br...](http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html)

</comment></comment><comment><USER7> These guys handle the daily pancake rush for the Iowa Ragbrai. They easily handle thousands of pancakes every morning. <http://www.chriscakes.com/Video.htm>

I know it's not robotics, but the process is unbelievably efficient -- and fun.</comment>


Why you should never use hash functions for message authentication - <AUTHOR> http://blog.jcoglan.com/2012/06/09/why-you-should-never-use-hash-functions-for-message-authentication/ <comment><USER2> This is a great essay on why you should never use a hash function for message authentication.

Except not for the reason the author thinks.

There are several problems here.

First, with SHA-1 for example, you have 64 bytes per chunk. That means you basically get a free ride on this problem for anything < 64 bytes. A lot of "application state" fits pretty well in 64 bytes.

Secondly, unless a message ends right on the 64 byte boundary, it is not nearly that simple. You have a bit of a problem, because the hash is padded, and when you add extra characters to your original string, that padding gets _replaced_ with those values. So, it's no longer simple to just "keep going" from where you stopped.

Still, you can see how that leaves a distinct subset of cases where you'd be exposed. SHA-1, along with most secure hash functions, appends the length of the message the end of the source text before performing the hash function. That means that if you add even one byte to the string, you have now changed the last 8 bytes that were fed in to the "original" hash function. Oh, and your extra byte goes in _before_ those bytes, so not only did you change those 8 bytes, but you shifted them down a byte.

So, no, it isn't nearly that easy to crack a SHA-1 based authentication, and yet, it is easy enough that you should totally NOT use them for authentication and instead use HMAC ; they _are_ vulnerable to extension attacks, it's just not nearly as easy as this article suggests, and conclusions one might draw from this article (like you can solve this problem by feeding all source text in to the hash algorithm backwards) are likely ill founded.

It just turns out that cryptography is way more complicated, and even in terms of understanding weaknesses that arise from doing things wrong, you are going to get it wrong. Trust the experts, when they say it is a bad idea, but don't assume _why_ it is a bad idea can be explained in a short blog article like this.

 _UPDATED_ : Added an explanation as to why it might be dangerous to just take this article at its word.

<comment><USER3> "Never use a hash function for message authentication" is such a simplistic view. The author takes a common hash function design (Merkle-Damgard), and somehow extrapolates that hash functions should be simply ruled out for authentication.

First, this may send the wrong message to the less-focused reader: "what, I should use block ciphers instead?". Luckily, HMAC is eventually brought up, which is a fine solution.

HMAC requires 2 calls to H, our favorite hash function. Certain applications may find the overhead to be prohibitively high. With non-broken hash functions (e.g., any of the SHA-3 finalists), we can use the so-called envelope authenticator: A = H(K||M||K), with some padding to separate K from M to keep security proofs happy. This is significantly faster for short messages, and short is the most common size out there.

<comment><USER4> _First, this may send the wrong message to the less-focused reader: "what, I should use block ciphers instead?". Luckily, HMAC is eventually brought up, which is a fine solution._

If the reader can't be bothered to read the article to the end, I hardly think it reflects on the author. Whilst it might indeed be a more concise article if it just said "don't use a hash function for message authentication, use HMAC", it would still miss the important final point about timing attacks, not to mention the journey of explanation about _why_ you shouldn't just use a hash function.

<comment><USER3> You are correct, I shouldn't have tried to argue poor readership, that's just sloppy.

</comment></comment></comment></comment><comment><USER5> I e-mailed visa about something similar with their new upcoming V.me service. They suggest that you use md5 to generate the tag which is known to be weaker than SHA-1. I was a little surprised that a company like Visa would mess up on crypto and not know to use HMAC instead of just a simple hash. Never heard a response from them either.

Here's what their documentation says:

Language Standard Syntax for Generating MD5 Hash Java import org.apache.commons.codec.digest.*; hash = DigestUtils.md5Hex(string1+string2+string3...); PHP $hash = md5($string1.$string2.$string3...); Ruby require 'digest/md5' hash = Digest::MD5.hexdigest(string1+string2+string3...) Python import md5 hash = md5.new(string1+string2+string3...)

<comment><USER6> The link: <https://developer.v.me/docs/get_credentials>

</comment></comment><comment><USER7> Tl;dr: Use HMAC for Hash-based Message Authentication Codes and hash functions for hash functions. Don't use them the other way around.

PS, maybe more developers should take an intro course on crypto.

<comment><USER8> \+ don't compare secret strings in a manner that makes it possible to draw conclusions about the position of the inequality.

</comment></comment><comment><USER9> > Finally, you should make sure your application does not exit early if the > tag is invalid. You should do all the data processing you would normally do, > just short of modifying the database, and check the tag last. If you return > early you risk another timing attack.

What kind of timing attack is that? In order for there to be a timing attack, there has to be a difference in the timings.

1\. You can either process the data, check the authentication code, then commit.

2\. Or you can check the authentication code, process the data, then commit.

I don't see any attacks on #2 that couldn't also work on #1.

<comment><USER10> The timing attack is if you check the tag, that fails, and then you _don't_ do any further request processing. This shortens the request time. It depends quite a lot on what you're actually doing with the message, but in general you want to leak as little info as possible about what's happening during any crypto-related process.

<comment><USER11> But it only tells them that it failed, not that they got closer, like with the string-comparison based one. What does that gain an attacker if you already provide other feedback about the request being invalid? And not doing so would result in a bad user experience if you have users run into a bug somewhere and it fails silently so they don't know that nothing was actually done.

<comment><USER12> The leak that you're ostensibly timing is that in order to figure out how much of the candidate MAC string was valid, the target had to compare more byte, which takes more time, which adds observable lag to the error response.

<comment><USER13> Is the observable lag for a string comparison significant enough to be useful?

We're talking about such small amounts of time compared to the overhead of the full web stack.

<comment><USER14> The observable lag isn't usually significant enough if you only do it once but over many requests the stochastic factors can be compensated for.

</comment></comment></comment></comment></comment></comment><comment><USER15> Number one thing I learned from the Coursera class: don't build your own crypto.

<comment><USER16> I've heard this said many times before and I agree. However, using crypto libraries does not solve the problem of vulnerabilities through cryptography misuse. For example, keys must be stored correctly, algorithms often need initialising in the correct mode for your specific application, IVs must not be repeated, and, as shown in this article, hashes should be used in specific ways to work correctly.

There are many ways to fail with cryptography and avoiding them all takes considerable expertise. Using crypto libraries does not solve this problem.

<comment><USER12> This is the entire point of high-level crypto libraries, like Guttman's libcrypt and Google's Keyczar. So, yeah, don't use OpenSSL or javax::crypto or whatever .NET calls it; but, do consider using something like Keyczar, or, better yet, just use PGP/GPG to store data at rest, TLS for data in motion, and be done with it.

<comment><USER17> Those still require key management. There is no way a developer can abdicate all responsibility for this stuff, no matter how high level (at least, not until we have good, common, trusted security as a service).

<comment><USER12> Part of the point of Keyczar (note the name) is to make the right decisions about key management in advance and abstract them away from developers.

</comment></comment></comment></comment></comment><comment><USER18> The title is sort of linkbait, as in fact what it should be is "Never use hash functions vulnerable to extension attacks"... (And most common ones are) With that said, this stuff is pretty cool and after reading that the author learned all this in the Coursera Cryptography class I decided to sign up for it. (Starts June 11th)

<comment><USER19> You can learn all that and more just by reading Applied Cryptography.

<comment><USER12> People that build crypto after reading Applied Cryptography are doing a fine job paying for my kids college education, so I agree with you and encourage everyone to do likewise.

If you don't happen to like my kids, well, first, screw you, and secondly: buy _Practical Cryptography_ or _Cryptography Engineering_ (really the same book) and burn your copy of "Applied".

<comment><USER19> There's nothing wrong with Applied Cryptography so long as you _understand_ it. If you blindly apply outdated algorithms, yes, you lose. Everyone should read both Applied Cryptography _and_ the other books you mentioned, and keep up on the literature besides.

<comment><USER12> No, there's a lot wrong with _Applied Cryptography_, and those things have very little to do with the fact that AC writes about IDEA and not AES.

If you read _Practical Cryptography_, you don't need to read _Applied Cryptography_. AC is a book full of trivia, and of encyclopedia-style descriptions of random block ciphers with minimal attention given to the actual real-world attacks on implementations of those ciphers.

I strongly advise that you _not_ waste time reading AC. If you're lucky, you can read it and just lose time; if you're unlucky --- and a lot of my clients have been --- you can find yourself having learned stuff you'll later need to unlearn.

<comment><USER19> Paging through my copy of AC, I think you're right. I'd been a while since I read it. PC is indeed the better book.

<comment><USER12> Even Schneier has somewhat acknowledged how toxic AC turned out to be.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> >> This fact means that an attacker can determine the first correct character of the tag by submitting requests to a signed URL with a different first character in the tag each time, and stopping when the request takes a little longer than usual. After guessing the first character they can move onto the second, and so on until they've guessed the whole correct tag.

Wouldn't this attack be eliminated by using iptables rate limiting to reduce the attack window of opportunity?

<comment><USER12> Wouldn't this attack be better eliminated by fixing the timing leak that is potentially allowing people to guess valid MACs on packets?

The reality is that you probably _can_ dick around with things in your deployment and your app to make timing attacks prohibitively expensive/annoying; if you understand that you're not _eliminating_ the timing leak, but rather _masking_ it, you can take advantage of the additional measurements required to unmask the leak to give your MAC enough of a buffer to last for its whole useful lifetime.

But when you do this, you're really playing on the razor's edge of what we currently know about side channel attacks on crypto, and you're probably going to end up putting more effort into your workaround than you would in just fixing the underlying bug.

<comment><USER21> I guess the idea of just blacklisting the client's IP after the first 1,048,576 failed attempts is too boring, or has some other drawback.

<comment><USER12> The idea of trying to detect people employing timing attacks on your cryptography and block them individually by IP address is so obviously retarded that the comment I'm replying to is indistinguishable from trolling.

<comment><USER21> I'm not an IT guy, so no, I wasn't trolling. Why exactly is it "retarded" to build your system to reject (or at least flag) access patterns that are unlikely to be due to legitimate activity?

I'd recommend using the word "retarded" with a bit more circumspection. Obviously the incoming IP address doesn't uniquely identify a client who's likely to be on the other side of a NAT gateway. But the idea that a system should just sit there silently and carry on business as usual while any one address or class-C block generates large numbers of failed access attempts seems like a _good_ application of the word in question.

<comment><USER12> You're not an IT guy, but you are a programmer, and you know that leaving a vulnerability in your code, hoping the devops team catches attempts to exploit it, is a fucking retarded idea. I think you're just trolling.

<comment><USER21> Who said anything about leaving a vulnerability in the code? If your security model depends on a suboptimal implementation of strcmp(), you have bigger problems than timing attacks.

<comment><USER12> I have no idea what you mean by "suboptimal implementation of strcmp".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> For the string comparison, could you really use that in a timing attack. Wouldn't the difference between comparison taking one char longer be measured in nanoseconds, while the overall network lag would be milliseconds?

<comment><USER23> Yes, I don't see that being detectable for things like web-based APIs. For these string lengths (eg., HMAC with SHA-256), the network lag would add sufficient randomness that you would not be able to measure any difference in timings in the string comparison.

<comment><USER12> It turns out that it _is_ possible, over a WAN, on _some_ frameworks. The rule of thumb is, if the comparison is effectively being done by libc's memcmp(), the timing attack is very difficult to do even across a single switch; however, some platforms don't drop to memcmp and instead compare each byte explicitly. These are timeable.

If you're wondering, "how do I detect nanosecond differences over a network when my measurement will be swamped by other things happening on the target, the network, and my host", the answers boil down to:

* You're going to move your measurement code as close to the drivers as possible, and fix interrupt handling so that interrupts don't confound your measurements.

* You're going to get yourself on the same hosting provider as your target; for instance, a good chunk of all target apps can be attacked via Amazon EC2 for not very much money.

* You're going to take lots and lots and lots and _lots_ of measurements and then use high school statistics to process the results.

</comment></comment></comment><comment><USER24> > The easiest way to defeat this attack is, instead of directly comparing two > strings, compare their mappings under a collision-resistant hash function.

Is this really the best way to compare strings without giving away timing info?

<comment><USER12> No. It's A way to do it, but not the fastest or the simplest. An easier, faster way to do it is what Rails does (after Nate Lawson via Coda Hale told them how): accumulate the XORs of each offset of both strings and then verify that they add up to zero.

<comment><USER25> What's wrong with simply doing a traditional compare, but not exiting early when it's found the two strings don't match?

I see how the xor method works, but not why it's superior.

Also, it would seem that you'd be leaking information about the size of the other string with either method (whether you exit early or not when you run past the length of one of the strings) - not a problem when comparing hashes presumably, but is it never a concern?

I don't think you'd be leaking that information if you hashed both strings and compared the hash, because it wouldn't stop getting faster when the shorter string gets shorter.

<comment><USER26> Compiler optimizations, CPU pipeline and branch prediction would be my guess, although I'm sure someone else can jump in with more detail. XOR is basically immune to optimized tricks.

<comment><USER25> Ah, that does make sense. Thanks!

</comment></comment></comment></comment></comment><comment><USER27> Stupid question: Whenever I've used GPG to sign an email, it includes a line saying "Hash: SHA1". Does this imply PGP-signed messages are vulnerable to this, or does PGP/GPG do something different/smarter?

</comment><comment><USER28> One thing I'm slightly confused about here.

The article says:

 _"This sequence is then folded using a compression function h(). The details of the h() depend on the hashing function, but the only thing that concerns us here is that the compression function takes two message blocks and returns another block of the same size."_

So if the chunks in a SHA-1 hash are 512 bits each then surely the output of the hash function would be 512 bits rather than the 160 bit digest?

Edit: the IV is 160 bits , so "another block of the same size" means each derivative block is the size of the IV _not_ of the actual data.

</comment><comment><USER29> RFC 2104 specifies how you should do it, see e.g. [http://de.wikipedia.org/wiki/Keyed- Hash_Message_Authenticati...](http://de.wikipedia.org/wiki/Keyed- Hash_Message_Authentication_Code)

The Handbook of Applied Cryptography, Chapter 9 (free online: <http://cacr.uwaterloo.ca/hac/>) nicely explains the reasons.

</comment><comment><USER30> In order for an extension attack, wouldn't the blocks have to align perfectly? Like suppose I hash [abcd][efgh][k]

How would you extend that?

<comment><USER12> You guess the length of the last block (or iterate over possible lengths with trials of the attack). When you know it, you can easily predict the MD padding at the end of the hash to fill in the block. That fake padding (our code calls it "glue padding") actually ends up in the forged message; for instance, if you're signing URLs, you'll see it as gibberish in the middle of the URL. In practice, most code does not care about the gibberish "glue" bytes.

</comment></comment><comment><USER31> tptacek or others with domain knowledge-

Is the timing attack hardening suggested in the blog post a standard approach?

If I was trying to attack a system and knew loosely that they did what he suggested (hashing then comparing vs comparing with timing exposed) , my untrained instinct would be that this is the weakest part. In other words I think this just makes the timing attack a little more difficult, but still possible, by producing specific hashes that carry out the timing attack.

When I've needed to harden comparisons against timing attacks, I've always just used constant time comparison functions, such as these ->

<http://codahale.com/a-lesson-in-timing-attacks/> [http://rdist.root.org/2010/01/07/timing-independent-array- co...](http://rdist.root.org/2010/01/07/timing-independent-array-comparison/)

</comment><comment><USER19> Also, HMAC is just one MAC (message authentication code). OMAC and is another good one; it has the interesting property of being built on top of a block cipher instead of a hash function, which can reduce the number of "moving parts" in a system if you're using a block cipher of some sort anyway.

</comment><comment><USER32> I was wondering about that timing attack. Is that really possible? How many requests would you have to make until you can get reliable statistics over the timing of a string comparison, when you have network delays, other requests and all kinds of stuff that influence timing?

<comment><USER12> It's very difficult, but possible. It's a plausible enough threat, especially if you're cloud hosted now or ever might be, that you should take steps to avoid it.

Jitter and confounding are problems that can be addressed simply by repeated measurements.

The rule-of-thumb from Crosby & Wallach's paper on remote timing attacks is, assume tens-to-hundreds of nanoseconds precision if you can colocate the attacker at the same provider, and tens of microseconds if you have to do it over the Internet.

<comment><USER32> Thanks for your reply. I was totally oblivious to this type of timing attack before I read the article.

</comment></comment></comment><comment><USER33> what's wrong with hashing (message + secret) instead?

<comment><USER10> Relying on the way you happen to combine data, instead of using a function that's _designed_ for authentication and has baked-in a safe way to combine the inputs, is a bad idea. "What if $EDGE_CASE_OF_INAPPROPRIATE_CRYPTO_FUNCTION" is never a good question to ask. Just use the right tools in the first place.

<comment><USER33> > _"What if $EDGE_CASE_OF_INAPPROPRIATE_CRYPTO_FUNCTION" is never a good > question to ask. Just use the right tools in the first place._

that's not an intelligent attitude.

understanding where an edge case breaks down is still illuminating, regardless of whether i use hmac in the end.

</comment></comment></comment><comment><USER34> This seems to me like a variant of "do not trust the client." Good info though. I have learned a lot more about how hash algorythms work. I do wonder though if fixed-param hashes are relatively safe due to the inability to add suffixes.

<comment><USER12> "Never trust the client" is, like "always validate input", one of those timeless bits of security strategy that is worth pretty much nothing in the real world. It's about as useful as "pretty much you should always make sure you're secure, pretty much."

<comment><USER34> I disagree with you here. One should always be sure input is validated somewhere before anything important is done with it. And not trusting the client is one element of what I call a "push security back" strategy (that strategy is, basically, don't do any security enforcement in your application you can't make a component further back do just as well. The reasoning here is that components like operating systems and web apps will always have more review and more eyes than your web app, so if they can work without trusting your app then all the better. Work from least privilege and design so that components further back can do things like authentication, authorization, and the like, to the extent this is practical. This creates a narrower security perimeter, and greater depth in defence. Of course, as in all things, security is a matter of perpetual tradeoffs.

</comment></comment></comment><comment> X-Istence If I remember correctly this was the same issue that Flickr had with their API calls at one point in time!</comment>


Show HN: Yarnlink – connect with world class mentors - <AUTHOR> Connecting driven people with mentors possessing a track record of success. Focusing on specialized medical residencies at the moment but mentors in other industries welcome!<p>yarnlink.com <comment><USER2> Awesome, thanks for sharing.</comment>


Which music are you listening when you coding? - <AUTHOR> https://www.youparty.in/playlist/5b4f9242-b44a-11e7-acac-42010a8a0002 <comment><USER2> I never, ever listen to music when I code. It reduces my efficiency drastically. Music is precious to me and I like to give it my full attention.

I can't listen to music while talking to people either, which rules out most bars and clubs.

<comment><AUTHOR> I prefer some piano when I am coding, as I don't like it's too quite :)</comment></comment>


New Math Proof Could Help Us Describe the Earth's Interior - <AUTHOR> http://www.pbs.org/wgbh/nova/next/physics/math-proof-could-help-us-describe-the-earths-interior-like-never-before/ <comment><USER2> Not to insult this important work, but the headline makes this sound a lot more important than it is, although "math proof" should have clued me in otherwise.

I was expecting something that'd actually explain why our planet's core is still hot, without using the thermonuclear crutch, given how it is nearly solid iron (not liquid) at such temperatures; such as properly integrating plasma physics (ie, Birkeland currents) into the math.

<comment><USER3> It's synonymous with the Nature headline: "Long-awaited mathematics proof could help scan Earth's innards"

[http://www.nature.com/news/long-awaited-mathematics-proof- co...](http://www.nature.com/news/long-awaited-mathematics-proof-could-help- scan-earth-s-innards-1.21439)

I fail to see how either headline is not an accurate representation of the result.

<comment><USER4> The problem is that it's unclear the maths result lines up exactly with reality -- as I understand it, this is that a "perfect scan" lines up exactly with one model of reality. What we want is that some kind of "nearly accurate scan" produces a "nearly accurate reality". From my (limited) reading, the proof doesn't seem to demonstrate that (maybe I scanned it too quickly)

<comment><USER3> I agree that's a limitation of the proof, but this is a thread about journalism tone. What alternative headline would you or the OP prefer? How much weaker does it need to be? Is "could theoretically help" weak enough, or do we need to go all the way to "could hypothetically, maybe, possibly help"?

Forgive me, but it's frustrating to see Monday morning quarterbacking on a huge, important result that was the culmination of decades of work by the authors. Prior to this, the most general result in boundary rigidity was [https://arxiv.org/abs/1205.6425](https://arxiv.org/abs/1205.6425), which only works on simple metrics.

</comment></comment></comment></comment><comment><USER5> I am pretty sure that the work depends on the speed of sound being tied to just density. But it isn't. Sound travels faster in some directions than others.

[https://www.sciencedaily.com/releases/2017/02/170213124312.h...](https://www.sciencedaily.com/releases/2017/02/170213124312.htm)

</comment><comment><USER6> Does this provide a new constructive way of mapping a space (which would be exciting) or just a proff to a known conjecture which is already being used to map spaces? (also cool but not as much)

<comment><USER7> I work in related areas of math but don't know anything about the applied side of this stuff. The general rule of thumb though is that whatever algorithm the mathematicians are proving correct is chosen so that it is easy to analyze and isn't going to have the best convergence properties for actual use. After this result, though, expect others to tackle questions like faster converging algorithms, stability, etc. There are exceptions though: Newton's method was both ridiculously fast and easy to work with mathematically and is still used in both applied and pure contexts today.</comment></comment>