HN user
My friend once told me that physics formulas are like compression algorithms: a short theory can explain many data points that fit a pattern.
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.
Note that there are quite a few ways that crypto implementations can be insecure even if it's proven to be "correct" (in terms of inputs and outputs). For instance, it may leak information through timing, or by failing to clear sensitive memory due to a compiler optimization.
Sincere question about communism:
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?
Longjmp is used by Postgres for transaction aborts. With C, there's not really a better option available.
"It is our responsibility to chose the right tool for the job."
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.
Simon was one of the first people I met in the Postgres community, perhaps in 2007 at the first PGCon that I attended. We've attended many of the same conferences in places around the world, and I've occasionally had the chance to explore those places with him. He was always kind to me and helped me immensely. I was proud to have the chance to co-author a major feature with him. The last time I saw him was this past December.
Very sad.
What are the barriers to doing so?
"Plus, you don't give out your secrets to fabs, too."
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.
What are some killer apps for FPGAs? What major products do they enable?
It works. Bugs have been found, and some more bugs probably exist, but I think it meets a fairly high bar of quality.
Postgres is designed to recover on OOM in most cases.
Part of the theory is that abstract thought enables culture, and culture enables much faster adaptation than genetic evolution. But still far from instant.
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.
I happen to be reading Sapiens right now. The author seems convinced that we genetically developed the ability for abstract thought (which he calls imaginary or fiction), and that allowed us to cooperate much more easily in large numbers. For instance, believing in a particular flag allows you to identify your allies on the battlefield without having ever met them before. The theory goes that other animals, including other hominins, genetically lack the hardware to rally around a flag.
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.
Do you believe it was designed and standardized as a reasonably implementable feature?
It looks like Ada 2022 has a way to track at compile time whether functions block or not. Seems cool for async programming.
setjmp/longjmp exist in a lot of real world C code, so there is a lot of value in allowing rust to deal with longjmp in a defined way at least in some narrow cases.
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.
I'd be happy if there were a way to always unwind when a longjmp() happens, regardless of whether there are !Leak types on the stack.
The article addresses this: "However - and this is the big, enormous caveat of this section - this would rely on the compiler effectively implementing some kind of unbreakable firewall, to prevent a type that does not implement Leak from ever getting used with pre-2024 code."
Why do you say they'd have to be splattered over basically all rust code? The post compares them to Send and Sync, and I don't have to use those very frequently (though I don't write a lot of rust code, either).
The Leak trait could be interesting when it comes to C code that calls rust code that calls C code that might longjmp() over the rust code in the middle.
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.
Postgres has a free space map, which allows it to reuse the space of deleted tuples for new or updated tuples created in the same table. If no new/updated tuples are created in the table after the DELETE, you have fragmentation, which means the file remains large so the space can't be used for other tables (or other unrelated data residing in the same filesystem).
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.
What is the larger issue here? Why is this significant?
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.
"Enough profit they can fund efforts to tilt the system in their favor."
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.
If you depend on the company making the chemical to do studies and be transparent about them, of course the reaction time will be bad. You need independent studies and environmental monitoring.
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.
If the chemicals are bad, and everywhere, we need a reaction time faster than 50 years.
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.
"Ford will make a zillion dollars on electric trucks, they did the obvious thing and Musk couldn't get out of his own way in needing to create the unnecessary and unwanted just to do something different."
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.
"There are no real world natural keys — only someone else’s surrogate key... SSN, VIN, email address, UPC, tax numbers, country codes, language codes, URIs… they’re all just someone else’s made up identifier."
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.
Regarding framework in general (I have 12th gen): I'd like a full-size SD card expansion card for trasferring photos.
Other than that and my 12th gen is nearly perfect. A few really minor things that are probably software issues.
If the fundamentals of the course change, shouldn't that be a new course? If the previous course existed, would that still be worthwhile for some students even if most move to the new course?
Is the difficulty switching from SWI due to tooling issues or because source code changes are required?