by

I only skimmed the article, so maybe they said this, but for choosing from a small range, for example 0..51, you can get several of these from a 32 bit random number with this algorithm

https://stackoverflow.com/questions/6046918/how-to-generate-...

You should be able to run a 64 bit PRNG once and pick at least 8 random cards from a deck.

From personal experience, this is absolutely correct and still a major problem which needs solving. The nurses in hospital will keep a fluids-in fluids-out chart constantly logging their best estimates. Outside hospital this will not happen. Lack of fluids can be fatal. I would not be surprised if this was proven to be a very common cause of fatality for people with dementia. Even in hospital fluids-in fluids-out may not be recorded accurately - the measurements require more human effort and continuity of care than is likely to be available. (It is always best for people to be enabled to do things, for example drinking and eating, for themselves if possible, and this can take a long time.)

My guess is that fluids intake could be tackled to some extent by a measured drinking device. The difficulties are spillage being counted as consumption, simple and safe operation for people with lower cognitive, physical and sensory abilities, the need for hospital-level cleanliness of the device, and of course cost. I do not know why we do not have devices like this when people can die from lack of fluids.

A less obvious way technical people can help is to test the accessibility of their products. A device with a black button on a black background, or which in some other way obscures its controls and functions, is a failure in this respect. Make all the functions visible, easy to understand and easy to operate. Test websites with automated tools like https://try.powermapper.com/Demo/SortSite

This would be good to build into the windowing system so it could apply to any application. Split any application window horizontally or vertically and put the two parts where you like on the screen.

The .COM domain has always been international in nature, not a country domain restricted to the US. See the extract of RFC 1591 below. Or have I missed something?

It is fairly clear that .US is for US companies, .COM is international commercial, and the .GOV and .MIL domains are restricted to the US.

RFC 1591 (March 1994) http://www.ietf.org/rfc/rfc1591.txt

"Each of the generic TLDs was created for a general category of organizations. The country code domains (for example, FR, NL, KR, US) are each organized by an administrator for that country. ... These administrators are performing a public service on behalf of the Internet community. Descriptions of the generic domains and the US country domain follow.

Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States.

World Wide Generic Domains:

COM - This domain is intended for commercial entities, that is companies. ...

EDU - This domain was originally intended for all educational institutions. ...

NET - This domain is intended to hold only the computers of network providers, that is the NIC and NOC computers, the administrative computers, and the network node computers. ...

ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. ...

INT - This domain is for organizations established by international treaties, or international databases.

United States Only Generic Domains:

GOV - This domain was originally intended for any kind of government office or agency. More recently a decision was taken to register only agencies of the US Federal government in this domain. State and local agencies are registered in the country domains (see US Domain, below).

MIL - This domain is used by the US military.

Example country code Domain:

US - As an example of a country domain, the US domain provides for the registration of all kinds of entities in the United States on the basis of political geography, ..."

"The length of the randomly generated salt shall be at least 128 bits."

nist-sp800-132.pdf http://csrc.nist.gov/publications/PubsSPs.html

Not quite the same application, but it would seem best to take a conservative approach and make your salts 128 bits because the storage required is so small - you are only storing one per username.

My theory is that un-released software is like physical inventory. Keeping inventory is very expensive because the money spent could have been earning interest elsewhere and product sitting in the warehouse becomes gradually obsolete. As you accumulate a great deal of software inventory towards the end of a big project the cost of keeping the inventory, and therefore the pressure to complete the project, naturally increases. Shipping small increments frequently and not keeping much software inventory is the most efficient process if the product design/market allows. (I'm not saying this is always possible or would have been appropriate in this case, just making a comparison.)

Maybe I did not phrase that well. What I was thinking was not to give your premium accounts away free, I agree that would devalue your product, but that you could get free advertising by posting details of your product in places where the community will be interested. Places where there is a high concentration of people who would benefit from your product. I do not have particular sites to suggest, you will need to do some extensive Googling. My experience was getting some nice links to something I did by applying some effort to find people who were particularly interested in the subject. Do not think I am an expert, I was just throwing in some small ideas.

Try to find places where there are people who would benefit from your product.

Post free links to your site on non-spammy relevant places. If you get creative this should produce a nice set of inward links and a bit of traffic.

Look at your competition. They probably have relevant expertise. See where they advertise and are listed.

No. The police possess a great deal of stolen property. The entire police force would collapse into a blue hole if they had to arrest everybody in possession of stolen property. The crime is knowing it is stolen and having no intent to return it.

It's called traffic analysis

https://secure.wikimedia.org/wikipedia/en/wiki/Traffic_analy...

That depends on how you define 'active'. A quick Google gives me some Facebook published statistics [1] which say that more than 250 million people log on every day. Goldman Sachs seem [2] to say "600 million+ monthly active users".

[1] http://www.facebook.com/press/info.php?statistics [2] http://www.businessinsider.com/facebook-has-more-than-600-mi...

"In any case that value was unrealized assets, so it's not like they actually had $36B in cash"

I could equally say that if they liquidated that $26B quickly they would get less than that. I would hope the $36B and $26B were fair estimations of the asset value at the time.

That is trivial compared to the $10,000 million the Harvard endowment fund lost.

http://www.bloomberg.com/apps/news?pid=newsarchive&sid=a... http://www.nacubo.org/Documents/research/2009_NCSE_Public_Ta...

The things we should fear are myocardial infarction [1] and cerebrovascular accident [2]. These are what will probably kill us in developed countries [3]. The good news is that we know how to prevent many of these deaths: regular exercise, not over-eating, not smoking and moderation in alcohol and drug consumption. Other causes of death and ill-health are also reduced by these actions.

[1] http://en.wikipedia.org/wiki/Myocardial_infarction [2] http://en.wikipedia.org/wiki/Stroke [3] http://en.wikipedia.org/wiki/List_of_causes_of_death_by_rate...

Yes, you are quite right. I should have done that.

Sorry, I misunderstood. I thought you were supporting a 'rage is sufficient reason to attack people' position. My counter-example was intended to show clearly that rage can be entirely unreasonable and inappropriate and to disprove a general statement that 'rage is sufficient reason to attack people', which glorifies rage and anger over logic and reason. But we were missing each other's points I think.

"The harshness of the lesson was proportional to the amount of rage such behavior induce."

Let's consider the logic of that statement by taking a different example. A young child is in a shop and is told by its parent it cannot have some candy. Young child "I want candy! I want candy!". The child becomes enraged, more and more enraged, by the behavior of the parent. Should the child now teach the parent a harsh lesson? Since the parent's behavior has induced a great deal of rage a very harsh lesson seems entirely appropriate.

The article does not make it clear that to make a submission to the review itself you should see this page

http://www.ipo.gov.uk/ipreview/ipreview-c4e/ipreview-c4e-res...

the survey they are asking you to complete is submitted to Coadec whose agenda is here

http://www.coadec.com/?page_id=225

Please don't shout in uppercase in the titles. The guidelines are here:

http://ycombinator.com/newsguidelines.html

I realise the original article uses this title, but a little more peaceful when posted to HN would be nice.

It is very poor security to teach your users to enter their passwords on HTTP pages. Even the small minority of technical people who check the page uses HTTPS when it posts the form do not check it every time they use the page.

Why doesn't Data.PVector.map increment the last element from 14 to 15?

    ghci> adjust succ 2 a  -- apply a function to a single element
    fromList [1,42,14]

    ghci> Data.PVector.map succ a  -- apply a function to all elements
    fromList [2,43,14]

"scientists, engineers and tech folk are able to abstract the description of a high-trauma event .. and describe it in such matter-of-fact terms."

Here is John Hamilton who made that remark:

http://web.jcsb.org/Trans/index.htm

What evidence do you have that he is a scientist, an engineer or a tech folk?

You talk about password collisions. I am only considering salt collisions.

Their system had many holes, one of which was the salt length. I did not mean that the salt length was the largest hole, nor that it was the one that was exploited. Just that it is a hole which could have been exploited if the others were absent.

The salt's only purpose is to prevent a password hash result being used more than once. The normal attack is to pre-compute and store a table of passwords and hash results by running lots of common passwords through the algorithm in advance. The salt needs to be large enough to prevent anybody storing a pre-computed table which has a chance of matching a result in your database. The salt also needs to be large enough that your own salts do not collide because this would reduce the work needed to crack the ones with salt collisions.

It is a salt collision not a hash collision. No, clearly one would not matter, hence staying below that would be entirely safe against a salt collision inside your database.

But if it was feasible to store 10^32 rainbow tables you should make it longer. Ah, it should probably be longer. I think 128 bit salts would be more sensible.

It's called the Birthday Paradox

https://secure.wikimedia.org/wikipedia/en/wiki/Birthday_para...

the rule of thumb to remember is that there is a 50% chance of a collision when the sample size reaches half the bits of the total available.

Curiously I see an example of duplicates with slightly different points. Maybe something is not enclosed properly in a transaction and the list is being generated partly before and partly after an update has been applied.

On the 100 points version I see:

27. The only script in your head (headjs.com) 248 points by timf 12 days ago | comments

28. The only script in your head (headjs.com) 247 points by timf 12 days ago | comments

"Balancing portfolios is basically a universally recommended practice."

The 'balancing' is against a stock market index which will seriously over-represent a particular geography, industry sector, business size, asset class etc. Why choose that index? Because the stock market tells us to?

"If you manage your own portfolio,"

I was considering how to make a 'passive' index fund even more passive.

"won't you have a similar "churn rate" to the index fund?"

An index fund would have a higher churn rate and therefore higher costs than my theoretical fund, but I do not know how much money an index fund spends on index-following sell-buy transactions.

My theoretical fund would have a wide range of stocks. It does not seem to be related to spreading gains or risks.

I have not seen any comparative table of stock churn rates for different funds, but my guess is that index funds do well because they reduce the sell-buy transaction costs, partly by eliminating the cost of human stock pickers, but primarily by reducing the percentage of stocks in the fund that are sold then bought every year. Maybe this is wrong?

My understanding is that an index fund sells and buys stocks to balance the proportions held in the fund as the market capitalisation of the companies changes inside the index. This imposes an apparently unnecessary cost on the fund. If we removed this cost by not selling and buying stocks to keep it equal to the index would the fund become more profitable? I am considering it to be a fund where people invest incrementally over a long period so there would be constant random aquisition of new stocks from the index.

Maybe that doesn't make sense for some reason.

Index funds seem to me to work by reducing churn - the percentage of your stock that is sold and bought each year - because every time you sell then buy you lose a lot of money. I am not yet convinced you have to follow an index.

If you had a fund that did not sell anything and bought a random stock from an index as funds came in would this beat an index fund?

As a Mercedes it sounds like this:

"There's not much point lamenting about how your Mercedes could be appropriated in ways that you don't like.

If you are worried about that then your only option is to refrain from parking it in public places.

Otherwise the golden rule of the road applies: When it's out on the road then it's out on the road - and there's no taking it back."