HNHacker News
TopNewBestAskShowJobs

ricmo

9 karma · joined February 2, 2010

submissionscomments
ricmo··on You Can Stop Worrying About A Radiation Disaster In Japan - Here's Why
This is an article based on a comment(!) to a NYT article. The comment itself is just a repost of the original (and now discredited) Oehmen "why I'm not worried" blog post. So this BI "article" is a repost of a repost.

So much for investigative journalism.

ricmo··on Amazon CloudFront - Production Status and an SLA
Typo? : "If the availability drops below 25% you can apply for a service credit equal to 25% of your monthly bill."

- if availability dropped below 25%, I'd be looking for more than 25% back...

ricmo··on Miguel De Icaza: CLI on the Web.
Complex VM? New UI metaphors? ...W3C? Sure, that spec oughta be ready in 20 years or so....

It's a vendor job, not a committee spec. They can take the arrows in the back, keep what works, toss what doesn't. I personally think that modern JS+JIT implementations are nearly fast enough: it's become the DOM and its legacy behavior that's becoming the problem now.

ricmo··on Miguel De Icaza: CLI on the Web.
We're talking (or at least I thought we were) about replacing the scripting language in a browser, which visually renders the structure and styling of a DOM. That's how browsers work.

Replacing the scripting language of a browser does not magically make the applications you describe possible, any more than it's possible to draw high quality vector graphics on a 5250 green screen. You're presuming all sorts of hardware-accelerated graphics, network connectivity, font manipulation and many other fundamental sorts of hardware manipulation that just isn't possible within the confines of (most of today's) web browser.

What you describe is indeed possible, e.g. Silverlight and Air, but putting a new scripting VM in today's browsers is not going to get you there. You're not talking about web applications, you're talking about a new class of web browser.

ricmo··on Miguel De Icaza: CLI on the Web.
OK, how exactly? Web apps now, and presumably in the future, are essentially engines focused on manipulating a DOM structure, which is then rendered (with any luck, correctly) by the browser, right? So unless you're talking about effectively ignoring the DOM and rendering applications solely via use of Canvas or SVG, what is the magic sauce that flavors this <i>new</i> class of web apps?
ricmo··on Miguel De Icaza: CLI on the Web.
The pain of developing web applications is largely dealing with cross-browser DOM and CSS issues. Swapping in a different scripting language may give you faster code execution, classic class-based inheritance and a packaging system, but as far as I can see it does nothing to help with layout issues, widget creation and other UI issues.
ricmo··on Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
I'm not sure I get the point of this. Two of SQLites strong points (among many others) are: (a) Short dependency list (b) Platform independent filesystem storage

..doesn't this negate both of those for what seems like little gain?

ricmo··on Ask HN: please review my app - html to pdf API
have you seen this? http://code.google.com/p/wkhtmltopdf/