jeff-davis
If that's true, then perhaps AIs would come up with something just by looking at existing observations and "summarizing" them.
Far-fetched, but I try to keep an open mind.
Let's say hypothetically that the distribution of stock ownership was more even across the population, and variance was largely (but not completely) due to length of time in the workforce. And further, that the stock owned by workers is a large enough block that they effectively have controlling shares at many companies. Maybe I'm talking about a different universe, but please imagine it for a moment.
Would that hypothetical world be kind of like communism in the sense that the workers own the means of production? If not, why not?
That perspective doesn't work well for database products, in my opinion. There is a huge pressure for databases to evolve with your business and applications and to adapt to whatever your throw at it.
Swapping out a database product is less like changing tools and more like changing a foundation. You can't do it every time a new problem arises.
That's not to say you can't use a few different products if that makes sense. But that has its complications.
Very sad.
That's a perfect answer to my question, thank you.
Also many other great answers in this thread, but I don't have much to add.
So maybe the abstract thought hardware was there for a long time before we got culturally coordinated enough to use it with full effectiveness to organize large groups capable of outcompeting Neanderthals.
This also led to the notion of a shared culture across many individuals that can adapt much more quickly than genetic evolution.
(Unless I misunderstand, of course.)
The author squarely blames Homo Sapiens for wiping out the other hominins, pointing out how many other large species seemed to go extinct as soon as we arrived someplace new, even long before the Agricultural revolution.
And I don't think it's impossible -- it probably requires some special wrappers (perhaps bindgen could generate them?) that would call setjmp before entering the C code. setjmp has its own set of problems, but I don't believe those are impossible to solve, either.
Right now longjmp()ing over rust code is not a great idea for a couple reasons, but because leaks are currently always allowed in rust, it arguably follows the rules at least in some cases (doing so could cause problems, of course).
If the Leak trait were introduced, then skipping destructors would be clearly the wrong thing to do if there are types on the stack that don't implement Leak. That would clearly require some way to either prevent longjmp() from ever jumping over rust code (e.g. always catch it in C code and turn it into a special return code), or find some way to catch the longjmp and turn it into an unwind in rust (e.g. a panic?) and then turn it back into a longjmp to go back into C.
The nature of fragmentation means that you need to move a lot of data around to actually make that file smaller. In Postgres, that's typically done with VACUUM FULL. The problem of fragmentation is not unique to Postgres, it's a fundamental issue; but perhaps other systems are able to move the data around in a less disruptive way.
If you just delete a column, that creates a different type of fragmentation within the tuples themselves (e.g. you delete the middle column, and the tuple itself doesn't shrink, it just ignores that middle column). You are right that can be a problem. Postgres could be improved to rewrite tuples to eliminate the wasted space from deleted columns in the middle, which would probably be (computationally) worth it to do if it's already performing cleanup on the page.
It seems like a fine point within trademark law. It maybe sorta kinda has implications for parody speech? But even there, it doesn't seem like a major threat to parody speech unless I'm missing something.
That might explain things in the US, but worldwide?
Why didn't some other country at some point run some studies, call some cabinet head in the US and say "Why are you spraying this chemical on everything? Don't you know it's kinda bad? We're restricting imports of stuff with that chemical unless it's really needed.".
"The Supreme Court..."
Congress needs to do its job and stop blaming SCOTUS for federal law interpretation and regulatory scoping issues. (Constitutional law is a different story because Congress can't do anything about that.)
Politicians optimize for shouting loudly about things, and then blaming others when they do nothing.
The blame game gives the politicians and bureaucrats a nice excuse for inaction, and not much else. And 50 years later it just looks ridiculous.
Sure, if someone does something bad, blame may be a part of the response. But you need good outcomes first and foremost, not bad outcomes and blaming.
For new inventions (not well-known issues), it would be far better to be fast-reacting and no-fault rather than slow-reacting with vengeance.
Run studies as the use of the chemicals scales up and start raising warnings early so the company has time to collect more information and adapt formulas or applications. As the costs become apparent, start placing those costs on the companies ahead of time rather than 50 years later. That will sort out who really needs the new chemical, versus who just wants to spray it everywhere.
Negativity aside, isn't that what startups and HN are about? Do something new, see how people react, and iterate/pivot.
Perhaps this attitude has no place in the auto industry, and it should all be incremental changes. Then again, perhaps it does.
Every time this topic comes up, there are major definitional problems, and it seems like either surrogate keys or natural keys get defined out of existence.
The author is drawing the line such that natural keys are surrogate keys that are out of your control, and surrogate keys are in your control. That doesn't seem to match the definition from wikipedia: https://en.wikipedia.org/wiki/Surrogate_key
I agree with the author that control over the ID is an important distinction, but if you're going to make up a new ID, why not just say so? "Surrogate key" just introduces confusion -- it makes it sound like something only programmers and database admins care about, which is definitely not true. If customers are seeing it, everyone in the organization should care that it's in a recognizable pattern (so you don't mix up different IDs from different places) and memorable and easy to understand when spoken.
Other than that and my 12th gen is nearly perfect. A few really minor things that are probably software issues.