skysight-inc/HackerNews huggingface dataset:
efficient vector-based animation

SVG in HTML (embedded directly in the DOM, not an <img>) is all but certain to happen; the SVG and HTML working groups just have to agree on the details. Of course SVG in an <img> island is possible already, which is what already more integrated with the browser than Flash.

support for audio mixing

HTML5 has <audio>, and the rest will come in time, with enhancements to what's there now.

tool support

Actually, there are already more Web developers than Flash developers, so I'm not sure this argument holds much weight... but you can be sure there are people working on this very issue for the Web platform.

If these and similar issues all that Flash has going for it against the Open Web, then Flash is on the way out. In a decade, I expect Flash will be as relevant to the Web as Java applets are today.
Here is a Chinese blog, hijacking the top 4 email provider SSL on a local machine

http://wuhongsheng.com/it/2009/09/ssl-hijack/
Current Crop of E-Readers Compared: iPad vs. the Rest
Italy Plans to Extend TV Rules to Web Videos
No, all it means I'd prefer Chinese people to do what they're good at, and Americans do what they're good at. If we can't manufacture cost-effectively in this country, then it's fine for it to happen somewhere else. I don't view manufacturing plants as a birthright.
Mary Oliver on the First Requirement for Writing Poetry
I included this in an article I recently submitted here, but think it stands on its own as something relevant to creative people:

If Romeo and Juliet had made appointments to meet, in the moonlight-swept orchard, in all the peril and sweetness of conspiracy, and then more often than not failed to meet — one of the other lagging, or afraid, or busy elsewhere — there would have been no romance, no passion, none of the drama for which we remember and celebrate them. Writing a poem is not so different — it is a kind of possible love affair between something like the heart (that courageous but also shy factory of emotion) and the learned skills of the conscious mind. They make appointments with each other, and keep them, and something begins to happen. Or, they make appointments with each other but are casual and often fail to keep them: count on it, nothing happens.

The part of the psyche that works in concert with consciousness and supplies a necessary part of the poem — a heart of a star as opposed to the shape of a star, let us say — exists in a mysterious, unmapped zone: no unconscious, not conscious, but cautious. It learns quickly what sort of courtship it is going to be. Say you promise to be at your desk in the evenings, from seven to nine. It waits, it watches. If you are reliably there, it begins to show itself — soon it begins to arrive when you do. But if you are only there sometimes and are frequently late or inattentive, it will appear fleetingly, or it will not appear at all.

Why should it? It can wait. It can stay silent a lifetime. Who know anyway what it is, that wild, silky part of ourselves without which no poem can live? But we do know this: if it is going to enter into a passionate relationship and speak what is in its own portion of your mind, the other responsible and purposeful part of you had better be a Romeo. It doesn’t matter if risk is somewhere close by — risk is always hovering somewhere. But it won’t involve itself with anything less than a perfect seriousness.

Various ambitions -- to complete the poem, to see it in print, to enjoy the gratification of someone's comment about it -- serve in some measure as incentives to the writer's work. Though each of these is reasonable, each is a threat to that other ambition of the poet, which is to write as well as Keats, or Yeats, or Williams -- or whoever it was who scribbled onto a page a few lines whose force the reader once felt and has never forgotten. Every poet's ambition should be to write as well. Anything else is only a flirtation.

And, never before have there been so many opportunities to be a publicly and quickly, thus achieving earlier goals. Magazines are everywhere, and there are literally hundreds of poetry workshops. There is, as never before, company for those who like to talk about and write poems.

None of this is bad. But very little of it can do more than start you on your way to the real, unimaginably difficult goal of writing memorably. That work is done slowly and in solitude, and it is as improbable as carrying water in a sieve.
I think he is assuming way too many things to be constant, and then using that to justify his thesis of addressing efficiency concerns only just-in-time.

The biggest concern I have is that he account nowhere for growth of that new feature, and the increasing hosting costs as a result of that growth. Part of efficiency is how fast is it now; the other half of efficiency is how will the performance change based upon an increased load.

Part of the risk of putting out a new feature is you don't entirely know what the uptake will be. It could fall flat, it could grow exponentially within the first week. Or, as this author assumes, it could enjoy a rapid uptake of a certain amount, and then level off just as quickly. I'd argue this last possibility is almost never the observed pattern.

The other part of the risk is that, if you go the inefficient route, you may not have the time later on to even build bad hacks within the inefficient code to make it speedier. This is a bad situation to be in, you end up getting screwed by your own unexpected success, and users get pissed because now your site is unreliable.

Yes, spending insane amounts of time on efficiencies probably aren't worth it. Yes, you need to do cost-benefit analysis to decide what amount of time is. My point is that there is a lot more to consider than the author gives credit for, and I don't think you are as likely as he believes to reach the same conclusion he did. Cash flow is important, but it is also important to remember that things don't remain flat or grow linearly just because you assert that they do.
Thanks for entertaining it. Your answer is already pretty informative.
I launched Dragon Naturally Speaking and said, "I ham dict eating too the come pewter write now", which it transcribed as "I am dictating to the computer right now."
"Comments really are a hard problem."

Bit tangential, but has anyone (e.g., start-up) solved the problem of massive discussions? Anything over a hundred or two hundred comments becomes unmanageable in a hurry. Some of the larger sites (e.g., Huff Post) routinely have 2000-comment threads that would take days to plow through.

Is there a solution that combines karma, upvotes as a means of identifying the 'cream' as well as grouping of sub-discussions and points-counterpoints? I haven't seen any solution take a serious shot at a way of grouping sub-arguments and discussions.

The level of comments on the typical news article here in Australia is embarrassingly bad. Any discussion quickly becomes a confusing read without threading and a complete waste of time without persistent identities or moderation. Disqus has taken a crack at the basics, but is it much better for discussions over, say, 500 posts?
Mozilla is so idealistic about the H.264 video codec but couldn't care less about something like this that actually has serious consequences for end-users.
"So I get that it's never necessary, but I find it sometimes limiting as an author who cares strongly about how his code is organized."

Nothing other than an if statement, a goto, and some basic arithmetic is needed in a programming language. It's all syntactic sugar. I agree that such a construct would be useful. However, it's more about if it's worth complicating the language over. I don't necessarily know how complex that would make things, but I can definitely see that a case can be made that it would be more trouble than it's worth considering the way indentation is handled.
Do you think it would be preferable if the application broke (or broke another application) unexpectedly at a later date due to an otherwise innocuous system software update?
I'm not making that claim, and freely admit that I am utterly ignorant about mercurial. I'm merely demonstrating that, contrary to the author's assertion, it's possible to use git without deleting branches and still have a meaningful way to measure whether a branch is "done", and it's the common-sense measure of "has it merged?"
Not much content here, it's a press release mostly stating that Allion is the first official independent SSD test house for the SSD Association. Certainly no additional evidence for the hypothesis put forth in the title, other than stating that USB3 is faster than HDDs can sustain, which shouldn't be news.
The first index is 0, the next is 1, and if you loop around backwards, it's -1.

Makes sense to me.
In regards to the complaint on lambda, isn't it more pythonic to use list comprehensions anyway?

intlist=range(0,16)

filter(lambda x: x % 3 == 0, intlist)

vs.

[x for x in intlist if x % 3 == 0]

Should be faster too: http://stackoverflow.com/questions/1247486/python-list-compr...

I know anonymous functions are idiomatic in javascript from using jquery, but I rarely use them in python. Does anyone have a good example of leveraging lambda in python?
I like the trash metaphor. I haven't formalized it yet, but often I will simply "mv" things to ~/old or ~/tmp and let it rot there for a few months. Thanks for the tip, I'll check it out.
Usually steering is powered by a hydraulic pump driven by the engine's serpentine belt. Automatic transmissions have torque converters, which are one-way (the engine can turn the wheels, but the wheels can't turn the engine). As soon as the engine dies, the serpentine belt stops, hydraulic pressure drops, and steering gets hard.

Some newer models (usually hybrids) power the hydraulic pump with an electric motor, and a few cars have purely electric power steering (just an electric motor, no hydraulics). In these types, a kill switch could be set up to stop only the engine, not the electrics. The battery could power the car long enough to stop safely.
This seems to be how Qt4 is. It's a great API to work with, but unfortunately results in 50-call-deep stacks (not an exaggeration -- I have to set valgrind to --num-callers=50 to get reasonable stack traces) and a lot of latency. That plus bugs in the new QGraphicsScene API are making me consider switching to something lower level, like Clutter or my old friend OpenGL.
And every one of those cameras sends a live feed back to the plants that assembled the iPad, in Communist China!

(Sorry, just had to indulge my paranoid side after seeing the story about the Firefox CNNIC CA cert.)
Growth in the modern age is rarely linear. The real risk in creating an "inefficient" solution is when you've done so at the cost of extensive technical debt not just mere inefficiencies, and this technical debt blocks your ability not only to switch to an efficient solution but to stretch your inefficient solution just enough to keep your business running during periods of growth. Failing to take advantage of an order of magnitude (or more) growth opportunity can leave your company at a competitive disadvantage or even kill it outright.

So build an inefficient system if you think it's a better solution in the short-term. But be careful that you know the difference between mere inefficiency and a horrible, grotty, dailywtf level hack-job that may seriously limit your company's future.
This seems like more of a criticism for the python port maintainer than the entire build system. It might be worth posting a request for Tk support to be made a variant of each of the python ports.

For the record, I use MacPorts over Homebrew for many of the reasons on this thread. I've been responding to people saying "What's the point?" because I see some of the benefits of Homebrew, even if I'm not fully convinced. (I suppose that I'm also frustrated at the common interwebs reaction of "But I use some other thing, so this new thing must suck." Homebrew may not be the answer to everything, but it's very worth looking at. There are some very good ideas there to some common problems.)

Having said that, my complaint about Python was explicitly specific to that package. That's why I said "the Python issue to be a particular pain..."

The Tk & Python issue has been brought up repeatedly on MacPorts lists and posts about MacPorts. They seem to prefer it that way, and for all I know, they have good overall reasons. Follow-up: Well, I haven't checked in a while, and I'm dead wrong. The getmail package currently depends on Python 2.6, which now does have a no-tkinter variant. Shows what I know.

Edit: By the way, the PHP on OSX is notoriously light on modules. There have also been a few pretty ugly issues with Perl and core modules. So I'm not denying that there are real reasons to worry about the built-ins. I said as much in my post above. There are pros and cons to each approach.
>>> from itertools import cycle
>>> iter = cycle(['red', 'green', 'blue'])
>>> iter.next()
'red'
>>> iter.next()
'green'
>>> iter.next()
'blue'
>>> iter.next()
'red'
Agreed, my mum uses skype to talk to me (I live in Canada, she's in the UK). It's not a device for my mum, because even for the applications she uses (my dad worked in IT since before the 90's, it took until the 2000's to get her on a computer, and until 2008 to get her on facebook) it's simplistic. For my father, who did web development and application development (before then he was working with some of the first computer controlled fuel injectors in vehicles, so I have no clue what language that would have been programmed in), it's far too simplistic.

I believe one of my cousins even got my grandmother (in her 90's!) onto the internet to pay her bills. Telephone banking with a nearly deaf woman who has no hope in hell of understanding an Indian woman, and no chance the Indian woman is going to understand a 90 year old Geordie. I doubt it would be hard to teach her how to turn on skype, meaning the iPad would be below her uses.
Soon (hopefully that was vague enough). According to DHH - "Rails 3 beta is almost ready for public testing. We're just hammering out the last bugs in Bundler. Stay tuned." [1].

As far as I can tell from watching commits/tweets/etc, the finishing touches are being put on now. It sounds like there is still some work to be done on Bundler as well as finishing up javascript handling. Other than that, I believe that all of the big pieces are in place and ready for a beta.

Hopefully someone on the core team who reads HN can chime in with a better response.

1. http://twitter.com/dhh/status/8522612662
Apparently from all the downvotes I am the only one that hates a small iframe with a wall of text?
Nope, although apparently somebody really wanted it to be on the same day as the PHP folks announcing an exciting new product.
Manufacturing cost effectively and manufacturing cost effectively while maintaining workplace safety, paying a living wage and respecting the environment are two different things, and it is the latter that you are comparing with the former.

So the only reason why you can buy that stuff manufactured in China cheaper is because of a combination of lack of respect for human beings, sloppy environmental controls and unsafe work place practices.

If those were brought up to the same standards that are held in the developed countries the prices would be roughly the same after import duties and transportation costs are figured in.
I find Hacker Newspaper uglier and less legible, because it's non-linear and harder to visually scan/skim through the items. However, as a non-linear format, it is inferior in design to newsmap: http://newsmap.jp/#/t/us/view/
I can't recommend RVM highly enough. Not only will it let you easily switch between MRI (the standard ruby interpreter) versions. It'll also let you switch just as easily between other interpreters such as JRuby, Rubinius, Ruby Enterprise Edition, etc.
A lot of IDEs/text editors can autocomplete HTML closing tags, so I find the comparison based on characters moot.

I'll admit it might make things easier to navigate with the eyes. But on the other hand it seems to abstract something that's really not that complicated to begin with.
> MacPorts is an autarky -- you get a duplicate copy of zlib, OpenSSL, Python, etc. Homebrew uses what is already there, and consequently, most stuff has zero dependencies and builds faster.

MacPort's self-sufficiency is its strength. Apple's system is managed by Apple, via Software Update. Depending on and modifying that system is foolhardy. What happens when the next point upgrade of OS X updates a library to a non-compatible version? Or what if you need ruby 1.8.7, but Leopard's ruby is at 1.8.6 (1.8.7 was a large release)? Your package system doesn't talk to Apple. Apple's update either breaks you, or your updates break OS X.

In fact, MacPorts once linked to OS X's libraries, but they found out how brittle this was, and switched to the current system.

OS X is not a Linux distribution, and it is not organized and defined by its package management system. If you want the flexibility of an open source Unix package system in OS X, you have to build one separately from Apple's Emerald City. The thing is, you can, and it works pretty well.

The problem I see most people having with the MacPorts / OS X duality actually stems from improper management of their shell's PATH. One way to manage namespace collisions is this: place MacPorts bin directories below the system PATH:

export PATH="/usr/local/bin:$PATH:/opt/local/bin:/opt/local/sbin"

and then create symlinks in /usr/local/bin to specific MacPorts executables that you would like to have on the top of the search stack. That way, you'll use Apple's binaries by default, and then you can cherry pick the MacPorts binaries that you would like to use in place of OS X's defaults. The inverse of this works quite well too.

> Dependency resolution and updates are basic or not working yet.

I'm sure this is in the works, but my feeling is that managing dependencies and updates are the raison d'être of a package management system. Without this, you just have an installation management system; a shortcut around `make' and `ln'.
I think it is worth pondering, especially for anyone in danger of being so perfectionistic that they are looking like they might never ship. I got a link to the Duke Nukem Forever story from one of the comments. I am currently feeling like that about some of my goals -- like I piddle and fiddle and tweak and never accomplish anything. Maybe I am just having a bad day (heck, that's very likely -- I am treating a sinus infection), but this article meant something to me personally. Yes, you need to not just fuck it up royally. But, like with Duke Nukem Forever, you really can err terribly in the other direction as well.

Thanks for your very well-thought out and meaty comments.
Coaches Still Vexed by Going for Two
It is so. much. faster. to write. I've never been able to articulate why, but, in particular, if you do interaction by lighting up DOM elements by class in jQuery, Haml is like having a language designed to lay out UIs.
The readme also says:

You don't have to sudo

It's up to you
IPhones Vulnerable to New Remote Attack
Put it in a directory in your home folder instead.

(Also: this doesn't address the security concerns, but by default on a clean install of SL there is no /usr/local, so you're really not hurting anything.)
It's a really terrible press release. First they talk about a collaboration to develop a PCI-based SSD card. Then they start talking about the limitations of USB 3, which shouldn't even apply to a PCI-based SSD storage solution. They even manage to get the speed wrong. USB 3 is 6 gbps, not 5. Don't waste your time reading it.
A little misleading, USB 3.0 is only expected to have a throughput of IIRC 400 megabytes/second after protocol overhead. It's entirely possible to get 300 megabytes/second out of a properly configured HDD system. Considering the considerable price difference between a HDD and SSD, 33% faster transfer rate isn't hugely important for the average consumer.

SSD might have some advantages, but it also has disadvantages and I'm still not personally impressed with the drives viability over long periods of use.

Edit: I also fail to see how USB3 is really relevant, especially considering that eSATA is capable of providing up to 6Gb/s, compared to the 3.2Gb/s estimated by the USB 3.0 specification after protocol overhead. Regardless of HDD or SSD, USB3 still isn't the deciding factor if you're looking for high transfer speeds with external drives.
You can change your mind and turn a 'bookmark' into a 'branch' and back again. you can also fold your branch into another one and pretend it never happened. Or you can pick your branch up and place it somewhere else in the tree, or...
I have found it very useful when writing unit tests for a particular method. I don't have to instantiate the class for which the method is a member of; instead I can easily pass a mock object as self that only contains the properties the method is supposed to test.

Furthermore the claim that python doesn't support objects cleanly or easily is unfounded: 1) everything is an object in python (http://diveintopython.org/getting_to_know_python/everything_...), including classes. 2) properties of an object are accessed in just the same way as in Java (obj.property), I don't understand where the confusion lies.
LSF Network buys Unreal Marketing
Groovy++
Yeah, I'm excited about this not so much because I think I'll make much use of the feature, but mostly because I hate the idea of patent trolls at Apple limiting what I can do on my own phone by threats of frivolous lawsuits.

I'm just thrilled to see Google standing up to the bullying.
That's another demonstration of my point. Many, many people out there in the non-tech world would expect that the first element would have an index of "1". First = "1st" = "#1." On the other hand, we often experience the convenience of pointer arithmetic (or similar) with zero-indexed arrays.

Yet another programmer/techy and ordinary person divide.
Iunno, 99% of my HTML writing is copy & pasting. I just write one thing and usually just copy and paste it around. The bottleneck is in fixing CSS and cross-browser display, not really the speed of HTML coding.

That being said, if your HTML development style is based around writing everything then I can see how it would be faster. But for me I use autocomplete+copy&paste, and then usually a lot of other stuff I (embarrassingly) google and then copy from examples.
Sigh. Please try to read in context and not score debating points.

I didn't say that the README insists on not using sudo. I was responding to a claim that the Engine Yard blogger made up the method of reassigning /usr/local to a regular user. That's simply not true.
Also seems to work with Safari
Funny, I could have posted the same comment after s/git/mercurial/g and s/Github/BitBucket/g. But then again, it would be equally stupid and trollish.
In case you didn't see the etherpad link:

http://mixergy.etherpad.com/56?
> Manufacturing cost effectively and manufacturing cost effectively while maintaining workplace safety, paying a living wage and respecting the environment are two different things, and it is the latter that you are comparing with the former.

It would be interesting to see some objective measurements about how much of the cost difference is explained by which differences in practice. For example, I think the "living wage" paid to manufacturing employees in the U.S. frequently exceeds the real living wage by a substantial margin, which they exact from their employers via a monopoly on labor (unions).
Google Chrome OS tablet concept revealed
Yes, all that's necessary is for the content author to provide a Theora encoded version of the video.
I hate sounding paranoid, but all of these things are possible. Given the tight relationship between Chinese companies and the Chinese government, such shenanigans would be trivially easy.

For anyone looking to do manufacturing in China, this is something to consider.