For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | innes's commentsregister

"I didn’t know Steve. I never met him. I never worked for him. I never even got one of his famous one-liner email responses."

204 upvotes on HN.


Doesn't work on any of the three browsers on my laptop - presumably it works on Apple's browser. Kudos to Apple on going the extra mile there.


If you look at the code it only has webkit bindings. It fails gracefully however in trident/presto/gecko, so no real issues in my opinion.


> The point isn't that the keyboard is bad, the point is that the keyboard is excruciatingly bad.

You're talking about a device with a D-pad, and no touch screen. That's how keyboards work on such devices. It being bad isn't unexpected or noteworthy.


EDIT: got confused between "Kindle" and "Kindle Touch". To me it is obvious that "Kindle" has no touch screen and that keyboard input must be via the D-pad. Consequently I assumed the complaint re:keyboard not being touch would apply to a product that actually had a touchscreen.

In short: I agree with my parent comment. neither unexpected or noteworthy.


Changes in these traits ... were larger in magnitude than changes typically observed in healthy adults over decades of life experiences, the scientists say.

Clearly most people don't read good books, or scientists would have seen evidence of their radical personality-changing effect.


I'm not sure if you're being sarcastic, but I would say it is certainly true that most people don't read good books. Most people don't read books, in general. Of those who do, most read for entertainment (like me), rather than seeking out great books to have read.


No sarcasm. I have read good books (I think), but am pretty sure that they didn't modify my personality. Normally they result in a couple of days of thinking "wow, that was a good book".


I think that a "good book" in the sense used above is a book where you spend the next coupla days thinking about the new ideas from the book, or the new vantage on a subject you thought you understood, or examining your life in light of what you just read.


I tried this podcast once - found it embarassingly pretentious, with terrible musical interludes set too high in the mix. Conery's speaking style really rubbed me up the wrong way. But I'll maybe give it another go. Maybe he's got it under control since then.


Totally agree, it was painful for me.


If the alternative is "rubbing you the right way"... I'll pass :). If you had the time to be a bit more concrete with your thoughts - it would probably help. I'm not an audio engineer, I'm a developer like you.


Don't worry, I'm not going to get all Christina Aguilera on your ass. Anyway, I do admire your ambition at attempting something a little different from the 'guys chatting' norm.


Agreed, though it might have improved; it just seemed as if they were trying too hard to explicitly imitate Ira's speaking style.


seemed as if they were trying too hard to explicitly imitate Ira's speaking style.

This is exactly what it sounds like. I don't understand the appeal of this, sounds like a ton of work just to sound like someone else.


Well, I don't know, I'm a Trent Reznor fan so I like the music.


2. API ties windows to threads

What UI APIs are there that don't have a concept of UI thread(s)? Coming from Windows, I'm used to UI work needing to be done on a UI thread.

I randomly googled these comments:

"Never, ever, touch the UI from outside your UI thread, in any version of Qt."

"Android UI toolkit is not thread-safe and must always be manipulated on the UI thread."

google "iOS 'non-UI thread'": 60 million results.

javascript: everything UI-related runs on one thread.

Do you do much UI coding?


This is about an OS-layer API, not a windowing toolkit API. Tying the window to a thread at this layer makes it impossible to have a single-threaded UI application. It is inflexible.


"This is about an OS-layer API, not a windowing toolkit API"

What does that even mean? Of course you can have single-threaded UI applications in Windows, the majority of them are. Have you ever written a Windows application in C or C++?


What exactly is the problem with the approach?


Sorry. I've read your comment a couple of times and am unable to make any sense of it. Win32 is a (dated, clunky) API for writing GUIs (in part). "OS-layer" is babble in this context.

And yeah, i would stop signing your posts - it comes across as conceited somehow; like each comment is a big deal.


Well, I guess my digi-wallet asking me if I want to order groceries is slightly less weird than my internet-fridge going ahead and doing it without asking.

Still, I'm not convinced that it makes sense for my 'wallet' to be doing this.


And let me explain how Barcode Scanner (or something like it) combined with Google Wallet will make my life as a consumer more productive

Yep, this will really speed things up.

Instead of scanning items on the way out, (i.e. "beep...beep...beep...beep...beep") people will scan as they shop "okay... just line up the cameraaaa... hmm it's not seeing it, turn the phone a bit... oh i beg your pardon hang on [moves out of the way of another shopper who also wants a can of baked beans]... [phone grabs barcode]... ah finally... beep." - one can of baked beans purchased.

Can't wait!

Also, given how fragile self-scanning checkouts are - presumably calibrated to prevent shoplifting - how will scanning stuff yourself and then walking out with it be acceptable to supermarkets?


Have you tried the app in question? Even with the low quality cameras on the first Androids, it worked really well. On my 8MP camera now, it's insanely fast. And since everyone would be doing it as they picked things up, the lines to check out will be limited to making sure people didn't steal.

Having said all that, I think elimination of the traditional supermarket is more in line with what I want in the future. There was a startup on here that talked about having no customer-accessible store. The customer orders from home, drives up in their car, the store loads the order in the car and collects the money, and the customer drives home. Eliminating the customer's driving is a logistical nightmare, but I expect that will eventually be solved, too.


Have you tried the app No I haven't - I've just used the 'standard' Android barcode scanner. So now I feel a bit sheepish given that I may have over-egged the pudding with that little scenario!

I've used internet supermarket shopping in the past, when I didn't own a car. It was reasonably good, and you paid £5 for delivery within a 2 hour window. You would tend to sometimes accidentally buy a weird size of some item though.


I suppose they could use the scales that are integrated into current self-checkout stations to compare the aggregate weight of your purchase against what it should be.

Seems like a lot of hassle.


Origo can talk and write blog posts. Lose that functionality and the price should drop considerably.


I remember Google having reported various problems with their app store in the past, so the accusation is not valid, at least with respect to what we're discussing here.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You