skysight-inc/HackerNews huggingface dataset:
I faced problems with flaky unit tests that used a common unit test database for the whole project. Since all the tests ran at once, the tests would sometimes fail because of concurrency issues. I never got the time to look too deeply into it.

I wonder if there's a database that works sorta like git, giving one "commit" point at the start of every test and then "branching off" so each test can do its own thing, make transactions, commit them, whatever, and finally be able to roll the whole thing back.

If that can be done then each unit test can use a full database clone with actual valid data and not just test data that was fast enough to set up before the test ran.
> Everyone should start doing this. Once the AI companies engorge themselves on enough garbage and start to see a negative impact to their own products, they'll stop running up your traffic bills

Or just wait for after the AI flood has peaked & most easily scrapable content has been AI generated (or at least modified).

We should seriously start discussing the future of the public web & how to not leave it to big tech before it's too late. It's a small part of something i am working on, but not central. So i haven't spend enough time to have great answers. If anyone reading this seriously cares, i am waiting desperately to exchange thoughts & approaches on this.
The problem with this approach is that SQLite dialect is not the same as most production setups. Even if you use an ORM you often have manual queries or you are using a feature that is only supported in some databases (like geospatial queries)
I trust that he made millions betting against the market back then.
I think the point is comparing 2 different things. VSCode with a helper daemon running on the server, and Emacs not configured to run as a daemon on the server side, accessing the server via SSH and scp.

I am not sure how the speed of both compares, if one properly sets up Emacs on the server as well, to make it a fair comparison.
> and it's a different idea than decoding multiple instructions in a cycle and sending them to one of many execution units (which is usually just called "dispatch", though "out of order execution

Being able to execute multiple instructions is more properly superscalar execution, right? In-order designs are also capable of doing it and the separate execution unit do not even need to run in lockstep (consider the original P5 U and V pipes).
I've had good experience with testcontainers (https://testcontainers.com/) to do that sort of thing.
I encourage you to read what a TPM is. A TPM isn't an "encryption" software/hardware. It's completely orthogonal to "successful open source encryption software".

"successful open source encryption software" don't solve the main usability problem with encryption: "Where do I store my super secure 4096-bit private key so it's both secure and convenient to use"
Here is the NY Fed household data statistics on the subject. The NY Fed reports quarterly on US credit and debt. Aggregate delinquency rates going up.

https://www.newyorkfed.org/microeconomics/hhdc/background.ht...
I think one helpful thing is what rails calls transactional tests (https://guides.rubyonrails.org/testing.html#transactions). It basically does the database setup (migrations and seeds) and then executes the tests in a transaction that is rolled back at the end (and thus never committed). This helps with speed and also ensuring that tests don't have as much accidental codependence as they might otherwise.

If you use read replicas in production code this can become tricky though since the transactions don't commit they never become visible to the reader or even different connections to the same database
Unfortunately there are many examples of fraud on the part of practicing doctors. The insurance companies (whether private or government) can't just pay for whatever the doctors say they want to do.
How textiles made from plastic took over the fashion industry
Vampire hedgehogs, pirate spiders and fishy fungi: strangest new species of 2024
Was dealing with mocking voodoo garbage this morning as a result of fixing a bug. What a horrible mess just to claim a few lines of "test coverage" while ignoring critical db functionality. I wouldn't mind if the mocking frameworks weren't absurdly complex in their own right.

Unfortunately our "integration" tests are even worse, corrupting data all over and flaky as hell.
Undeterred: Energy firms pursue Mozambique projects despite massacre report
Don't know what language or database you use, but check this out: https://github.com/peterldowns/pgtestdb

If you happen to use Postgres, the approach is ultimately portable: it uses Pg database templates (also, regarding perf, the author recommends using a ramdisk and turning off fsync on your test DBs; you'll see this in the project readme). But you’ll have to write the code yourself.
I'd bet Melon Husk hasn't played D&D in years … I doubt he'd be able to even find a table that didn't bow to his every whim.

Honestly, the "species" thing has bothered me for years. I'm not sure I'd agree with divorcing physical traits completely, but that's easy enough to house-rule, as is everything else about the game. I feel sure that anyone getting upset is doing so performatively, not because it's actually a problem.
Starting each test in its own transaction and then rolling back at the end, and ensuring no 3rd party network calls in application logic in rails and Postgres apps have worked with a lot of success in my experience.
I believe it. Happened to me once or twice when I was making under 50k/yr over a decade ago.
You might not understand how precarious many people's spending habits are. After all of your bills and necessities are paid, many people only have a few hundred dollars per month spare. So if you get $2,000 popped in your lap, that might be the equivalent of 9 months of fun time money for them.
Maybe it's different for you, but I don't think any three letter agencies have some kind of TPM backdoor (they don't need to with how often TPM chips end up being vulnerable to common software exploits, the firmware being written in unsafe languages and all). If a government was going after me with enough force to use their TPM bypass trick, I'd probably be in jail for years on fake allegations regardless of encryption status.

TPMs work great against things like common thieves and probably corporate espionage, if set up well. When implemented well, they provide no additional friction (except for having to store a recovery key somewhere) but all the security against a laptop being stolen at the airport you could wish for.
> what would send all the criminality to that province?

Nothing would "send" criminality there, over time any place joining the USA would become the USA, and by definition it would become the average of the USA (because it will be a part of the USA)

A lot of people like to think a place will become the USA in all the perceived "good" ways like higher potential salaries, lower income taxes, more freedom, etc., but they fail to realize a place will also become the USA in all the ways that make the USA so vastly different from every other developed nation (healthcare, education, violence, crime, etc.)
Like others, I think this is a solution describing an idealised problem but it very quickly breaks down.

Firstly, if we could accurately know the dependencies that potentially affected a top-level test, we are not like to have a problem in the first place. Our code base is not particularly complex and is probably around 15 libraries and a web app + api in a single solution. A change to something in a library potentially affects about 50 places (but might not affect any of these) and most of the time there is no direct/easy visibility of what calls what to call what to call what. There is also no correlation between folders and top-level tests. Most code is shared, how would that work?

Secondly, we use some front-end code (like many on HN), where a simple change could break every single other front-end page. Might be bad architecture but that is what it is and so any front-end change would need to run every UI change. The breaks might be subtle like a specific button now disappears behind a sidebar. Not noticeable on the other pages but will definitely break a test.

Thirdly, you have to run all of your tests before deploying to production anyway so the fact you might get some fast feedback early on is nice but most likely you won't notice the bad stuff until the 45 minutes test suite has run at which point, you have blocked production and will have to prove that you have fixed it before waiting another 45 minutes.

Fourthly, a big problem for us (maybe 50% of the failures) are flaky tests (maybe caused by flaky code, timing issues, database state issue or just hardware problems) and running selective tests doesn't deal with this.

And lastly, we already run tests somewhat selectively - we run unit tests on branch uilds before building main, we have a number of test projects in parallel but still with less than perfect Developers, less than perfect Architecture, less than perfect CI tools and environments, I think we are just left to try and incrementally improve things by identifying parallelisation opportunities, not over-testing functionality that is not on the main paths etc.
The Kalash language is a mix of the languages found in the region- Tajik, uzbek, tartar, persian, etc. But, there are Greek words for woman, washing, winter, greetings etc used among the several Kalash tribes that are Greek. While even that can be explained under the PIE theory, your statement of 'absolutely nothing to do with Greek' does not stand.

But further study- genetic and archeological- is necessary.
This is a good thing to be aware of when choosing a database, but I think most of the time people just reach for Postgres because it's the "standard".
I've seen a db mock work when 1) there was a small subteam in charge of the OR-mapping, schema structure, and included a DBA; and 2) also a design policy from the architect that all objects had to come out of factories. Under those specific circumstances, having the mock - used solely as a per-developer object cache imitating the factory interface - was critical for unblocking the people working on business logic and front-end.

I wouldn't structure a team that way now.
> You're subsidizing those wages with your tax dollars.

Under your proposal I'd be paying even more tax dollars to those rendered unemployable.

> It's not the case that they wouldn't employ people.

People who produce less value than they cost become unemployed.
I don’t know. Like any other tool, it depends on how you use it. I worked for a unicorn with presence in multiple countries and they were using Mongo as main db in multiple microservices. Around 1500 engineers. It worked fine. I’m not saying it was justified, but never had perf. issues.
Yeah. His storyline was supposed to track the original series much more closely, but filming got shut down for covid, and the actor didn't come back when it resumed. Deleted all his socials, etc. Didn't take any more work until just recently, too.

No one knows what the deal was - lots of people speculated it was vaccine requirements when it was announced, but filming resumed before vaccines were available, so that couldn't have been it.
> There is a duty of care to properly investigate when people die.

Yes, usually every death is already investigated and run by a medical examiner. This is a proper amount of investigation, unless there is evidence to support a more extensive one.

> When there are many suspicious deaths, even moreso

Is there any evidence linking this death to the others you mention, and any consensus that all of them were suspicious, other than in your personal narrative of events? I have seen neither.

> Have you dealt with government workers before? Do you know any of them that would re-open an investigation on their own from submissions from an independent person that shows they got it wrong (egg on face)?

Obviously they wouldn't (and shouldn't) do it if you didn't have any evidence showing that the previous conclusion was wrong, and I have not seen any presented here.

> What would convincing evidence even look like to spur the necessary action after an investigation has been closed solely based on a medical examiner's report?

I've answered this twice, once in each of the above posts, suggesting what direct, non-circumstantial evidence might look like. A conspiratorial, self-serving personal narrative, conflating unconnected events, unfortunately isn't that.

> You are talking yourself in a circle, where overwhelming evidence that isn't quantifiable must be present before investigation, when such evidence can only be acquired in an investigation

This is actually a circle that you are talking yourself in. Things like search warrants can't be granted on the basis of 'another person [out of billions] also took their own life a while ago while under stress, that seems sus to me', and that doesn't sound like a good justification for focusing resources, either. What, then, are you proposing a new investigation should do?

Have you seen any direct, non-circumstantial evidence? Witnesses? Videos? Communications ordering a hit? Documents discussing it? Anything like that?

I haven't. And unfortunately you did not answer this question previously, so now it must be re-asked. I'm genuinely asking here. Maybe I missed some direct, non-circumstantial evidence. You mentioned something about blood, could you please [link] us to what you're talking about there?
Another software engineer chiming with QModem being one of his childhood core memories. Sorry for your loss.
There may not be a legal obligation, but there's still a moral obligation.
But it's just so much fun you never want it to end!
The election is over, we stop pretending that the market is doing bad.
Transaction per test is how that works in ruby on rails. Also, the rspec parallel gem will create N test databases for running tests - one per process.
One thing I like about the new rules: they let users create their own unique species/class combinations, without feeling like the game's rules are limiting you.

For example, a Barbarian gnome or Half-orc wizard can be fun choices from a role playing perspective, but suboptimal in combat or gameplay. Removing species-specific ability score increases lets players create non-standard combinations without weakening the party.
China-backed hackers breached US Treasury workstations
That's true in every neighborhood - everyone has that one neighbor who doesn't take care of trash, has problems with rats, etc.

We keep trying to signal out people without housing as different, but it's never true. It's just the house that's missing.

> we have to get them off the street and I'm pretty sure the only way for that to happen is through oppressive policies.

Who cares if you think something is an eyesore? Maybe you're an eyesore to me; can I arrest you? Your words are much more obnoxious and dangerous than the unhoused person you describe; can we jail you? Only oppressive policies will work.

You'd better start standing up for human rights and freedom before it's too late. Oppression is a crime against the rule of law and human rights, not a policy.
Dupe the database. That's what I do in one of my test suites (though that's in part because the tests happen across 4 different processes so it's just not possible to keep it within one transaction).

Creating a db from a template is not free, but if there's not too much stuff in the db it's not horrendous either. And if you're using sqlite, you might be able to backup an on-disk template to an in-memory test db.
+1 for US & India.

I put in a quote request with the lab OP used, the economics might work out but we'd run into the problem of people sharing the insights/outliers on social media?

Also side note, this test seems exorbitantly expensive in India. $1100 for 1 kit!
https://www.amazon.in/Phthalates-Test-Bus-Days-Schneider/dp/...
It's not OT at all. It depends on what you mean exactly by LLM, but we use them all the time. ESMFold2 was an LLM [https://www.science.org/doi/10.1126/science.ade2574] and was instrumental in advancing deep protein fold prediction in metagenomic space. Likewise AlphaFold2 it's direct application in creating FoldSeek for ultra-deep homology search. Both of these actually have radically improved our capacity to say Obelisks are _REALLY_ not like anything that's known.

Besides that I encourage all students to use ChatGPT for research, coding, copy editing, etc... I haven't encountered an LLM that can deal with difficult domain problems like we're facing, but I'd welcome the help. I'm for using all tools available, my main criticism with AI/LLM in general is the poor way in which uncertainty is reported.
They didn't even figure out unified memory - even original xbox (20+ years ago) had that.
Yeah I don’t get it honestly. This is a tech enthusiast forum isn’t it?
I used MongoDB at a company where engineering policy was strictly that MongoDB was our only allowable database, including in cases where it was clearly not the best choice.

Were there good aspects? Sure... kind of. It was super super easy to just throw data into the database. Need to add a field? Who cares, just add it. Need to remove a field? Who cares, just remove it -- as long as the calling code is null-safe. And it was likewise super easy to store denormalized data for fast lookups when it made sense to do so, as well as deeply-nested things and arbitrary JSON blobs synced from our CMS. And queries could be stored and manipulated as actual Python dicts instead of opaque strings, whereas you normally need an ORM or query builder to do that in SQL. And you could get the best-of-both-worlds-ish with the ODMantic framework, where you could spit out a warning (but not an error) and recover gracefully if there happened to be bad data in the database.

Basically it allows you to forego any foresight or serious design, and instead just throw shit together. Which is great for getting a prototype going really fast and giving the appearance of a highly productive team. That is, until you run out of new microservices to prototype and now you have to start adding features to existing code and fixing bugs. IMO it was completely "penny-wise and pound-foolish" with respect to developer time, but I can at least see the appeal if you're a particular type of engineer operating under a particular set of incentives.

As for using MongoDB for things it was actually meant for (writing a ton of schemaless JSON blobs really fast and figuring out reads later), I have no idea because we never used it for that and had nothing really resembling that use case.
Mark All as Read
Does something like PGlite work for your use case? https://pglite.dev/
I worked full time on a pretty seriously-trafficed product based on MongoDB for 3 years and I still don't know of anywhere I'd want to use MongoDB. I'd basically always want either a DB with a schema or a super fast opaque-store style cache.

Also, their hosted offerings (MongoDB Atlas) were not well operated and they took down our company for 2 days. Our MongoDB instance stopped accepting new connections and restarting our instance via their control panel didn't bring it back up and then their support literally said "we don't know why this happened or how to fix it" for like a day and a half, while we were on their highest tier ultra platinum support contract. Ultimately, we had to do 24 hours of research and then tell their own support how to fix the problem using their special shell access. If I recall correctly, it was some issue with WiredTiger (an internal component of the Mongo version we were using).

After that experience, I'd never use anything produced by MongoDB for anything; we moved everything that we possibly could out of Mongo and into more traditional RDBMS (PostgreSQL) and never had to deal with issues like that again.
Same, I use bitwarden and it keeps all my passkeys in it and is available on all my devices.
That doesn't work if you need to commit for one reason or an other. And while in some cases you might be able to substitute subtransactions via some sort of test mode, it's not always an option depending what you're doing / testing exactly.
“ That's my biggest issue with it.”

Those are your words. They literally agree with the OP’s position on free speech. You then go on to state that you don’t like what people say, even though you are lamenting the lack of free speech. You’re a contradiction with a hyper aggressive view of others: calling others “psychos” says more about you and your small minded attitude to others than it does about the people on Bluesky.

So you don’t like what people say. Who cares? Either put up with it because you believe in free speech or stop lamenting the lack of free speech on Bluesky.

And then maybe consider how you view others. Having an opinion of people being psychos just because they don’t align with your worldview is the mindset of the extremist
Testing against a real database is an example of integration testing. Using mocks is for unit testing. Ideally, you want to do both. Unit testing entails isolating particular components for testing which is important because it let's you be more precise in what exactly you're testing. Using mocks also makes it easier to run automated tests because it means you don't need to have a database or credentials handy during the build process.

Integration testing is also important because the closer you get to running things in a production environment, the more likely you are to detect issues. Some things just won't be apparent until you start running code in production or near production. The thing to understand though, is that you want to do both if you can, not either-or.
If only BeyondTrust was called LeastTrust, it might not have used a global key to gain access to a load of very high-value targets.

To be fair though, most of what we use in these companies is a stack of containers of stuff that we just assume works properly, securely etc. and we don't really know if we use e.g. Citrix or VMWare or BeyondTrust or whatever, whether the software works as designed and whether it was only as secure as the people who wrote the code.
> If you’ve been through the experience of having anything and everything gradually stolen out of your yard and car if it’s not bolted down, with the police not giving a flying F about your loss or the problem systemically,

I've been through the experience of being homeless. I have some opinions about the degree to which the police cared about my problems too.

I once stole a tarp out of a yard in the face of an incoming blizzard I was hoping to survive. My sympathies are never going to be with the yard guardians here.
We had some pretty bad performance with $lookup queries but it all magically went away after adding some indexes. I have a lot of grievances with teams that use MongoDB, but relatively few grievances with MongoDB itself along these lines.
It's not a honeypot, and it does have value when used properly.

Their main purpose is to generate and store keys that cannot leave the device, instead performing signing operations as needed internally and only returning the result, and only if attestation passed. This is a lot better than just having private keys on disk.

People just forget that security isn't absolute, and each solution has a threat model it is appropriate for. In case of full disk encryption, neither a TPM nor user input can protect against evil maid on its own for example - the TPM will unlock for anyone, while user input might be collected by a modified and malicious bootloader. Having both, however, works well.

"TPM" is a bit dated as a term as it's all directly built into the processor nowadays, including for smartphones and such. Another modern feature in that catalogue is memory encryption, which rules out the attack described by OP as the rebooted machine would be unable to read old memory content.