dikei

Not even close, Quantum Computer are still far from being able to do any cryptography cracking.

Yeah, sadly data and command intermingling are also one of the main things that make these "AI" appear so human.

Humans are also susceptible to prompt injection all the time, we just call it differently: social engineering or scam.

Plus, if you look at OpenWebUI horror of a commit history, they don't often take external contributions.

Some global services have control plane located only in `us-east-1`, without which they become read-only at best, or even fail outright.

https://docs.aws.amazon.com/whitepapers/latest/aws-fault-iso...

For paper documents, you'd make at least a few copies for storage at the source, and then every receiver will get his/her own notarized copies.

Electronically, everyone just receives a link to read the document.

Start training them from a very young age: competitive coders typical start in secondary/high school or even earlier.

Russia has specialized schools to support this kind of education, so are China and many other countries. Thus, they rank very high in IOI and ICPC contests

Big claims with not a single benchmark to back them up

Well, only a lunatic would use ZIP with anything but DEFLATE/DEFLATE64

I use ZSTD a ton in my programming work where efficiency matters.

But for sharing files with other people, ZIP is still king. Even 7z or RAR is niche. Everyone can open a ZIP file, and they don't really care if the file is a few MBs bigger.

I hate ticket-driven development, but clearing ticket is one way to stay sane when the final objective looks crazily out-of-touch.

Yeah, and all the popular web frameworks include authn and authz as a core component.

OpenWRT stopped doing this 10 years ago, as it was too much hassle to pick a drink that satisfy everyone.

I still remember the day when I used jemalloc debug features to triage and resolve some nasty memory bloat issues in our code that use RockDB.

Good times.

The difference is the quality of the OSS implementation: most OSS ASN.1 tool choke on the enormous 3GPP specs and others used in the telco industry, thus cannot generate 100% valid code.

For some use-cases, you can get by with manually adjust the generated code. That works until the hardware vendors release a new device that use a more modern 3GPP specs and your code start breaking again.

When using a commercial ASN.1 tooling, they often update their compilers to support the latest 3GPP specs even before the hardware vendors, and thus supporting a new device is way simpler.

DER is still easy, UPER (unaligned packed encoding rules) is so much harder, yet it's prevalent in Telecom industry. Last I checked, there was no freely available tool than can handle UPER l00%

It's not about the VCS, it's about API compatibility being broken.

If your code is out-of-tree, every time someone changes an API that break your build, it's your responsibility to update your for and fix it.

If your code is mainline, the people who change API and break the compilation are on the hook to fix it.

The use-case is because it's so cheap, why bother with anything less.

Currently, I can get 1Gbps Internet for $15, while the cheapest package is 200Mbps for $5. I expect they'll offer 10Gbps in my area in the next few years for the same cost as the 1Gbps now.

Still, at that speed, the router CPU can actually become the bottleneck, and OpenWRT currently has pretty poor support for hardware accelerated routing.

One reason for Spotify's move away from p2p was it was absolutely a no-go on mobile platform, which was rapidly becoming dominant at the time.

I prefer Log4J2 built-in JSON Template Layout to Logback's various JSON output solution.

The API of Log4J2 and SLF4J v2 are similar enough that it does not matter for basic usage, I don't see the benefit of SLF4J in a project that's already using Log4J2.

Not a good example, as the de-facto logging interface for Java was SLF4J.

Though I myself prefer Log4J2, as I'm already using Log4J2 as the concrete logging implementation.

We use the same setup, though we use PGBouncer so after switching primary we just force reconnect all clients from PGBouncer instead.

The clients will have to retry on-going transactions, but that's a basic fault tolerant requirement anyway.

I'd be more similar to Debezium-server that runs everything in the same process, than regular KafkaConnect-based Debezium.

However, this only does postgres-postgres, so it's a lot more limited compared to Debezium.

Ok, so PGLite is used in the Firebase Data Connect's emulator: a test utility, not even the client library.

It's a bit disingenuous to lump it in the same sentence and try to mislead user that Google's adopting Electric.

Yeah, I'm gonna need a citation on Google's usage of ElectricSQL, considering that the link points to Firebase Data Connect.

The problem with handcrafted build system is only the author can effectively maintain it. When he moves on, someone has to spend the time ripping it out and replace with something more standard.

I've been on both end of this situation and would rather not do it again, so I'll use whatever is the de-facto standard, but you do you.

Yes, basically any build system that supports distributed caching use digest instead of timestamp when checking modification: Bazel, Pants, Buck, etc.

They're all hugely complex though.

For local build only, I think SCons and Waf both use hash for changes detection.

Yeah, I think the HFT guys use CPU pinning a lot: 1 process - 1 CPU, so you'd need multiple processes to take advantage of multicores server.

Well, "pause too short to matter" just doesn't have the same ring to it.

Maybe they run a small heap with a zero-pause JVM like Zing, as pause-less GC generally has lower throughput than normal GC.

So basically, you want to build a write-ahead-log before writing data to Kafka, and I think you're underestimating the effort to implement a WAL.

If you don't have a person that can manage Kafka, you almost definitely don't have the person to maintain a WAL.