"Username or password is incorrect" is bullshit - <AUTHOR> https://hackernoon.com/username-or-password-is-incorrect-is-bullshit-89985ca2be48 <comment><USER2> The right answer isn't a blanket "sites should do this super-secret e-mail- only shuffle and not tell you anything".

First, you should define your threat model: which information is considered secret and which isn't, and treat any violations as security vulnerabilities.

If usernames are public by design, then don't hide them in one form, and expose in URLs elsewhere on the site.

If exposing who's registered on your site really is a threat, then by all means have a weird registration (and password reminder) that doesn't tell whether it worked or not. But if your site is for cookie receipies and you don't consider exposing who's a fan of cookies a privacy violation, then just use most helpful messages you can.

<comment><USER3> Right, for example if you run an email service, your usernames (addresses) should be hidden. That's because a spammer could use your login page to find valid usernames and then send spam to them. They don't have to guess passwords to cause damage.

<comment><USER4> They could also use your signup page to attempt to create an account for email@example.com. Since you can't allow duplicates that rejection gives them the same information.

Might as well let a user logging in that the username is incorrect to make the legit use case, i.e. user has a typo and/or misremembers their username, more pleasant.

I usually suggest clearing the username field on failed logins as well. That way if there is a typo, the user doesn't try it again thinking only the password is wrong.

</comment></comment></comment><comment><USER5> I have an argument for "username or password is incorrect" messages: it's possible that the password is correct, username exists but isn't the intended one. Then "password is incorrect" message would be lying, as the issue is actually with a username.

<comment><USER6> You mean you log onto John with password 12345 and the website says "Some other user uses this password, but not John"?

Seems wrong, somehow.

<comment><USER7> If you, as a developer, are technically able to check that the password is used by another user, you have failed pretty big at best practices.

<comment><USER8> Doing it every time a user login failed is probably infeasible if you have even a moderate number of users, but you can presumably do it on an ad hoc basis unless you have a _ton_ of users. Or am I missing something?

<comment><USER9> Yes you are. If you have done your security right, users' passwords are not stored in a form that lets you determine whether one is equal to another.

<comment><USER10> It's a little different from determining if one salted hashed password is the same as another salted hashed password. Whether it's account signup ("the password is already in use") or login ("you typed in someone else's password"), you have the plaintext of the password, and can just loop through the user table and attempt a login for every user with that password. It's slow when you have a lot of users, as mnarayan01 mentioned, but certainly reasonable as an ad-hoc thing.

(Not that any of this is good practice.)

<comment><USER7> If you are able to do that, then I insist: you probably have failed at best practices.

Most likely on this part: a good password hashing (ie. security hashing) should be fast so that you can log-in but slow enough to prevent brute force (ie. what you are implying). Hashings like md5/shaX don't have that: you can compute of lot them very quickly, which is their purpose. Bcrypt/Argon2/... will have a cost/time that will allow only a few computation per second, which is their purpose.

So if you did best practices well, and try to loop through your users database, (I assume you have more than a few hundreds users) it might take some time, some long time. Anyway, you'll then fail at another best practice because the initial user trying to log in will get bored and be gone somewhere else ;-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Signup and login should behave the same, and provide no information wether the email is registered or not. And username should be treated as public.

So for login: always say "email or password is incorrect".

And for register: as he said, always say "we sent you an email to verify your email".

<comment><USER12> Why? I don't see why it's important to hide existence of a user unless you're allowing people to try multiple logins per second on your site. (I'm not an expert so I am sincerely asking to help me understand.)

<comment><USER13> Disclosing the existence of a user increases the success rate of certain attacks.

Say I've got a leaked password database for foo.com and know that the user firstname.lastname@example.com uses the password "tomato1". If I try using his credentials to log into bar.com and get the message "username or password is incorrect", I'm just going to try the next user on the list. If I get the message "incorrect password", it makes sense for me to try "tomato2", "tomato3" etc. If I know that your password policy requires eight characters and a capital letter, I'm going to try "Tomato11". This is obviously trivial to automate.

You can't protect your users against credential-stuffing attacks if they use the same password everywhere, but you can offer them a small layer of protection if they use the same password with minor variations.

As others have pointed out, mere disclosure of the existence of an account could be a serious privacy breach in itself.

<comment><USER8> Any evidence of this being used in the wild, particularly where the attack is only trying password variants if the initial failure indicated the user exists? Not disagreeing with the point, just would be interesting if anyone's seen such an attack.

</comment></comment></comment></comment><comment><USER14> Not quite on topic, but it would be nice if more websites would offer the option of using client side TLS certificate "login" with or without an additional prompt for a username and password.

It would be next to impossible for an attacker to bypass that. For example, even if the attacker provided the correct credentials, they most likely would not have the associated client-side TLS certificate private key. Then the server could just reject the log on attempt outright (since the certificate wasn't provided or verified).

<comment><USER15> Sounds like a great solution - would browsers need to support it? Do you have any resources on implementing it?

<comment><USER16> Browsers has supported it since the late nineties. The problem are on the practical side. If you ever log in from more than one machine, all must have your private key, and the mechanism for synchronising keys between machines are not there. You have to manually install your key each place. It has also been too hard for most people to make and handle public/private key pairs. Also, if you don't have the private key with you, there is no way you can log in to the site. All of these problem and many other usability problems would have to be solved for client side certificates to be a success.

<comment><USER14> > If you ever log in from more than one machine, all must have your private > key, and the mechanism for synchronising keys between machines are not > there.

I don't think that's good practice. What's better is to have a separate key/certificate per device that's used to access a service. That way, even if one machine is compromised (or stolen), then the user can still use other devices to log in. Also, the service provider can disable certificate log in on a per device rather than a per account basis.

> Also, if you don't have the private key with you, there is no way you can > log in to the site.

That's not necessarily true. Some HTTP server software (e.g., nginx) do have the option of requesting/asking for a TLS client certificate rather than requiring one. If one is not provided, then it's still possible to connect and log in. Server side policy can be much more strict in terms of locking the account in case of incorrect credentials or restricting access to certain account features if the client certificate wasn't provided.

</comment></comment></comment></comment><comment><USER17> Even if this doesn't increase security, you should still do it in the hope the user will check the username they've just typed as well as retyping the password.

<comment><USER18> Why? Why not just tell the user what is actually wrong?

<comment><USER19> Because the application doesn't know what is actually wrong. The error message is actually correct as written. The user entered their username incorrectly or their password incorrectly, or both. The application doesn't know which and shouldn't guess!

<comment><USER20> This is true for existing user with wrong password, but that message would be wrong if the user doesn't exist. In this case, the error clearly would be the username, not the combination user+pass.

<comment><USER21> How can the pass be correct if the username isn't? A password is only correct in the context of a specific account.

<comment><USER22> The password may be correct for the user (who is a person, and has a password for that service).

Of course the person may have multiple user accounts and he may have given the "wrong" password for the "right" username account, but he may also have given the "right" password for the "wrong" username.

</comment></comment></comment></comment></comment></comment><comment><USER23> The article explains how to do it properly at the end:

> To prevent attackers from knowing whether an account exists or not your > signup must only take an email address and provide no feedback in the UI if > the sign up succeeded or not. Instead the user would receive an email saying > they're signed up.

Is this not also part of the various 'best practices'? (I confess I don't read too many of them!)

<comment><USER24> Typically, yes. This post didn't really offer any new insight to this. Maybe it's a PSA? Either way, it completely depends on the site's threat model. In the case of GitHub, it's quite useless because a user can just go to the targets's profile to see if it exists. Thus, it really isn't in GitHub's threat model, obviously.

Where it gets really interesting is when you perform user enumeration attacks via timing. IE: it takes the server a few milliseconds longer to send a registration email than to not, or it takes the server longer to try to validate a password hash than to lookup a nonexistent user.

<comment><USER25> Is this possible to detect despite external factors (variable latency etc)?

<comment><USER26> It's black magic to me, but I'm paranoid about timing attacks after seeing a few examples in the past of what's possible for a clever attacker to guess if they can gather data from a number of requests.

</comment></comment></comment></comment><comment><USER27> The solution is relatively simple.

1\. Email and password for login. Don't tell the attacker which is correct.

2\. Email and password for registration. On registration send confirmation email. If user is already register attacker would need access to their email. Access to email is game over.

So now an attacker can't see which users are registered with your service and you've protected your customers privacy.

Extra points if your code is aware of timing attacks.

<comment><USER28> > 2\. Email and password for registration. On registration send confirmation > email.

This opens up a different problem. It should be:

2\. Email only for tentative registration. On tentative registration, send confirmation email.

3\. User clicks link in confirmation email, which takes to page for setting password. (Alternatively, confirmation email includes randomly generated initial password, user is required to change it on first login). After password is set, registration changes from tentative to confirmed.

If email and password are both included on the initial registration form, an attacker can try to sign up people and some fraction of those people will accidentally click the link in the confirmation email, thereby resulting in some new accounts where the attacker knows the email and password, and the email owner does not know the password.

<comment><USER21> You should definitively set the password after clicking the link. That said, what would an attacker do with that account?

<comment><USER28> Suppose it were a social media site. Now that attacker has a working account with someone else's email address, and that email address is considered verified by the site.

The attacker could then use that account to post threats, harass people, and so on. If he goes far enough that either law enforcement wants to come after him or someone wants to sue him and the site is served with a warrant to reveal information about the poster what they are going to cough up is the verified email address of the account holder.

That will be followed to the email provider, and from there to the email address holder. The email holder's claims that he never made the social media account are going to sound unconvincing--he clicked the confirm link to make the account!

Remember, a civil suit only requires a preponderance of the evidence, not proof beyond a reasonable doubt. That verified email might be enough to reach that standard.

In a criminal case it would not be enough...but if the matter was serious enough it might be enough to justify a warrant to search the email address owner's place and computer. At the very least that would be very annoying, and at the worst it could uncover things that the email holder does not want brought to law enforcement attention.

<comment><USER21> And all of this activity on the site happens without the site ever sending a single other email besides the account verification, that would tip-off the victim?

Color me unconvinced.

</comment></comment></comment></comment></comment><comment><USER29> The title is "bullshit". The real problem is that they leak the information they try not to leak anyway, on a different form. This is a common, but not universal, problem.

It's not OK to leak information, even if that information is maybe leaked somewhere else already.

<comment><USER30> In the GitHub case the handles are public information. Anyone can go to [https://github.com/<handle>](https://github.com/<handle>) to verify if it exists. So they trade off usability of a clear error message for no gain at all.

<comment><USER31> This is true for the username but it's possible to make your email address private on GitHub in which case the message that your email is taken can still be considered an information leak.

<comment><USER32> You can check if an e-mail is associated with a GitHub account easily. You forge a commit with this email as author email, push it to a foo/bar repo, then look at [https://github.com/foo/bar/commits/master](https://github.com/foo/bar/commits/master) .

</comment></comment></comment></comment><comment><USER33> Ask HN: Why does Amazon allow multiple accounts with the same email address? (2014) | [https://news.ycombinator.com/item?id=7075372](https://news.ycombinator.com/item?id=7075372)

<comment><USER34> Interesting. Just reading this now, but it makes me wonder, what happens if you set two accounts to the same password?

<comment><USER35> > _you can create two accounts with the same e-mail address, but you will get > into trouble if you try and give them the same password. I 'm not sure what > happens, so try it and see._

</comment></comment></comment><comment><USER36> It's still good advice for software where there is no public signup, such as SaaS where accounts are created by administrators.

</comment><comment><USER37> Isn't the other reason so that adversaries can't tell if a particular username/email has signed up? This is not so useful for something like github, sure, but certainly is useful for the more embarrassing sites where users have an expectation the site won't leak their membership.

So in some ways I've always thought of this as a privacy concern rather than a security one?

Edit: I guess I'm thinking purely of emails where you don't get availability checkers during sign up.

<comment><USER38> As the post demonstrates, you simply go to the login form to validate the presence of accounts.

Few sites remember to anonymize that, which might be the real PSA: in such a case, if you require an email confirmation anyway, just send the "recover password" email internally, but let it look like the regular sign-up flow.

If you don't requite email confirmation, anonymous membership isn't possible (just try to sign up with that account, what is the site supposed to do that looks legit without giving away information?)

</comment></comment><comment><USER39> If you're just trying to find a set of accounts with a weak password, isn't it much more viable to use the sign-in page that shows "invalid password" instead of "invalid username or password" rather than dealing with captchas on the signup page? Assuming you can't just find usernames as public profiles like on GitHub.

</comment><comment><USER40> There's definitely a trend away from this to some degree lately, I feel. It's probably more influenced by Google not doing it with their accounts (enter username -> forwarded to password page with your avatar) more than anything else, mind.

</comment><comment><USER41> I asked this same question[0] on StackExchange earlier this year. It has been asked many times and it really comes down to considering a username a secret or not.

In B2B applications where there is no registration form, then the username is probably a secret. In B2C applications where anyone can register, then the username likely isn't a secret. Many of those applications have the concept of "mentions" by username so clearly the username is not considered a secret in that case.

[0]: [https://security.stackexchange.com/q/158075/11536](https://security.stackexchange.com/q/158075/11536)

</comment><comment><USER42> Try searching for your username on [https://namechk.com/](https://namechk.com/) [https://www.namecheckr.com/](https://www.namecheckr.com/) [http://checkusernames.com/](http://checkusernames.com/) or [https://pipl.com](https://pipl.com). I am sure these name checkers can't be built if they have to spam the sign up forms just to check availability (at least not for free if they have to pay for manual recaptchas).

The privacy is worth it.

</comment><comment><USER43> This is actually a feature for users who have almost the same username and mistype this instead the password. E.g. this could probably happen through an unfamilar kayboard layout.

I understand that a lot of people think this is a security feature, but once upon a time it was the lazy programmers answer when "SELECT * FROM users WHERE username=? AND password=?" didn't return a result.

With proper salts for hashed passwords you now have to find the username, use the salt to hash the password and compare this. If your database allows to hash passwords with a dedicated function it's still the easiest to say username OR password must be wrong.

</comment><comment><USER44> Stripe does it wrong, so it's wrong everywhere? Nah. _That 's_ bullshit.

For emails, you can very easily fake a second signup with the same email and ping out an enhanced verification email "Somebody just tried to register with this address but you already have an account".

Building the username into that flow is harder. That's why I preference not having separate usernames but some people would argue this is itself a bad thing (removing a factor or somesuch).

Either which way, _Stripe 's approach is broken_. That doesn't make the whole idea nonsense.

</comment><comment><USER45> Here is a super useful article about how you should build login [https://blog.codinghorror.com/the-god- login/](https://blog.codinghorror.com/the-god-login/) (if you don't want to rely on professionals from Auth0 or Okta :-). In the article, there is a very good statement "being user friendly is way more important than being secure" and this is exactly this case also...

</comment><comment><USER46> > Even if reCAPTCHA was perfect, a hacker could manually validate their > usernames of interest by trying to sign up, then automate an attack on the > sign in page.

Why is imperfect reCAPTCHA worthless? Do sign up pages even allow brute forcing of usernames (once validated)?

Is he suggesting to fix sign up pages, or to allow brute forcing usernames on login?

His writing style is dramatic, but the arguments are very weak.

</comment><comment><USER47> I like the dramatic style this opinion is written.

<comment><USER48> I could totally feel this blog post, not just read it.

<comment><USER49> Haha, that's cool with me.

</comment></comment></comment><comment><USER50> My other favorite security theater advice is locking an account after x number of failures. How could this used for anything but DOS?

Depending on the service that's being protected, rate-limiting to 5 minutes between attempts, alerting the owner, and assigning them a temporary username seems more reasonable countermeasures to me.

</comment><comment><USER51> After reading this I went straight to change the login system I'm currently working on ... And discover that I would need to add some extra code paths / conditionals ... So for me it's not "best practice", it's more todo with laziness and not wanting to add complexity to critical functions.

</comment><comment><USER52> This is a pointless argument because I doubt Github or anyone who uses this message seriously considers it to be a security measure. Github's usernames are absolutely public. But they also have so many users that I suspect the wrong username is typed all the time. So yes, sometimes maybe the username is wrong.

</comment><comment><USER53> I have felt this same way for so long and I'm really glad someone finally wrote about it.

</comment><comment><USER54> What's the point of having passwords at all? If there's a password reset mechanism they provide no additional security. Just send a one time login token to the email.

Having a password just increases the odds of a hack by the user accidentally exposing it.

<comment><USER55> At the expense of convenience - I often need to access accounts on devices where I don't have access to my emails (e.g. if I'm using a semi-trusted PC [family devices etc.], I might login to Amazon, because anything there can be undone, but I wouldn't login to an email account [and if I haven't memorised my email password because it's in a password manager, I might not even be able to]).

</comment></comment><comment><USER56> Also if you are doing the username/password is incorrect you should also add an artificial delay if it's the username is wrong. Because you can tell which one is wrong my seeing how long it takes the server to respond.

</comment><comment><USER57> I suggest we just randomly say your username or password is incorrect.

"Your username is incorrect" "Your password is incorrect" "You hit the wammy. Try logging in again."

That way, you never know what's going on at all.

</comment><comment><USER58> In the article: "You gain no security, yet your customers lose clarity."

Oh boohoo. Like it's not on the customers side to know which email it is and which password.

And as many have said, one does gain privacy.

</comment><comment><USER59> So, as per the author, sites should first check if the user exists and then check the password? Why? What if the username belongs to someone else?

</comment><comment><USER60> Lately I've seen the catch-all "We could not verify the credentials you entered" and it has grown on me a lot.

</comment><comment><USER61> ... also, you can often do "Forgot my password" and if you give unregistered email it will tell you that.

</comment><comment><USER62> Doesnt "username or password is incorrect" falls into the Security through obscurity category?

</comment><comment><USER63> Good point. I'm embarrassed it didn't occur to me before.</comment>


Optical Proof of Work - <AUTHOR> https://arxiv.org/abs/1911.05193 <comment><USER2> In my view, the idea that optical PoW will reduce the energy cost of PoW mining is only temporary, because the Capex aspect of photonic miners is likely to be only a temporary competitive advantage - just like the Capex advantage of building ASIC miners is only a temporary, until each newer and more efficient ASIC is rolled out.

Photonic technology is new and not as readily available - for now.

If it turns out to be a way of minting money, demand will rise, and the competitive process of PoW will surely result in every photonic-miner owner trying to build a bigger, faster farm, just like all the others, and then we're right back to energy.

<comment><USER3> The ratio of HW cost to energy use is different for each computing platform and depends on algorithm etc. For example, it seems Cuckoo Cycle PoW has somewhat higher capex/opex in ASICs because of the heavy memory use.

For photonics the ratio changes significantly due to fundamental physical properties of analog computation, photons vs. electrons and so on.

Anyhow the process of the Si Photonics (and memristors/other analog approaches to AI) maturing to the same degree as digital ASICs will likely be long and gradual so this isn't a practical issue for next decade.

<comment><USER4> I had high hopes for Cuckoo Cycle PoW, but it turns it cannot be scaled linearly, or even at all predictably. So unless the consensus is to regularly tweak the algorithms pretty heavily, it runs the risk of reaching a situation in the future where the currently immense memory requirements being a piece of cake.

<comment><USER5> See the long discussion in [https://www.grin-forum.org/t/grin-improvement- proposal-1-put...](https://www.grin-forum.org/t/grin-improvement- proposal-1-put-later-phase-outs-on-hold-and-rephrase-primary-pow-commitment)

It will take many years for 1GB of on-chip cache to be common, but when that happens, hopefully commodity computing devices can support somewhat efficient Cuckoo mining...

</comment></comment></comment></comment><comment><USER6> Does anyone have any insight into what the actual nature of HeavyHash is?

> This leads to the selection of a hybrid design that composes digital hashing > with low precision vector-matrix multiplication (intended for photonic > acceleration) to produce HeavyHash. HeavyHash is an iterated composition of > an existing hash function, i.e. SHA256, and a weighting function such that > the cost of evaluation of HeavyHash is dominated by the computing of the > weighting function.

What is the weighting function? How do we verify that the result is valid? There have been other attempts to make proof of work more capex sensitive (especially memory-hard variants, like birthday paradox) but they all end up suffering from the fact that the very fact that you can verify the result means that you can brute force the outcome, and often that's a tradeoff that works.

Without knowing specifics it's very hard to say whether this particular proof of work algorithm does not permit an energy-inefficient brute force solution that will end up making the energy problems just as bad -- my intuition is that of course this won't work, as a matter of "no free lunch" \-- the cost to secure a coin will be equal to the value of keeping it secure.

I guess we'll have to wait:

> Beyond these intuitions, the specifics of the algorithm and a detailed proof > of its security will be published in a separate manuscript. [54]

> [54] Michael Dubrovsky and Marshall Ball. Towards optical proof of work; > oPoW. Unpublished Manuscript, 2019.

<comment><USER5> > the very fact that you can verify the result means that you can brute force > the outcome

No; you cannot brute-force the outcome in any realistic sense. For example, a Cuckoo Cycle [1] proof consists of 42 n-bit indices of edges that together form a cycle in a random bipartite graph on 2^n+2^n nodes, with typically n >= 29. Brute forcing over all possible size-42 subsets of 2^n indices will take well beyond the heat death of the universe. It's way easier to brute force the 256-bit private keys of all bitcoin balances...

[1] [https://github.com/tromp/cuckoo](https://github.com/tromp/cuckoo)

<comment><USER4> Can you please expand or refute on my comment above. (User jacobush.)

</comment></comment></comment><comment><USER7> So the big problem is that Market Forces are the largest decision factor in any distributed system.

Right now the barrier to entry is relatively low. Miners just need cheap electricity and off the shelf GPUs to get started. It's also well known to use and get started with building your own mining cluster.

The only way to fix it is to introduce graduated electricity rates that increase as more electricity is used.

<comment><USER3> Actually, electricity rates drop with economies of scale and willingness to set up in remote areas.

Have you looked into mining Bitcoin with GPUs lately? You would need free GPUs and free electricity to justify the effort to set it up...

BTC is only profitable with a. ASICs b. Very cheap energy source

Same is increasingly true for other coins.

</comment></comment><comment><USER8> I've spent a lot of time trying to understand PoW and came to the conclusion that is a distributed clock of sorts, described here [https://grisha.org/blog/2018/01/23/explaining-proof-of- work/](https://grisha.org/blog/2018/01/23/explaining-proof-of-work/)

<comment><USER9> Well, it relies on a synchronized clock, so it can't provide a clock. PoW adjusts the difficulty based on the time to try to meet some difficulty target.

In fact, if the time of nodes is not synchronized, it can cause significant problems and vulnerabilities. If time is too fast, the difficulty adjustment algorithm will think it mined too few blocks and decrease the difficulty.

<comment><USER10> Those aren't really "significant problems and vulnerabilities": any given node can lie about what time it is, but you're not trusting a particular node for more than the outcome of a single contiguous block—and block difficulty "velocity" is capped—so you'd need a Sybil attack to actually walk the difficulty down. Otherwise, even at 49% malicious nodes, consensus is just going to bounce between nodes that say the time was really short, and nodes that give "regular" timestamps, keeping the difficulty roughly constant within the network's margin of error.

Really, the timestamp field in most PoW systems' "block" structs (Bitcoin's, Ethereum's, etc.) is just defined as "a number that is higher than the one in the parent block, and not so high that when interpreted as a POSIX timestamp it would land 30+ seconds in the future relative to the local node's time." So you just need >50% of the nodes to have a ±30s clock sync in order to agree on which blocks are valid for consideration; and even if you don't have that level of synch, those blocks will still become valid _eventually_ , once they're old enough that all the nodes do consider them to be in the past. (And most PoW systems keep around near-"future" blocks until they're valid for just such a case.)

</comment></comment></comment><comment><USER11> This is a really fascinating paper. Given that cryptocurrency is here for the long haul - a reasonable assumption, even if it's only for money laundering - finding a way to cut the power cost and make mining resistant to bots makes a lot of sense.

</comment><comment><USER12> If the cost of operation is minimized and transferred to at the time of purchase, it will just make people buy MORE hardware, not less. Instead of realizing that money in operations, it will be shifted to purchase of increasingly more amounts of hardware as the primary mode of competition.

Building the hardware could maybe be optimized, but is unlikely to be energy efficient or environmentally friendly. At least with energy you can optimize the point source of pollution at the source, and as such use sources of energy that are renewable or environmentally friendly.

This scheme seems to be robbing Peter to pay Paul.

<comment><USER3> Yes, more HW would be purchased.

There's much less embodied energy in $1 of chip (especially cutting edge HW where you are covering R&D) than in $1 of energy.

Also once hardware (access to capital much better distributed than access to huge quantities of discounted power) is purchased it's portable and condensed. Much better for decentralization.

<comment><USER13> For existing PoW hardware (even GPUs) it seems like proximity to the Chinese supply chain is more important than capital. I don't see why that would change.

<comment><USER3> For existing PoW, proximity to cheap energy is required before anything else.

</comment></comment></comment></comment><comment><USER14> I'm not sure this theory works. If the opex is sufficiently low, even if the capex is higher then miners would migrate to it as the total ROI is greater. They seem to admit this partway through the paper - "a low energy PoW can be achieved by tailoring a PoW algorithm to a hardware paradigm with a CAPEX dominated cost perhash/trial".

But while they've demonstrated a low-energy way of computing an equivalent hash, presumably this is in no way currently competitive. Therefore this proof-of-concept itself is not an example of an algorithm with capex-dominated costs.

Given that capex versus opex is primarily a matter of accounting (i.e. do I buy a PC, or do I rent a VM from AWS?), I don't understand how that algorithmic distinction can even be achieved. If the ongoing cost of running the device become negligible, then you just incentivise the miners to "spend the saving" by buying more mining devices up-front.

</comment><comment><USER15> Naively, it seems to me that as long as the profit you get out of mining scales linearly with the amount of money you put in, the richest player will eventually control all of the hash rate. Yet this doesn't seem to be the case (so far?). Is my thinking incorrect, if so, why?

<comment><USER16> Why would it? E.g. if mining has a 1% return on investment and there are three actors with 4, 5, and 7 units of hash power, and they reinvest profits into more mining rigs, then a year later they will have 4.04, 5.05, and 7.07 units of hash power---the ratios stays the same.

<comment><USER15> Turns out, I really didn't think this through. Thanks for the correction.

</comment></comment></comment><comment><USER17> They're falling just shy of mentioning which silicon photonics providers we should be buying :)

</comment><comment><USER18> These designed optical chip devices look like alien technology really...</comment>


Lakers most popular NBA team, has the loudest fans; Spurs most underrated - <AUTHOR> http://fanvibe.posterous.com/lakers-most-popular-nba-team-has-the-loudest

<comment><USER2> That is an awesomely visually designed infographic. Well done guys. Complete with the hardwood floor motif! :)

</comment><comment><USER3> Justin Bieber : Twitter :: Blake Griffin : Fanvibe

<comment><USER4> To be fair, Blake Griffin actually IS awesome.

<comment><USER5> I think Bieber fans would contend the same thing.

<comment><AUTHOR> haha that's true too. nice comparison dtran ;)

</comment></comment></comment></comment><comment><AUTHOR> Forgot to mention, this is just for the NBA as All-Star weekend is coming up.</comment>


Ultimately, Banks are 'Big Data' and Technology Companies - <AUTHOR> http://blog.zactownsend.com/ultimately-banks-are-big-data-and-technology-companies

<comment><USER3> Disclosure: I work for one of the biggest US investment banks.

They fed us this line during training, and often senior leaders who left our company would say the same thing when interviewed on CNBC. This is naïve at best though. Banks are only recently starting use "Big Data" (how I love this buzzword), because they have unmaintainable mainframe systems running on LPARs. The reason it's "Big Data" is that as time goes on, the retention of financial data will increase as well. Banks are definitely NOT technology companies, at least as far as the compensation structure is concerned ;)

Don't believe me? Compare any bank CTO to an equivalent position in front office.

<comment><AUTHOR> (I'm the author).

I completely agree with you that currently most banks only pay lip-service to modern technologies, even if they throw buzz words around like crazy. Mainframes, COBOL, etc, are still the standards in many, if not most, large financial institutions.

My point is that when you actually boil down what a lot of commercial and retail banking is to it's core (I would exclude capital markets here, mostly for simplicity) then it's a technology and data problems. It's a technology problem that is surrounded by legacy systems, culture, and regulations.

Ultimately, though, I believe that those banks that can most quickly infuse themselves with modern technology and -- most importantly -- actually run themselves like technology-first institutions, will be the ones that have the most success in the future. I'm not sure any bank is currently doing that, exactly to your point about compensation.

<comment><USER3> I agree with your point on commercial and retail banking. I also agree that if banks pivot in the direction of "technology-first", they will succeed in the future. I'm a bit skeptical (perhaps I'm biased in this regard since I work for one) that they will pivot in the near future though.

</comment></comment></comment><comment><USER4> It really depends on what team you're on. When I worked at a bank, I worked on a pretty competent team. We didn't do anything that important, but it did work pretty well... we had automated tests, continuous builds, and all that good stuff. Most people could open up someone else's code and work on it. (This was largely due to the efforts of one engineer on the team, but you have to give credit to the management for letting him do it :)

At the same time, I would work with other teams, and it just amazed me the kinds of problems they caused. One team worked on streaming data from spreadsheets to other spreadsheets. (Don't ask me why all market data was calculated using spreadsheets.) This was implemented as a set of servers that read from and wrote to a proprietary multicast network that was usually down. It didn't matter, though, because the servers themselves "health checked" each other, and if it detected one was responding too slowly, it would kill and restart it. Except sometimes the killing and restarting caused _that_ server to fail to respond to health checks, so the system basically consisted of servers killing each other all the time. (No, it didn't actually work despite all this. It was a constant source of problems, and was over a million lines of C++! It couldn't even quit without core-dumping because of memory corruption!)

Another team I worked with wrote their application on Java. The company had a policy of only allowing developers to develop on Windows machines, but this team needed to deploy to Solaris. Their solution was to develop and test it on Windows, copy it to the Solaris machines on launch day, and turn it on. But a Windows-only library crept into the core. If this were rocket science, we would not have gone to space that day.

But, there were some pretty good initiatives. One was for a single team to rewrite all software at the bank, in their own C++/C#/Python hybrid, with their own IDE, making all other software engineers obsolete. And despite how crazy that sounds, they actually did a good job! They gave every obscure system at the company a unified API, so a normal user could stitch it all together with a tiny Python program. And write tests for it. It was rough around the edges while I was there, but obviously the way forward. (The big advantage: middle managers had no control over technology, only making a product. So there were no debates ... or rather, horrifyingly bad decisions ... over what servers to buy, what language to use, who would pay for the sysadmins... all they needed to do was design and implement. It was brilliant, and I wish them the best of luck.)

</comment><comment><USER5> This is a really naive view of banks. Big banks, especially investment banks are mostly politics-driven institutes. Technology is important, data is important, but those two are not nearly enough to run a successful institute.

I think everybody knows that who has been reasonably close to people actually leading these institutes. Look at GS, MS or the rest - the CEOs and other top managers are many times coming from the government, and in many cases, ending up in government.

Small hedge funds, prop trading shops are big data/tech companies, that might be true. Even in those cases knowing the market (which means significantly more that knowing the hard data) is of paramount importance.

'Beating the market' is not how these institutions make most of their money. Sales, politics and other kinds of human interaction is a make or break factor.

<comment><USER6> > I think everybody knows that who has been reasonably close to people > actually leading these institutes. Look at GS, MS or the rest - the CEOs and > other top managers are many times coming from the government, and in many > cases, ending up in government.

This doesn't disprove the author's point. The author is pointing out that a lot of technological innovation (eg - ' such as application programming interfaces') is churning inside of banks with no notice to the general public. This point is completely removed from politics and CEOs. The article just points out that there is a lot of software development within banks.

<comment><USER5> > This point is completely removed from politics and CEOs

No, it's not. I happened to see the biggest investment banks' technology departments from the inside (i.e. I worked on very core technologies), and this statements is just simply false. Yes, there's a lot of software development going on, but it's quite a slow-moving animal. They _used to have_ a lot of cutting-edge stuff, but nowadays most of these are superceded by better engineered implementations available to the public. And this is a big struggle for them, the more they've invested in proprietary IT decades ago, the more money they made with it around the late 90's, and the more difficult it is now to move towards industry standards.

<comment><USER6> I've been working at banks and financial institutions for years, and am currently working at a large investment bank and do not agree with you.

Yes, these large institutions have to support older technologies, but they are still creating innovations in the way the author suggests. There are several products out there available to the public that are better than what some banks are putting out, but the products banks are making for their core clients that aren't the general public as very good and relevant to those niche users.

</comment></comment></comment></comment><comment><USER7> I agree, banks and financial institutions are data driven businesses.

I have seen several banks from inside, and most of them think that they are driven by financial analysts, figuring out clever equations for managing money (e.g. lending rules, mortgage policies, etc), while IT is just a cost center for tracking the transactions. It's old school, and they change very slowly.

Sooner or later they shall realize that the transaction data they are tracking is a good source of information, and they could use "hard" data (through some machine learning and data mining), instead of or alongside of the "soft" intuition of their analysts.

</comment><comment><USER8> This is not true. Transaction volume for consumer banking, even including credit card processing, is minuscule - a heavy customer might generate a half- dozen transactions over the course of a day, and many of those (particularly credit card transactions) are able to be asynchronously processed over the course of days or weeks.

Ultimately banks are in the business of money _management_ , not money _tracking_ and have been for the 700 or so years they've been around in recognizable form.

Whether they could do this with less overhead than they presently do with new technology is a separate issue.

<comment><USER9> I beg to differ. In a world of fraction-reserve banking, banks are in the business of capital aggregation and debt issuance - in order to generate all important "spread". But, that world - the world for the past ~700 years - <USER2> disappearing.

We live in a world with collapsing credit spreads and Basel III will tighten them even further. In the US, Dodd-Frank's prohibition on lots of fee based income (which was a huge profit center for banks) and the disappearance of debit inter-change due to Durbin makes banks very concerned about the future of their business.

Banks are increasingly turning to transactional systems to make money.

<comment><USER10> Hi Dan

I have a friend inside Capital One who tells me they're very concerned about the future of the industry. In a nutshell, C1 makes money three ways: (1) debit interchange, (2) net interest margin (NIM) and (3) fees.

Dodd-Frank basically killed debit interchange and fees (esp. with the overdraft changes). If you think spread will keep collapsing, I'm not sure what's left revenue-wise.

</comment></comment></comment><comment><USER11> Good point Zac, It's interesting to see how banks are shifting away from traditional sources of revenue based on trading, balance sheet leverage, advisory, etc into potential new sources that involve the monetization of data more like a traditional technology company. I'm curious if there will be a dramatic cultural shift within banks as traditionally technology has always been viewed as "back-office"...

</comment><comment><USER12> This reminds me of a VMWare acquisition last year of a cloud automation firm DynamicOps. It turns out that DynamicOps was actually a spinoff from one of bulge bracket investment bank Credit Suisse's IT groups. The bank appears to have been quite supportive, complete with venture funding. Quite an interesting story of how tech innovation can come from some unexpected places.

</comment><comment><USER13> It's not only transactions. It's battling fraud. Mitigating financial risks. A boo boo is not that we are offline but also merchants losing money.

<comment><USER14> And a huge damage to reputation as well

</comment></comment><comment><USER10> When I worked at GS a few years ago, they often talked about the "high tech" and "high touch" parts of banking.

You're right that transactional, lower-value activities like basic commercial banking, credit settlement, mortgage origination, etc. are at their core, technology problems, but a lot of banking, especially on the higher, relationship-driven end (private banking, investment banking) is more about customization and individual client service than technology.

Mentioning it because I find that model (tech vs. touch) useful.

</comment><comment><USER15> I've worked at one of the largest Bank's in the US for the last fifteen years, and I pretty much agree with the author. I first discussed this with a co- worker ten years ago and at that time I took the contrarian position but looking back now I think he was right even then. This is a huge shift in culture and focus but its recognized pretty much across the board, even I think by the majority of people who will not be able to adapt and will be left behind.

</comment><comment><USER16> every sufficiently large company is to some extent a tech company.

<comment><USER17> Yes!

But so long as it is merely a means to an end, we don't call them tech companies.

UPS is a shipping/logistics solutions company, even though they have massive Databases.

GM is a car company, even if they write lots of CAD/CAM.

</comment></comment><comment><USER18> Except for the largest banks, all the ones I've seen don't write much original software for their core business - they buy packages and integrate them. They then rely on the vendor for support.

</comment><comment><USER19> This article really rings true for me. I am a software engineer at a then software startup that is now acquired by FIS. When I first started at this small startup it has the makings to be technology based. Then we hired individuals who thought of the business purely from a financial services point of view and slowly killed the culture. It muted it and dulled it's appeal. I wish everyone at standard treasury luck and disrupting this space in a big way.

</comment><comment><USER20> I'm very much not convinced by the idea that banks have technology at their core with a mere wrapping of business functions around it. Having worked for a bank for many years, I'd say it's exactly the other way round.

Management of capital, liquidity, risk, etc. are the true core banking elements.

</comment><comment><USER21> "There, far from the public eye, new technologies – such as application programming interfaces – are allowing financial institutions and businesses of all sizes to interact in new, faster ways."

This "new" technology called API sounds amazing. Everyone should start using it.

</comment><comment><USER22> Ultimately all companies will be technology companies. Software is eating the physical world pretty quickly. Taxi drivers are going to be on the short end of that stick in the next decade or so.

</comment><comment><USER23> Banks as information and technology companies is a great insight. I think we'll start seeing more of this creep into the noosphere as p2p public ledger systems (like Bitcoin) becomes more mainstream.

I think it will also lead to a reforumlation of the concept of currency. Rather than defining and conceptualizing currency as a store of value, it becomes defined and conceptualized as data.

Arguably, the practice of accounting is already treating exchange of currency as data. However, popular concept of money is still tied more with the notion of "value", and emotionally with how much work and suffering one puts up with to trade for a reward. Maybe this popular notion will shift.

</comment><comment><USER24> > ...new technologies – such as application programming interfaces...

In what world are APIs _new_?

<comment><USER25> > In what world are APIs new?

Well, if you consider the whole history of human civilization, they're fairly new.

</comment></comment><comment><USER26> Online financial companies (paypal, stripe, square, kickstarter, etc.) are 0.1% moving bits around, 0.9% ensuring that the moving of the bits is robust, and the rest is a bunch of other stuff. Things like fraud detection and mitigation, relationships with other financial institutions, relationships with sovereign governments around the world, familiarity with relevant laws and regulations, customer service, and so forth.

I can set up a physical bank in 15 seconds. All I need is a shoebox (the vault), a notebook (the ledger), and a pen. And, indeed, in some circumstances this sort of bank is actually appropriate. But at the scale of worldwide commerce it is no more appropriate than a "banking" system that thinks that the software is the most important component.

</comment><comment><USER27> Most of us who work in banking IT, are lured in either by the proported larger salaries, or the opportunity work on big systems, and interesting problems.

The reality is a little less glamorous.

The salaries can be larger than average in some roles, but then again, as you will be working longer hours, your overall hourly wage will be somewhat less. Also, bonus? Interesting. You can work hard all year, deliver, be on track for a nice share of the pie, then bang! Some tard on the desk does a run of bad trades, or worse, hides losses, or the firm gets hit with regulatory fines, then bang - either a small bonus or more famously, a doughnut (zero bonus), with the promise that next year will be better. Just work as hard or harder, and maybe, just maybe, a bonus will come later. Maybe.

If you have ever worked in a competent professional IT setup, your eyes will bleed, your heart sink, your soul evaporate when you are exposed to the full horror of banking IT.

Sybase ASE - you will see schemas with 1000's of tables and many more stored procs - not because they are all needed, but because each one is a sticky plaster fix on the last sticky plaster fix. Oh, and almost nothing gets retired, it just grows like a slow cancer, consuming all that get near to it.

Offshore and nearshore vendor staff will "own" and manage and support the infrastructure, help desk, request system, application support and maybe even more. It will be hell on earth just to get access to one of your application log files to help troubleshoot why johnny-fucked-the-pooch trader tard tries to blame the application for his poor selection of trades.

You will watch so-called partners and peers travel with ease and get what they need, as they work 'for the business', on a business cost-code. You will be on an IT cost-code, and you will need director sign-off for a trip to the bathroom.

In short - the banks need IT, and they are basically fucked without it. But then treat it worse than the department that fills up the vending machine with coke cans each day. The reason is because YOUR management, IT management seem destined to fuck you harder than the business ever would. I never knew people could stand or walk without a spine, till I saw IT management.

<comment><USER28> What you describe isn't restricted to banking. I've never worked in the banking sector, but every software engineering position I've had at a company that wasn't a technology (and specifically a software-driven technology) company was in "the IT department." And "the IT department", even in places where IT has a huge impact on the orderly operation of the business, in my experience has been treated like a necessary evil (at best). I will never work in such a department again because of the shit-tastic experiences I've had in them.

Also your description of IT management in these places as merely spineless is far too charitable, in my opinion. Words that come to my mind are "incompetent, hypocritical, dishonest, creature of corporate politics."

<comment><USER29> I don't think its unique to IT. What you describe can probably fit any role at many companies where the role isn't in a profit center.</comment></comment></comment>


(Android) Developer Income Report #7 - <AUTHOR> http://www.kreci.net/reports/developer-income-report-7/

<comment><USER2> kreci, wanted to thank you for sharing your income with us; it helps everyone else figure out what they are doing right/wrong or at least have a point of reference.

You mix the income reports with self-promotion just right so you get visibility to the things you want to promote (ebook) and give us visibility into the things we are interested in (income).

Also had no idea iStockPhoto brought in any money at all... interesting!

</comment><comment><USER3> Kreci, is your Android market income 100% from ads? I wonder how Polish developers are coping or getting around the restriction of not being able to sell their apps. Your write-ups are always welcome, keep it up. Mile to widzieć, pozdrowienia z za oceanu.

<comment><AUTHOR> Yes it is 100% from ads as I am not allowed by google to sell apps on Android Market. Rowniez pozdrawiam :)

<comment><USER4> Can you share how many daily impressions your ads receive in order to generate that much income?

</comment></comment></comment><comment><AUTHOR> As usual comments are very desired and welcome! =)

<comment><USER5> I hate to be that person, especially as I an a nonnative English speaker myself, but have you considered getting somebody to copy-edit your blog posts?

After seeing the quality of the writing, I would be somewhat concerned about buying the ebook (in addition to the concern I already feel about its tiny size).

Other than that, keep up rocking.

<comment><AUTHOR> It looks I will need to get some English lessons. Thank you for being honest.

<comment><USER6> Eh, I don't think you need English lessons. You can run your posts through <http://polishmywriting.com/> and make adjustments based on that.

Thank you for continuing to share your progress. It makes for interesting reading. I hope you don't stop because of language differences.

<comment><AUTHOR> Great link - thanks!

</comment></comment></comment></comment></comment><comment><USER7> It would be interesting to know what apps you have out there and some numbers. Maybe that's another post though (price, #installed, ad revenue, ad stats..).

<comment><USER8> These appears to be his apps:

<https://market.android.com/developer?pub=KreCi.net>

You can get rough download numbers from the stats on the right-side.

<comment><USER9> As someone else stated, your (kreci's) English needs a little help to be professional grade:

"Trick your friends and show them broken screen... or make them broke it! "

Here you have an incorrect tense ("make them broke it!" should be "make them break it!")

Same for the text on the fart app.

It's understandable but it shows you're not a native speaker. I'm not either, if it helps :)

I still bow to you since you actually made something (rule #1 of enterpreneurship) while I'm still afraid of taking the plunge.

</comment></comment></comment><comment><USER10> Thanks kreci for sharing another income report.

I'm a U.S. college student and I'm looking to make some side income from Android apps. I've already developed my first very basic app, but I'm getting stuck on the financial side of things. I haven't been able to find any good answers to questions such as:

* What do I do about taxes?

* How do I report any income I make?

* Should I put my income in my personal bank account? Or should I put it somewhere else?

* How should I track sales, and what should I keep track of?

I'd appreciate any advice you or anyone else can give.

<comment><USER11> You also might want to pose such questions on <http://answers.onstartups.com/> as well

<comment><USER10> Thanks for the link. Looks like there's already a similar answer: [http://answers.onstartups.com/questions/18629/taxes-for- andr...](http://answers.onstartups.com/questions/18629/taxes-for-android- iphone-developers)

</comment></comment></comment><comment><USER12> Thanks for the information! Do you have a graph that shows the up and down swings of your ad revenue?

Also, I'm not familiar with the stock photo site you mentioned. Is that a site where folks can license out photography?

</comment><comment><USER13> cool, thanks for sharing! keep up the good work and good luck on developing for iOS!

<comment><AUTHOR> Thanks!</comment></comment>


How have you prepared yourself for emergencies? - <AUTHOR> Yes, I mean "prepping", which doesn't have to entail a bunker full of guns and ammo. It could just mean being ready for small natural disasters, or extended unemployment.<p>I have about a month's worth of shelf-stable food and water for my family. I have some cash savings on hand. I have basic first aid supplies. I have some relevant outdoor gear like water filters and headlamps. I have blankets and warm clothing such that my family could likely survive winter without heating. <comment><USER2> sadly my planning for unemployment was drastically underdeveloped, in fact the only thing i really have preparations for are medical emergencies, due to my mistrust of doctors i like to ensure im able to treat as much as possible so i have meds like amoxicillin, metronidazole, dexmethasone, morphine, diazepam, modafinil plus a few others and the usual OTC meds along with various bandages and basic surgical equipment.

other than that i have a few options for off grid power in case of extended periods of power loss</comment>


1m views of your company's blog: 5 simple tips - <AUTHOR> http://www.rockinrobin.co/blog-eng/corp-tips

<comment><USER2> Upvoting mostly because I'm interested in HN discussing this.

<comment><USER3> Agree. I'm into local communities like StartupDigest – good way to get first traction for startups</comment></comment>


Microsoft apologizing for IE6 - <AUTHOR> http://buytaert.net/album/drupalcon-chicago-2011/microsoft-apologizing-for-ie6

<comment><USER2> I'm not sure that IE6 was the problem; was it really that much worse than Netscape 4 or IE5?

I think it is more that Microsoft didn't update their browser for such a long time after releasing it, resulting in a large percentage of users having an old browser (which wasn't updated like others to implement standards). That is what Microsoft should be apologizing for.

<comment><USER2> Why did this get downvoted? I'm not trolling, and if I'm wrong I'm interested in hearing why. One of the other three posts seems to be saying a similar thing, too.

I'm comparing against IE5 and Netscape 4 since those were browsers of the same era and neither was all that great in following standards either and they of course don't support newer standards created over the years. Wouldn't web developers be complaining at similar levels if a large percentage of users were still running Netscape 4?

Also, I'm pretty sure the poster is referring to IE6 the browser rather than Microsoft's Internet strategy around that time since it says that "IE9 is better".

I think my point behind making the distinction is that IE6 developers should not feel any shame; it was a decent browser for its time; Microsoft IE management (or perhaps MS upper management) from the time immediately after IE6 release hold the blame.

</comment></comment><comment><USER3> It'll take more than one drink...

<comment><USER4> I also think everyone knows why IE9 is better. It's better because it supports things that Google Chrome supported when it first came out.

Funny thing is... IE6 was not the problem, it was the overall strategy, which is why I can't trust MS for anything. So IDK if a drink will do. Maybe a hit of E + a bit of ganja to make me feel more relaxed about it... maybe... Control The Rage!</comment></comment>


Looking for recent python bayes mcmc post - <AUTHOR>

Hi, recently ran across a great python bayes mcmc post.  This was a few weeks ago in March. If anyone can recall this, can you post the link?<p>thanks <comment><USER2> [http://jakevdp.github.io/blog/2014/03/11/frequentism-and- bay...](http://jakevdp.github.io/blog/2014/03/11/frequentism-and-bayesianism- a-practical-intro/) perhaps?

<comment><AUTHOR> no, but jakevdp is a great blog, and er.. that is some relevant info i should incorporate so thanks!

but i remember just scanning, it had a dark background and had many plots of mcmc output - sort of looked like a splom plot.

thanks for that link though anyway

\--anyone remember this</comment></comment>


I'm closing up shop, what should I open source? - <AUTHOR>

Hello!
I operate http://www.robots-everywhere.com and have decided to close up shop due to lack of attention/demand. What should I opensource, and where?
The software can go on github or the like, but what of the hardware designs? Is Thingiverse appropriate for stuff that can't be 3d printed? How about the electronics designs? <comment><USER2> There is a chance that Github does not support data files. They recently depreciated binary files.

[https://github.com/blog/1302-goodbye- uploads](https://github.com/blog/1302-goodbye-uploads)

<comment><USER3> Note that the post was written in 2012, not 2013. Despite not having external binary downloads support anymore, you can now upload binaries with releases. Read more at [https://github.com/blog/1547-release-your- software](https://github.com/blog/1547-release-your-software)

</comment></comment><comment><USER4> Hmmm... that's an interesting question. I think you could probably put designs and schematics and what-not on Github as well. It might make the most sense to do that, so everything will be together, in one central location.

<comment><AUTHOR> I'd actually like to open everything except for the NASA stuff, which I don't think I can open, and the NAVCOM bombing logic which I've excised from the program and am not going to ever release (I can't think of any peaceful use for a $1500 bomber drone, sorry).

<comment><USER5> water balloons.

</comment></comment></comment><comment><USER6> Just put everything raw open and see if people would do that work for you?

<comment><AUTHOR> I'm cool with that -- I don't know WHERE. As above, looks like github is a no go. I am primarily an embedded developer, a lot of the software only makes sense if it has specific hardware to go with it.

</comment></comment><comment><USER5> not sure how big your files are but I have a domain name called openrobotfactory.com that could be good for your designs, etc. my email is email@example.com

<comment><AUTHOR> Thanks, I emailed you!

<comment><AUTHOR> And got no reply :(Thanks for adding to my depression.

</comment></comment></comment><comment><USER7> You could look at bintray for your binaries.</comment>


Making daylight saving time permanent could reduce crime - <AUTHOR> http://www.washingtonpost.com/news/wonkblog/wp/2015/10/29/the-case-for-year-round-daylight-saving-time-just-got-billions-of-dollars-stronger/ <comment><USER2> I've always lived far enough north that the difference in daylight between summer/winter is very significant. In June, the sun is up at 5:30 in the morning, and doesn't set until after 9. In the winter, it's sometimes not light by 9AM when I go to work, and it is pitch black again by 4:30. It doesn't help that it is cold as hell at the same time that it is dark all the time.

My sleep cycle tends to be very sunlight dependent, so I'm seriously dragging all winter, since my body wants to still be asleep when I have to get up, and by the end of the day, I'm already shutting down. Daylight savings time screws things up even more - turning the clocks back in the fall isn't terrible, but those first weeks in the spring are _brutal_.

</comment><comment><USER3> And yet other research says we should start studying/working later. Can't have it both ways.

[http://www.theatlantic.com/education/archive/2015/08/why- sch...](http://www.theatlantic.com/education/archive/2015/08/why-school- should-start-later/401489/) [http://www.theguardian.com/lifeandstyle/shortcuts/2015/sep/0...](http://www.theguardian.com/lifeandstyle/shortcuts/2015/sep/09/why- you-should-start-work-at-10am-unless-youre-in-your-50s)

<comment><USER4> Better off just abolishing it. It's also been linked to more car accidents and such. If you want to set summer hours, fine, do that, but it's just silly to play with the clock to do so.

<comment><USER5> There's no meaningful difference between _abolishing DST_ and _making DST permanent_. It's really just a question about whether you'd permanently like a little more sun in the morning, or the afternoon.

In the Northern city that I live in, in the winter, a permanent DST would be preferable. We're already in the preferable situation 8 months of the year. No reason not to just extend it the other 4 months, permanently.

<comment><USER6> You do realize that the amount of hours of daylight one gets in one day is an immutable property of the rotation of the earth?

Calling 3:00 pm "Four O'clock" does not magically make the day longer, nor would it give you more sun in the afternoon.

<comment><USER7> Yes, people realize that. Usually people must conform to societal norms which require one to do things at a certain time, which may not be synced with the natural time.

</comment></comment></comment></comment></comment><comment><USER8> It's possible that the 2007 DST extension reduced evening crime because sunset was still late enough for the difference to matter. I'm not sure that will remain true all winter. That is, even if DST ran all year, in the depth of winter it might still get dark early enough for the street criminals to come out between 5 and 8 PM.

The link (near the bottom of the article) about how DST causes problems for farmers is baffling. Surely if any enterprise should be run on solar time rather than clock time, it's a farm! Why can't they just adjust their schedules so the DST change is irrelevant??

<comment><USER9> > Why can't they just adjust their schedules so the DST change is irrelevant??

Because it's known to be bollocks. Lowest grade quality article.

</comment></comment><comment><AUTHOR> > Most street crime occurs in the evening around common commuting hours of 5 > to 8 PM

Instead of mucking with Time, which we may later find out have some 'unintended' consequences, why not businesses, schools and workplaces change their open and work hours? This will change the timing of the "commuting" hours and spread over longer duration potentially also reducing the rush hour traffic issues.

<comment><USER10> >Why not businesses, schools and workplaces change their open and work hours?

It's far easier to legislate DST than to to regulate every business, school and workplace. In Indiana, DST and Time Zones are already political sore spots. There would be absolute revolt if they attempted to tell everyone to change the time they operate and everyone certainly wouldn't do it of their own volition.

</comment></comment><comment><USER6> Stop playing games with time. Instead of year-long daylight saving time, I'd rather we stick with standard time all year long.

<comment><USER11> Invariably when I am trying to setup some kind of international conf call I cant help but think that communication would be easier without timezones. Imagine the ease of coordinating world-wide tele-meetings if everyone just understood and used UTC. Yes technology often uses it under the hood, but if used it societally things would be so much simpler.

<comment><USER12> Though then you're just swapping that for the problem of remembering stuff like "Is 2am GMT a good time to call Japan?"

<comment><USER13> Japan will be around +10 hours, so it's 12h – sure, noon.

Remembering which country is where is standard in school, roughly estimating timezones from that is easy (US varies from -8 to -4, most of europe is 0 or +1 or +2, as is most of Africa, Russia is +3, middle east is around +3 and +4, china is +8, just like singapore and japan; australia, new zealand are between +10 and +12; I have no idea what the actual data is, just saying what I remember based on knowing the world map)

As everyone knows GMT, and everyone knows the world map, the issue is solved.

</comment></comment></comment></comment><comment><USER14> > In 2007, Congress increased the period of daylight saving time (DST > henceforth) by four weeks, adding three weeks in the spring and one in the > fall. "This produced a useful natural experiment for our paper,"

My knee-jerk reaction to reading this is that their paper's conclusions must be based on a single observation.

</comment><comment><USER15> Call me a traditionalist, but shouldn't 12pm be when the sun is directly overhead? (by definition)

<comment><USER16> Time zones already mean that's not true.

Pretty recently there was a post (I think here on HN) that shaded the entire world to show how far off from 12pm they are when the sun is directly overhead. There were some pretty serious gradients on a lot of time zones (where the left edge is far off in one direction and the right edge is far off in the other direction). And there were a lot of time zones where the entire zone was offset in one direction.

Unfortunately I don't remember enough to find that post again.

<comment><USER17> Think you probably mean this map - [http://blog.poormansmath.net/the-time-it- takes-to-change-the...](http://blog.poormansmath.net/the-time-it-takes-to- change-the-time/)

<comment><USER16> Yeah that's the one.

</comment></comment></comment></comment><comment><USER18> And when people get used to it, shift the time forward by another hour?

This makes as much sense as those people who set their clocks forward by 15 minutes so they aren't late.

<comment><USER19> It doesn't, because the numbers of time have an independent meaning that people follow that is unrelated to the sun, which is the entire reason that daylight savings time even works: people don't just ignore it and work 9-5 this week and 8-4 next week even though those are the same natural times.

<comment><USER20> One interesting consequence of this is that the further west that you look within a timezone, the less sleep people tend to get.

> Examination of ATUS activity logs shows that workers experiencing earlier > sunset also go to bed earlier and that this correlation between sunset and > bedtime persists even if the worker goes to bed well after dark. Coordinated > work start times translate this earlier bedtime into longer sleep.

Time Use and Productivity: The Wage Returns to Sleep, Matthew Gibson and Jeffrey Shrader

</comment></comment></comment><comment><USER21> If it were up to me North America would only have two time zones, and no DST.

I stopped changing my clocks years ago and I've never been happier.

I'm on the west coast and I set all of my devices to "Phoenix, AZ" time zone, which is Mountain Standard Time year round (or Pacific Daylight Time year round). Most calendar software works fine with multiple time zones. Set your appointments in Pacific Time, and they're shown in Mountain Standard Time.

There's really only 3 weeks of the year where mornings are unusually dark. The interesting thing is I naturally wake a little later during the dark mornings, and naturally wake a little earlier as the mornings become lighter. I enjoy it.

I don't have to deal with the shock of losing an hour sleep in the spring, or the shock of the sun suddenly setting at 4:50 PM in the fall.

The only negative is that Colbert is on an hour later than normal for a few months.

<comment><USER22> How do you communicate with the rest of the world? Do you often make the mistake of setting a meeting up an hour off, and are you ever an hour off from other people's expectations?

<comment><USER21> For formal appointments, you use your calendar software and enter your appointments in the local time zone. The software will automatically convert a 3:00 PM pacific-time appointment to your preferred time zone (Mountain Standard Time).

For informal appointments, you get used to "7:00 PM your time, 8:00 PM my time" for the 4 months. In rare cases you may get it backwards and you're off by two hours, but those errors are usually caught quickly.

The only time it's a real problem is when someone on the street asks you the time and you don't realize that you've put them off by an hour until you've walked away.

<comment><USER23> I'm not clear how any of this benefits you directly.

<comment><USER24> Daylights savings time is a fiction and I refuse to be ruled by it.

<comment><USER25> But your solution only works if you have a flexible schedule. You say, "I don't have to deal with the shock of losing an hour sleep in the spring," but that's only because, presumably, there isn't a manager standing at your desk at 9 a.m. wondering why you are showing up to work an hour later than everyone else all of the sudden. People aren't ruled by Daylight Saving Time, they're ruled by schedules.

The actual number doesn't matter at all -- I go to sleep at 11 p.m. in whatever time zone I'm in because it's about 8 hours before I need to wake up and jump into my schedule. Saying "11 p.m." is really "10 p.m." doesn't change the fact that I'm 8 hours away from waking up.

</comment></comment></comment></comment></comment></comment><comment><USER26> I made an IPython notebook awhile back exploring the advantages and disadvantages of various DST proposals for my lat/long (you could download and plug in your own). (Please forgive the attempts at humor in the notebook, they were sloppy).

[https://github.com/avdempsey/IPython- Notebooks/blob/master/D...](https://github.com/avdempsey/IPython- Notebooks/blob/master/Daylight%20Savings/Concerning%20Daylight%20Savings%20Time.ipynb)

</comment><comment> nommm-nommm Canada changed their DST hours to coordinate with the US a few years later. Is there any data of this type from Canada?

</comment><comment><USER27> Wouldn't it be better to increase the timezone by one, and abolish DST, so that it wouldn't be so confusing?

<comment><USER5> In what meaningful way are these two acts any different?

</comment></comment><comment><USER28> Could? Are we playing with statistics again? Yesterday I learned on HN that you're 8x more likely to be killed by a cop than by a terrorist. This also turns out to be the same odds as being killed by your furniture.

[https://h4labs.wordpress.com/2015/10/29/youre-8-times- more-l...](https://h4labs.wordpress.com/2015/10/29/youre-8-times-more-likely- to-be-killed-by-a-police-officer-than-by-furniture/)

<comment><USER29> Well, if you actually look at the article, they, for example, find a statistically significant 7% drop in robberies (with up to 27% in a specific hour).

<comment><USER30> That's nothing -- if you _do_ observe daylight savings time, you'll see a 100% drop in crime (and everything else) during one specific hour.

</comment></comment></comment><comment><USER31> There's no such thing as permanent daylight savings time. The point of daylight savings time is to shift everyone's routines forward during one section of the year, and backwards during another.

If you don't shift, and the new times are fixed, then people will get used to it and just move their routines back 2 hours. People will treat new:6:00 as if it's really old:5:00, because it is. Nothing will change besides the numbers on paper.

<comment><USER10> I don't follow. How are people moving their routines back 2 hours? Shops aren't changing their hours and my work starts at the same time. I don't do anything according to the sun, I do everything because other people are doing that thing at that time.

<comment><USER31> I meant 1 hour. But anyway that is the point of daylight savings time. The actual time doesn't change, just the number on the clock. Causing everyone to move their routines back 1 hour, so that they have more sunlight in the afternoon. Daylight savings time would work just as well if everyone decided to go to work from 8-4 during half of the year, and keep the clocks the same.

<comment><USER10> How do you propose getting all workplaces to change their schedules to 8-4, nevermind the places that don't run those hours? Legislation? This solution keeps coming up and the practicality of it seems nonexistent. Any legislation of business is riddle with exceptions, there would be end to them for such a move as changing working hours.

<comment><USER31> What are you talking about? I never suggested that was a good idea. I just said it would have the same effect. I was trying to explain the purpose of daylight savings time, because you didn't seem to understand it. My original comment was just saying that "permanent daylight savings time" is nonsensical.

Since you bring it up, I do find it absolutely horrifying that we rely on the government to mandate that people miscalibrate their clocks once a year. Instead of businesses and stuff doing the right thing and moving their schedules back so people can have more afternoon time. But unfortunately that's the world we live in.

</comment></comment></comment></comment></comment><comment><USER32> Am morning person. Must not be a criminal.

</comment><comment><USER33> Can we just go ahead and put the clocks forward 3 or 4 hours then? Mornings are not worth living anyway, and we could have glorious evenings where the sun sets at 8pm in the winter, and at midnight in the summer. Wouldn't that be lovely? :-)

<comment><USER34> Seems like China.

</comment></comment><comment><USER35> The article seems to be making a lot of assumptions. For example another explanation could be that crime is just seasonal.

People who are less well off would probably be able to survive on less during summer when they don't have heating costs. Or maybe they're just in a better mood.

<comment><USER36> "[The increase of the period of daylight saving time by four weeks] produced a useful natural experiment for our paper," authors Jennifer Doleac and Nicholas Sanders write at Brookings, "which helped us isolate the effect of daylight from other seasonal factors that might affect crime."

<comment><USER35> Ah ok, it seems I skimmed over that bit! That makes it more interesting.

</comment></comment></comment><comment><USER37> This is why we can't have nice things.</comment>


Growing a Compiler (2009) - <AUTHOR> http://www.cs.dartmouth.edu/~mckeeman/cs48/mxcom/gem/html/GrowingCompiler.html <comment><USER2> This made me find and read "Growing a language"

[https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf](https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)

"In a race, a small language with warts will beat a well designed language because users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language fills a niche, it is hard to take its place."

<comment><USER3> This should be in the preface to the Rust Evangelism Strikeforce Field Operations Manual.

<comment><USER4> Nah, you haven't _really_ avoided success at all costs until you've evangelized a committee-designed functional language with pervasive laziness.

</comment></comment></comment><comment><USER5> An interesting approach! But old META II (mentioned in the original article) system and its derivatives are looking more practical to me. I think, it's more effective to have two simple DSLs, one for parsing and another one for tree transforming like it was done in Cwic and TREE-МЕТА, which are grew from original META II (self-described in a few lines of code).

</comment><comment><USER6> The amount of JS bashing here is so high. Pretty much any popular language fits the given description. Humble yourself and read about why your language of choice sucks: [https://wiki.theory.org/index.php/YourLanguageSucks](https://wiki.theory.org/index.php/YourLanguageSucks)

<comment><USER7> Please don't do programming language flamewars here.

We detached this subthread from [https://news.ycombinator.com/item?id=14435298](https://news.ycombinator.com/item?id=14435298) and marked it off-topic.

<comment><USER8> I'm may be mistaken, but I interpret jamescostian's comment as "every language has some problems, let's stop this sort of discussion". May you intended to detach the parent comment ?</comment></comment></comment>


Free Client for OneDrive on Linux - <AUTHOR> https://skilion.github.io/onedrive/ <comment><USER2> Been using this for months with mixed success. Used to crash all the time but ever since the last update the bugs seem to have been worked out. Great project

<comment><USER3> Sounds great! Tells me that it works exactly as the Windows version!

<comment><USER4> Well, this is a command line interface so it's not exactly the same. However, it's quick and easy and scriptable so it definitely gets the job done on Linux.

</comment></comment></comment><comment><USER5> 1\. Written in D, neat!

2\. If I get a functional OneDrive client for Linux before a functional CLI GoogleDrive client for Linux... I just feel like that says something. And I've used the other "community-provided" GDrive clients and have had problems with all of them.

<comment><USER6> > 1\. Written in D, neat!

Maybe I'm just the outlier, but I was curious about D until I learned that it was a proprietary language, and not run by the community. At that point, I just left it dead and moved on.

I'm not trying to shit on this project, but I know I would find it troublesome contributing to a project like this, when it's not even certain if I can get the compiler running on my Linux-distro of choice...

<comment><USER7> It is run by a community. The reference compiler isn't fully free, but GDC (compiler with GCC backend) and LDC (compiler with LLVM backend) are free/opensource.

<comment><USER6> While there are open compilers, how about the language design and how that evolves?

Is that also handled by the community, or do Walter and Andrei still rule supreme here? Control of the language is IMO much more important than control of a single compiler.

</comment></comment></comment></comment><comment><USER8> Nice to see people using D.

Why a Makefile instead of Dub?

Also why disabling the bounds checking? Have you proven with a profiler that it really produces a noticeable impact for the user?

</comment><comment><USER9> Too bad Onedrive for Business is not supported, I have 1TB storage provided by school.

<comment><USER10> It really sucks that the OneDrive for Business is a totally different setup. It's like reinventing the wheel rather than just enhancing login options but that's all on MS's side. :/

<comment><USER11> It's a result of two completely different teams creating a project at the same time, so the backend (at least in the past) were completely different. IIRC, onedrive for business originally used sharepoint on the backend, not sure if that's still the case. I'm sure someone from MS could enlighten us.

What I _DON 'T_ get is why they don't just pick a winner and move everyone's data over to said winner.

<comment><USER12> > IIRC, onedrive for business originally used sharepoint on the backend

Yep, it's still sharepoint on the backend.

</comment></comment></comment></comment><comment><USER13> Looks good. I'm going to give it a try.

Though I am probably going to bite the bullet and start paying for something with full built in encryption. Obviously this will cost more as Google, OneDrive, etc. take a loss on the storage costs, making it back via data mining, ads, and product upsells.

The proverbial final straw was Windows 10 slide-showing personal pics hijacked from my phone on my start menu at a client site. Who knows if it would happen on the lock screen, too, since they've turned Pro edition, even, into a conumption and ad platform instead of a business class OS.

I have told Android OneDrive to NOT auto upload pics from my phone a least a dozen times, yet it still gives not a shit.

<comment><USER14> You can disable the Photos app Live Tile, so it wont show your pictures on Start

</comment></comment><comment><USER15> It's good to see people use D where it shines. Congrats.

<comment><USER16> I'm a c-sharper and I wanna learn D. It looks nice. But where does it shine?

I'm looking for a language, preferably c like, that optionally has pointers and with a good support for HTTP.

<comment><USER8> You get to have a C# like language that compiles to native code and offers today what System C# did (which will never be available outside MSR walls) for systems programming.

Plus it has lots of metaprogramming goodies, without the C++ SFINAE craziness.

However it does have the caveat of using an old GC implementation and not much GUI related tools are available.

But for CLI or server side applications on UNIX, if you don't want to wait for CoreRT to become available or not found of Mono AOT, D might be worth a try.

</comment></comment></comment><comment><USER17> Really nice. I don't program with D but the code is readable. OneDrive, purchased as part of Office 365, is a great desl.

<comment><USER18> It's a curly-brace language with similarities to C/C++/Java, not surprisiing you can understand a lot of it. There's not much in the way of interesting algorithmics going on either; it's what I'd consider "business logic" code that mostly consists of function calls. In fact the code looks quite Java-ish.

</comment></comment><comment><USER19> rclone ([http://rclone.org](http://rclone.org)) supports one drive too and runs under Linux.

Like this tool it doesn't support One drive for business though. Microsoft have made it very difficult for open source programs to use one drive for business as far as I can see. It has the most complicated registration procedure I've ever seen - even Microsoft admit it is too complicated!

<comment><USER20> It's because OneDrive for business is a completely unrelated tool under the hood with no relation to OneDrive except a deluded manager somewhere feels responsible for both.

Same with Skype and Skype for Business.

<comment><USER21> i'm not sure about the manager. skype for business doesn't have pretty much anything in common with skype except the name and icon...

<comment><USER22> Even the executable is still lync.exe for Skype for Business.

</comment></comment></comment></comment><comment><USER10> Well, time to test this out and see if it really is as smooth as advertised but if everything configures right, this might enable me to go back to the 1TB that I get through my work savings.

</comment><comment><USER23> Nice too see an alternative for linux since OneDrive is probably has the best pricing out there. I used to be an SpiderOak customer but has switched to OneDrive since it's better in several ways and half the price for the same storage.

It's nice to have auto-upload for my photos taken on my phone. I wish SpiderOak made their client simpler to use since last time I tried it was kind of confusing GUI even for me as a programmer.

<comment><USER24> OneDrive doesn't do file versioning, which makes it useless for backup. Get a ransomware on your PC then watch in horror as your cloud storage is useless for recovering your files. SpiderOak may have a clumsy UI, but it keeps historical versions of your files. Dropbox keeps versions for a month and they have an add-on for a year. Even Google Drive keeps versions for a month. OneDrive is basically the poorest choice you can make.

</comment></comment><comment><USER25> And of course it comes from Microsoft because Microsoft loves Linux!

<comment><USER26> Like (or even more than) countries, corporations have no feelings, they have interests.

Microsoft is now mainly interested in being in Oracle's shoes. I would not be surprised if next year they had a Microsoft Linux, like Oracle has had an Oracle Linux for years now.

(What I would be surprised about is if next year there's an Xbox Two. That's probably the next part of the remaining consumer space to feel the cold.)

<comment><USER16> They went from XBox (0) to 360 to 1. Why would the next number be 2? It should be 4, no?

</comment></comment></comment><comment><USER27> Why would you want to use a cloud storage service that has blatantly lied to their customers?

[https://blogs.office.com/2015/11/02/onedrive_changes/](https://blogs.office.com/2015/11/02/onedrive_changes/)

<comment><USER28> I don't know why people keep offering "unlimited" plans on anything, when they should know that someone will keep pushing it until they find out what the limit ought to have been.

<comment><USER29> It makes sense for some things, when measuring it would be more trouble than it's worth. The first website I ever made was hosted by a two man garage company that offered unlimited* bandwidth.

Even if you've got a measuring system in place, it helps figure out what would be a reasonable limit that works for 99% of your users.

*as long as you don't negatively affect other users.</comment></comment></comment>


What's the Difference Between Contractor and Consultant and FTE? - <AUTHOR> https://ozar.me/2015/06/whats-difference-contractor-consultant-fte/ <comment><AUTHOR> […] either a generalist or a specialist doesn't dictate your employment status as a contractor, consultant, or full time employee. However, generally I find that generalists are FTEs or contractors, and specialists tend to be […]</comment>


Nginx server not safe against ldos | feedback from sys admins? - rudhir-secpanel http://blog.crackerhost.com/?p=223

<comment><AUTHOR> Editorialized title on HN? According to article text served by the Google cache says he did this to Apache first, then someone specifically requested a test against Nginx. Those of you saying "it's not Nginx, it's the OS" are definitely correct, please at least acknowledge that the tester/author isn't being completely duplicitous.

<comment> rudhir-secpanel Thanks for you 'vote' :). I have responded to the issue of nginx vs os

</comment></comment><comment><USER2> Attack description and analysis: [http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/TCP- sh...](http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/TCP-shrew.pdf)

I agree with andrewcooke, it doesn't seem to be a problem of nginx or apache. OS TCP implementation should be modified to handle this type of attacks.

</comment><comment><USER3> why would it matter what the server was? isn't the attack against the TCP/IP stack? (low rate DOS fools TCP's flow control into over-restricting transmission afaict).

<comment> rudhir-secpanel the attack was done with slow http traffic. the delay effect on an apache server on the same os(centos) was different than was on nginx(again on centos). also i have been able to control the attack by focusing on the web server - apache or nginx.

</comment></comment><comment><USER4> From the page summary on Google:

LDoS = low rate denial of service (I didn't know, did you?).

Now the article doesn't load, anyone has the text?

<comment><USER5> Google cache link: [http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.crackerhost.com/%3Fp%3D223&hl=en&strip=1)

<comment><USER4> Thanks

</comment></comment></comment><comment><USER6> This article is misleading. as Andrewcooke and jsn point out, this is not about web servers, it is about TCP/IP traffic. For a technical forum such as this, it is appreciated when the underlying causes are enumerated. This comes across as marketing with inadequate technical detail.

<comment> rudhir-secpanel Thank you for your comments. I am always learning and take this opportunity to do that as well from someone with a better insight and experience.

On the specific points raised here, please go through:

<http://lwn.net/Articles/338407/>

Given above is also a similar(not the same) kind of attack, which can bring down an apache web server.

Quoting from this link, "It is not entirely clear which web servers have the means to defend against the attack, but there is general agreement that there is no way for Apache to completely defend against it, and that IIS is not vulnerable to the slowloris technique."

Also quoting, "Obviously, this is an application level attack. In their book on Internet Denial of Service, Mirkovic/Dietrich et. al noted that application level DoS is difficult to handle: "[...] many defenses are not able to help you defend against this kind of attack".

So we are back to what the Apache Security team concluded: This is an inherent problem for servers. If you want to serve, then you have to accept clients, and, if they intend to block you, so be it.

But, let's not give up so fast. Obviously, if the well-known proprietary alternative from Microsoft, IIS, is not affected by this problem, there are other solutions. What IIS does differently, is in the way it handles incoming requests: There is no static tie between a worker thread and a network socket in IIS. Rather, the workers are organized in a pool where they wait for incoming TCP packets (rather than TCP connections as Apache does). These packets are then assigned dynamically to threads. So, an idle connection occupies a socket, but it does not block an entire thread. Thus the web need not be shut down by penny-wielding customers or slowloris. "

If all that the attack has to do with is TCP/IP and has nothing to do with the (type of) web server, it should bring down an IIS server as well. No? Then why is that not the case, above?

1\. Any denial of service attack will have to be about connections and therefore tcp/ip. Is that what I missed mentioning? But that is not what this is about. 2\. Even http also belongs to the family of tcp/ip 2\. The point here is that the attack takes advantage of the way apache or nginx treat connections. It is not a simple tcp/ip flooding. 4\. What was it, again, that I am marketing, here?

</comment></comment><comment><USER7> Honestly looks like there are no real good solutions to this yet.

<comment> rudhir-secpanel we have been working on this and have had some success in detecting and stopping an attack. would be glad to share more details, if you want

<comment><USER8> Go ahead.</comment></comment></comment>