Hacker News new | past | comments | ask | show | jobs | submit | 00098345's comments login

I have to disagree with Hoare sensei there. The number is nowhere near a billion. I personally know of one case that totaled to a billion.


Would love to learn more about this single billion dollar mistake


SQL summation without coalescing null addenda to zero. The sum result was a null. This had been going on for years. Oops!

The lesson/mitigation was to add a NOT NULL attribute on top of a DEFAULT 0.


Hoare was talking about null references specifically. Or, to be even more precise, making references nullable by default, and allowing all operations on them in the type system, with U.B. or runtime errors if they actually happen.

NULL in SQL is a very different and largely unrelated concept. Though probably a mistake just as bad - not the concept itself even, but the name. Why did they ever think that "NULL" was a smart name to give to an unknown value? For developers, by the time SQL was a thing, "null" was already a fairly established way to describe null pointers/references. For non-developers, whom SQL presumably targeted, "null" just means zero, which is emphatically not the same thing as "unknown". They really should have called it "UNKNOWN" - then its semantics would make sense, and people wouldn't use it to denote a value that is missing (but known).


Sounds like this could have also been mitigated by either the SQL server warning about SUM() operating over a nullable column or a "where foo is not null" clause. Your solution is best, though.


This is good but please, to preserve your own sanity, first design the table struct properly to capture all attributes you can think of in separate columns and add the appropriate primary key. Then add the extra JSON(B) column for unforeseen data. Keep iterating till the table is still small.


You will never think of all the attributes anymore. For example 8 months later you want to score your contacts based on derived or imputed values. Who knows what you will want to slap in there when you scale up to 5 billion rows and start including click data from your website for example... there are basics from relational concepts that are obvious, which is why you are using postgres in the first place but table structure is not one of them.


"I might want to add more columns later" is not a good justification for avoiding a relational model. If you realize that you want an additional column, just run an ALTER TABLE statement.


Totally agreed. Some people have an unreasonable fear of migrations (not to try to put words in the above poster's mouth, just pointing out something that I've noticed). You generally shouldn't worry about migration-related downtime with Postgres if you're not using table constraints, using columns with defaults, or changing a column's type. There are very few migration procedures that require something like a table rewrite these days, or even an index rebuild.


Migrations are a pain in the arse. But not as much as trying to maintain a "schemaless" app.



While that solution is cool for preserving shape across all slices, it was clearly postulated by theoreticians.

An experimentalist would point out that pizza components have a radial dependence (Ie, crust on the outside), so it's not actually equal slicing in practice, and the traditional sector slices are really the most optimal ;-)


Operation success; patient died.


Not necessary because this is realised to a certain extent through safety standards. Certified earthquake proof. Done.

Now, in this case, FDA approval should include software standards that prevent this scenario. Done*.


Earthquake certifications are just like other certifications, in that most of the process is not actually reviewed by any government agency. They check blueprints, sign off on the process, but they don't actually make sure that the ibeams are connected correctly and that the angles are just right. Done.


The founder, Sridhar, is on here: https://news.ycombinator.com/user?id=sridharvembu

Very talented and humble guy.


It is interesting that Mr. Landis mentions entropy (in Thermodynamical sense I hope). I have always wondered what it means here, in this solar system. Assuming the solar system has negligible energy flowing in, what does it mean when life on earth is reducing entropy in this system? We are tipping the balance by assimilating atoms in a more orderly fashion with each birth. This means something bad is happening somewhere close-by. ;-(


What 'balance' are we tipping? There is no balance. Entropy increases globally over time. You do not cause bad things to happen by locally decreasing entropy temporarily. You might interpret this as indicating that life is meaningless over cosmic time scales, but it doesn't mean something 'bad' is happening anywhere.

Our star is slowly dying, and we feed on its remains. Our feeding is not the cause of its death, however. It will die anyway.


The amount of entropy within the solar system, or on the earth is fairly constant. Also, amount of information represented biological order is pretty trivial compared to the whole.

But yes lots of entropy is going somewhere else anyway. The sun is flinging a lot of entropy-bearing photons out into the universe. Its internal heat source then makes more entropy to replace it. For now.


Each act of "assimilation" and order as you put it, by definition requires energy and produces heat.


The current understanding of waves on a liquid surface is attributed to a clear boundary between two fluids with a density difference and a velocity gradient. Gravity plays no role in this.

Kelvin-Helmholtz instability: https://en.wikipedia.org/wiki/Kelvin%E2%80%93Helmholtz_insta...


Two fluids with a density difference and a velocity gradient usually have a common force acting upon them, e.g. gravity, which enforces so-said interface. Perturbations to the average interface are restored via this force, and these perturbations are called gravity waves.

KH Instabilities give rise to gravity waves.


Security on bare metal OS is a hard problem.

Square or cube that to get an idea of security in virtualization.


You are approaching from the wrong angle. How much was the exploit "worth" to the company?

Some people want to watch the burn. An attacker could make it known anonymously and LastPass will never recover from that onslaught.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: