skysight-inc/HackerNews huggingface dataset:
There's also no reason to spoof the MAC addresses of real subscribers.

If your modem's external MAC isn't in Comcast's (global!) subscriber table, they give your modem a "walledgarden" default configuration file that causes it to reset frequently, and a poisoned DHCP DNS that directs all queries to their "Subscribe Now!" webserver.

Some of the European ISPs have countermeasures that rotate the names of the configs frequently, but Comcast doesn't do that -- if you've modified your modem, all you have to do is have your modem ask for a different config file (the names of which it will sniff from your neighbors), and set a different DNS server on the modem's immediate clients.
"90% of everything is crud"

My first interpretation of this was that most development projects are basic create-read-update-delete applications, but maybe that's not far off from the intended meaning.
It's not really about high and low, it's more about valuation. If you can peg your valuation at $20 per share based on a variety of factors related to your revenue, free cash flow, discounted growth, etc., but your stock is trading at $12/share, your company is undervalued and a share repurchase may be a good idea. But if your stock is trading at or above $20/share, yet you can't make the case that your company is actually worth more than $20/share, it's foolish.
You've worked for a small business, but have you ever owned and/or ran one?

The time I have to spend on government forms (taxes, business registration, etc) takes away time from other activities (SEO, new blog posts, software development).

Yes, I can outsource this, but I still have to deal with it. And it adds no value for my customers. Accountants and Lawyers don't get software built, they don't get blog posts published. They handle my interaction with the government.

At my current company (day job) we're spend a lot of time working out some stimulus package details. It's a bunch of overhead, we have to track our time on it, and for a reimbursement of 80 cents on the dollar.

So, if you think that lawyers and accountants somehow get things to customers, yes, you have a valid argument. I haven't found that to be the case.
Internal Server Error
Unfortunately Ruby is not wrong. Ruby is simply being strictly correct from a logic point of view, where < is R^2 -> {T, F}, as opposed to being strictly correct from a math-notation point of view, where < is treated syncategorematically. Neither is correct, sans qualification; given that Ruby is not aimed at mathematicians, it's not unsurprising to find that it's not going to go through the extra parsing effort to use math notation.
I think some people are forgetting that Flash is used for more than just serving up video and pop-under ads (though admittedly that would be its largest use).

There are a lot of games that may not be possible to run on an HTML 5 canvas.

Also, lost in this discussion is the fact that one of the more popular browsers doesn't support HTML 5 in its current version or possibly even its next.

Does streaming video work under HTML 5 specs? If not, that's another thing that Flash can do, which you can't with html5.
While I agree that this guy is clearly a thief, I'd still disagree that there's no legitimate reason to modify a modem. I don't rent mine, I bought it, and it shouldn't be a crime to modify my own property. Maybe I'd like to change the firmware or remove the case to scavenge parts. Maybe I even want to change my MAC address. My old ISP made me re-enter my account info when I did that, and then it would work again. (Haven't tried it with the new one.) Nothing wrong with that.
Does a site do this? This sounds like a great approach to that sector.
There's also the alternate argument of doing it yourself the first time just to help build your community, then once you've pushed that as far as it can go, use mainstream media to help push you to the next level, since they have connections you likely can't get in any sane amount of time.
People have done real prison time for phone phreaking.
The unfunded future liabilities of the US government are staggering, some $50 Trillion if you assume that Social Security etc. remain the same.

This means either SS will be reduced, or that SS taxes on earnings will be increased, or that the currency will be debased (or some combination of the 3).
But... isn't that what the author says?

Haskell is right. Sugaring in the conjunction like Python violates non-associativity, which exists for predicate relations in human languages. And it's not a type error; it's a syntax error.

Note that in mathematics one sees things that look like "1 < i < n", which seems similar to what Python allows. But, if you ask a mathematician to read this aloud, they will say "some i between one and n", or in certain contexts "all i between one and n". This is an entirely different thing; it is not a predicate at all.

[...]

So with <, it's non-associative and bad to sugar up the error you get if you try to use it associatively.
1 < 2 < 3 DOES evaluate to (1 < 2) < 3

And 1 < 2 evaluates to true. What else would it evaluate to?

That leaves (true < 3)

Which fails. This isn't a mistake by ruby. When you chain methods you have to think about what they return.

And the issue here isn't associativity.
f) Amazon believes the consumer will eventually force the prices down and this was their method of bringing public attention to the issue. Thus every author posting on their blog today ultimately helps Amazon.
Fair enough, reading comprehension fail.
Yeah, that was my first thought as well. Better article title might be "Why Tech Companies Suck for Not Paying Out Dividends."
Lower taxes != less complex taxes. They've only gotten more complex. And this is too the benefit of large companies who can hide tax loopholes in the code. It also benefits the large accounting/tax companies. They will have a great business as long as we have a complex tax code.

"IRS Commissioner Douglas Shulman does not file his own taxes in part because he believes the tax code is complex."

http://thehill.com/blogs/blog-briefing-room/news/75119-irs-c...
Perfectionism: The Engineer's Bane
... you wouldn't happen to work on that, by any chance?
Report it and make $1337? :)
Melbourne Australia Hacker News/YC Meetup, Sunday 21st February
What: Hacker News meetup
When: 3pm, Sunday 21st of February
Where: Match Bar and Grill, 279 Little Lonsdale Stree, corner of Swanston, Melbourne.

Why:
By popular demand, we're again inviting Melbourne's Y Combinator/Hackernews devotees to come together for a lazy Sunday afternoon of sunshine & startup talk.

Tom & Fenn, alumni of the Winter 09 Y Combinator program will be there. If you're considering applying to YC, either for the upcoming Summer 10 cycle, or in a future round, this is your chance to talk to Melbourne's only YC startup about their experiences and seek their advice.

But you needn't be a YC aspirant to attend, anyone who procrastinates with obsessive re-reads of PG essays and eloquent dissections Michael Arrington's character is encouraged to come along, as is anyone who manages to avoid such distractions in the pursuit of startup success.

Get along and help make Melbourne the startup hub we know it should be!

http://www.facebook.com/event.php?eid=272449838595
But you can currently spend a grand on a laptop that doesn't have any detachable screen and/or touchscreen interface. This is a step up from that, albeit not 100% perfect.
I'm not talking about a different problem.

The bruteforce attack described in the article primarily affects short and dictionary-based passwords. If the password is of sufficient length and complexity (the keyspace is large enough), then bruteforcing becomes computationally infeasible. What the article proposes is, essentially, to use a more computationally expensive algorithm for the benefit of protecting shorter, weaker, passwords. I disagree, and think that increasing the computational cost of the algorithm itself should be used to enhance the security of passwords, rather than having their security depend entirely on that increased cost.

Good passwords stored as a salted hash, or preferably, as an HMAC, are in no way insecure. I feel that implying otherwise is a disservice.
Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea.

The biggest differences between Mindvox losing it's password file in 1995 and a webapp losing its user table in 2010 are:

* Web apps are getting fielded with straight SHA1 hashes, which is inferior even to FreeBSD's original MD5 hash scheme.

* Brute force attacks have gotten much faster.

The main advantage to bcrypt over, say, AES, is that the key setup is really slow. Mazieres spotted a weakness in Blowfish and turned it into a benefit.

Is there some real argument you have with me? I agree: if you lose your user table, you have real problems apart from losing password hashes --- though we could bicker about which of those problems is worse. Where are you disagreeing with me?
I loved freelancing when I had a ton of work on, because it basically meant I could code and get paid better for it than I otherwise would.

I hated freelancing when I didn't have a ton of work on, because it meant I had to do stuff that felt "dirty" to begin with, and then boring later on, like marketing, sales etc.

I'm now moving to a completely different country (with a far lower cost of living and tax rate) so I have more time to work on my own projects without worrying about needing to do the whole sales and marketing song and dance. I'm still not entirely sure if I want to focus on being an employee or being a freelancer over there though, Even after almost ten years going it solo, the sales part still scares me.
That is a decent rational, except that whichever rich nation makes the breakthrough (assuming it occurs) will not have a monopoly on the technology (unless it involves mining He-3 from the moon), in which case the rich nation that invested in lunar mining technology will have quite a jump.

It's pretty hard to keep big engineering secrets. As soon as the feasibility is proven, the fast followers will jump on the bandwagon.
Since server is still throwing a 500.

Another source: http://centralcomputing.blogspot.com/2010/01/tech-mania-down...

(a bit ad-infested, though. I am not affiliated in any way.)
Is there a Tetris AI that can play against this bastard? Has that been done already? Might as well let the computer try to outsmart itself.
I'm not entirely sure if this is the right approach, but a job site that works as well as job postings on HN is definitely in demand
I wonder if the black background on their book's icon at the bottom is supposed to be there or not. Since it's a PNG and everything else has a transparent background I am guessing it is a mistake. Silly little detail..I know...but I am a designer so this stuff jumps out at me. I can't wait to read the book though.

http://37signals.com/images/icon-crumple.png
Could always just extend the current jobs board for YC companies. I think the community would be effective in up voting real opportunities and flagging spam.
woop 57 characters, now will you hire me?
Fullscreen Emacs on OSX
Why Lisp loves parens w/Clojure
I do. What other disclaimer besides "I'll approve it quickly" would be needed?
Link: http://www.facebook.com/event.php?eid=272449838595
You sound like someone who has never run John the Ripper.

There clearly are passwords that are impractical to crack. To get one, just "head /dev/random | openssl sha1".

Nobody uses passwords like that. They're irrelevant. Instead, the smart ones use passwords that contain a combination of words, numbers, and punctuation. John the Ripper has been cracking those passwords for over a decade.

"Salted hashes" are insecure. They'd have been rejected by the FreeBSD team in 1997. If you choose to make a religion out of not using bcrypt, do what the RFC says and use PBKDF.
Or, Google has cached the posted article:

http://www.google.com/search?q=cache:www.thechromesource.com...
That is quite correct. If you look up the mathematical definition of associativity, the behaviour of the "<" does not fit it. In fact associativity is only a property that can be possessed by functions or operations that operate on a particular set. Thus, both the inputs and the result of the function or operation have to belong to the set. For the "<" operation, the inputs are numbers and the result is boolean. A boolean value cannot be an input for the "<" operation (if you take the classical definition of "<"). Therefore, "<" does not operate on a particular set. Therefore "<" cannot be associative.

The behaviour of "<" the author refers to is not associativity. Therefore, the languages he criticises do not really get associativity wrong, he just needs to brush up on his math.

Now you can say "well, ok this behaviour is not associativity but it is a well know behaviour of "<" and ">". Why can't the languages get it right?" I think the answer is that this (a<b<c<d) is one of those notations that look ok in algebra class but are really problematic if you actually try to define and use a logically consistent function notation, so it is not a problem for me, if some languages do not perform (a<b<c<d) as expected in order to keep their semantics clean.
I am not saying it's not a crime or that the hacker here shouldn't be punished. Just playing devil's advocate.
> "I think there is one metric that can be used to measure the value of a human life and that’s impact....(p.s. i don’t use spell check…deal with it)"

??
Are there any age restrictions? (High School Junior, 17).
One I got recently - and blanked on - write a function to generate all the permutations of a string. Recursion preferred.
A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information).

Are you suggesting that because a comprise is bad, nothing should be done to reduce the magnitude of the impact? This argument does not hold up in general, and it is especially weak when arguing about using encryption algorithms with freely available, high quality implementations. The developer effort required to use bcrypt is minimal.

Also, you seem to be making the incorrect assumption that only poorly written web applications get their databases compromised. Web applications with excellent security get their databases stolen for a variety of other reasons. Even if the programmers do everything right, a careless employee might get his/her password sniffed or stolen by a key logger. If a company uses external hosting, its database could get stolen because of a mistake by the hosting providers.

In summary, the risk of your database being stolen is always present, regardless of the diligence of the the programmers who implemented the web application. The fact that a compromise is bad is not justification for ignoring simple security measures that take minimal effort to implement.
I am a crypto noob, so please excuse me if I sound stupid. But why not force your users to pick a password that is at least 8 characters and contains at least one digit, one capitalized letter, one lowercase letter and one special character, then gen a 16-byte salt and run it through SHA-512? The examples given in the article are for 6 lowercase alpha-only characters, which has always been relatively trivial to crack.

This brief article I found from 30 seconds in google shows my example at the bottom ('96 characters'): http://www.lockdown.co.uk/?pg=combi

I acknowledge that bcrypt seems like a simple safeguard against password attacks, but I don't doubt a hacker's ingenuity in developing a method to make attacks against it reasonable - especially if it becomes widely adopted. And I think once you've lost your password database you're already completely fucked, in one way or another.
I'm sure Adobe will open source the parts of Flash they own.

They will just do it too late for it to make a difference.
My take: if it's "too big to fail" they need to create a "living will" to direct how to liquidate the company when it does fail. This avoids a sudden, unexpected shock to the system and any resulting dislocations.

In my mind it's debatable that something like that can be done practically, or that a "living will" would really work in practice. I am reminded of the "duck and cover" drills from my youth. Still, something needs to be done.
It's also a different world now. You could make a couple bucks on the side in the late '70s and still (sometimes) get away with it, because the problems with our infrastructure hadn't been fully criminalized.

We live in a world today where some significant percentage of all bank transactions in some countries are fraudulent. We've officially lost our sense of humor.
Hmmm... but by the same argument, Ruby is also doing it right, by correctly crashing at runtime (there is no way for a language without a type-system and with redefinable operators to discover the error at compile time).

Somehow the author isn't clear on whether he wants "1 < 2 < 3" to return true or to be rejected; if it's the latter, then most languages get it right (except Python and Matlab, as far as I know).
What do they mean by "pick a fight"?
In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.
I'll forgo a mathematical argument in favor of a practical one. If you have a choice between offloading complexity to your users or your developers, you should choose your developers every time. Rather that requiring complex password schemes from your users, have your developers use a slow hashing algorithm instead.
Always the s-shaped one? (Or the z-shaped) It guarantees you'll eventually lose.
It hurts the reader, in that they can't get cheap eBooks until a year after they are released

One of the lessons I have learned from this debacle is that I should be careful what I wish for. It turns out, according to my favorite authors, that time-sensitive pricing is a huge part of what makes the economics of their business work. After all, an author's hardcore fans are willing to pay more, and time-sensitive pricing -- with books costing more on the day of release, then gradually getting cheaper -- is the established mechanism for extracting that premium. The "hardcover" vs "softcover" vs "remaindered" thing is the industry's way of signalling the different price points.

I've suddenly started looking at hardcover buyers with more respect. These people aren't suckers, or at least they aren't mere suckers. They are the patrons, the hardcore fans, that are keeping my favorite writers in business.

It would be the height of irony if I eventually got what I used to think was my wish -- flat-rate ebooks at, say, $5 per copy, no premium pricing -- only to see my favorite authors either go out of business or figure out some other way -- exclusive early releases by subscription, the street performer protocol, selling T-shirts, product placement -- to recover the equivalent of the cost of a hardcover book!

We're all going to save money in the e-book era, but I'm not really sure it's going to be that much money: Writers and editors and marketers still need to be paid. We'll save on printing and shipping, but that may be about it. There just aren't tons of excess profits sitting around in book publishing: The audiences are too small. I might not even save money on bricks and mortar: I like visiting bookstores or the equivalent, even if just to sit and drink tea while surrounded by media.
He's implying that using bcrypt (and other iterative hash functions like PBKDF2 and scrypt) raises the cost of mounting a dictionary attack compared to commonly-used and -recommended hash algorithms like SHA256.

Which, uh, is an objectively verifiable fact.
As an author and niche publisher (of sorts) I'd much rather Macmillan "win" and shoot themselves in the foot. Higher priced e-books from the major publishers gives independent authors and small presses the opportunity to compete at lower prices. Worked on the iPhone App Store pretty well..
I agree wholeheartedly.

The iphone development target is the first step of many. I predict they'll be investing in OSS developers to support their eventual CSS/HTML 5 target they make the flash toolkit spit out as well after the iphone thing is working.
Here is a site using stackexchange platform for sharing ipad apps ideas.

http://ipad-apps.me/
Amazon real issue may not be the price issue but that Amazon
isn't dictating what the price shall be, someone else is.
Amazon may think that if they loose control over price, they loose control over their site.
offline full installer without the bootstrapped updater crap

http://dl.google.com/chrome/install/307.1/chrome_installer.e...
I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition).

The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, whether you use bcrypt, scrypt, PBKDF2, salted hashes or HMAC. Encourage them to use bcrypt or some other iterative technique for the security benefits, but don't exaggerate and tell them that they're "effed" if they have salted hashes. They're still a long way away from storing passwords in plaintext.
[] I can read a 35 bullet points list to the end without getting distracted
That's only for when the problem is with Chrome. :-/

I'm pretty sure it was it was badly coded script but I can't be arsed to dissect the webpage and fix it for them.
Once you go down the road of "not doubting a hacker's ingenuity", you might as well give up and stop applying OS patches. In any case, with "16 byte salts and SHA-512", you're pitting hackers against the folk wisdom of PHP developers. With bcrypt, you're pitting hackers against the IACR. You can't know everything, but you can pick the right battles.
Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.
The overwhelming majority of us did not agree to borrow this money with compounded interest payments, therefore I see no reason to pay the money back.
You're arguing for the sake of arguing. The developing weaknesses in SHA-1 don't make it a poor password hash. That's an irrelevant factoid you threw in to cloud the argument.

Pick a number of passwords to lose from a table. Hash them with any of the SHA-3 contestants and a "salt": you will lose more. Hash them with bcrypt, you will lose less.

Again I'm left asking you: what's your point? What are you trying to prove? That you know that there's a SHA-3 contest? You haven't refuted anything this article says; in fact, you keep accidentally managing to validate it.
If you can force your users to pick strong passwords, good for you. But in practice, that's almost impossible.
well, why didn't you? Is it lack of savings or lack of confidence or something else?
That link doesn't appear to work for me... it just redirects to my FB homepage.
First off, I notice it says 'up to', there is no telling what he'll be sentenced to until it's done.

But I find it a bit weird to see a sentencing guideline higher than second degree murder.
Or you keep them on the mantelpiece, but that could be the quadruple trick answer...