creatonez

I mean, most web application backends don't implement TLS at all, under the assumption that you're using it alongside a reverse proxy. Most of the time this is nginx, but if you want to ensure no bugs are introduced on the HTTP level by the reverse proxy, stunnel is a perfectly fine option.

Firefox has a builtin PDF reader, PDF.js, that resides inside of the Javascript sandbox. In theory, it's as safe as loading a webpage.

There have always been different types of hard drives...

> some space weather youtuber

Please stop watching that guy, he is a total fraud and knows nothing about physics.

I can't think of a more idiotic idea than a software package where every single user has a slightly different installation because the only way to install it is to feed a hallucinating random word generator with some vague instructions.

So we're just completely making shit up now?

Tor Browser handles this, it treats `.onion` as a secure context.

Note that this is not licensing the content (the content is already licensed to all of humanity, there is no royalty to be paid), this is simply them paying for a big data pipe to access the data, so that the consumer API endpoints are not overwhelmed. They will give this type of access to anyone who asks and is willing to fund the bandwidth usage.

Unlike for example Reddit, they don't actually make any attempt to block scraping other than ordinary rate limits. They just kindly request that you go the proper route instead, which in theory will be beneficial for both parties.

Microsoft is a modern IBM holocaust tabulation machine. Yes, many of the people who work for Microsoft should be prosecuted and put in prison for war crimes, with varying degrees of culpability. There are people in MS who knowing negotiated deals that aided and abetted war crimes, and those who wrote morally repugnant military surveillance software that was used to automate mass murder in the Gaza holocaust.

Every single engineer who works on this should be in prison for life. Nuremberg trials are coming. Be careful associating yourself with techno-fascists, history will not forget your git commits on evil technologies.

Wait... didn't they advertise some utterly perfect blockchain oracle that could resolve disputes in the most objective way possible? Is Polymarket overriding that, or is that system what is inevitably failing (due to it being impossible to solve the oracle problem, despite blockchain advocates' claims to the contrary)?

When Chrome first came out in 2008, it was noticeably faster than any competitors. Users with only moderate tech knowledge were switching in droves because it was faster. Part of this was that it had a process-per-tab model properly making use of multi core CPUs for the first time, but much of it was because V8 was fast.

The gap is not so big these days. JavaScriptCore, Spidermonkey, and V8 are all competent.

> all an SSG pipeline adds is more dependencies and stuff to break.

This is the exact opposite of what static site generation does.

I'm surprised they haven't been spammed by flat earthers & moon landing deniers so much that they have to stop picking up the radio.

Possibly explained by moon landing deniers being too stupid to operate radio equipment.

People complain about Github not allowing you to turn off issues and pull requests entirely, but I've always seen it as a positive. It means the truth about code quality, potential caveats, and better forked revisions can disseminate freely even when the author disappears. It becomes a spamfest at times, but is still probably a net positive for the ecosystem.

That being said, as long as you still have the discussion tab, auto-deleting all issues by default is not a big deal.

PVC releases potentially harmful vapors and is difficult to properly dispose of.

Wait, how did the `cd` executable used to work in old Unix? Did it instruct the kernel to reassign the CWD of the parent process?

I'm not talking about null safety in the sense of null pointers. Null pointers and out of bound pointers are still in the realm of memory safety, which of course Java has solved for the most part.

Proper null safety (sometimes called void safety) is to actually systematically eliminate null values, to force in the type system a path of either handling or explicitly crashing. This is what many newer expressive multi-paradigm languages have been able to achieve (and something functional programming languages have been doing for ages), but remains out of reach for Java. Java does throw an exception on errant null value access, but allows the programmer to forget to handle it by making it a `RuntimeException`, and by the time you might try to handle it, you've lost all of the semantics of what went wrong - what value was actually missing and what a missing value truly means in the domain.

> Catching exceptions, logging them, and continuing seems to be rather common. It's not like Rust and Go, where unexpected panics in libraries are often treated as security vulnerabilities because panics are expected to take down entire services, instead of just stopping processing of the current request.

Comparing exceptions to panics is a category error. Rust for example has great facilities for bubbling up errors as values. Part of why you want to avoid panicking so much is that you don't need to do it, because it is just as easy to create structured errors that can be ignored by the consumer if needed. Java exceptions should be compared to how errors are actually handled in Rust code, it turns out they end up being fairly similar in what you get out of it.

Java does fine on memory safety, but does not do great on null safety (and overall invariant protection / "make invalid states unrepresentative" ethos), has difficult to harden concurrency primitives, and won't be adopted in many scenarios due to runtime cost and performance pitfalls. Future Valhalla work fixes some of these issues, but leaves many things spiky.

It's at the kernel level. Each process has its own current working directory. On Linux, these CWD values are exposed at `/proc/[...]/cwd`. This value affects the resolution of relative paths in filesystem operations at a syscall level.

...Eight seconds for a hundred matches? What does your code look like?

Ah yeah. For VPS tenants it makes sense they would default to Chrony. They have a public facing pool of NTP servers at `time.google.com`, and for tenant use they provide `metadata.google.internal`, which is probably where the Chrony config file points. IIRC TrueTime is not actually open source and is only used internally on their infrastructure.

The Linux kernel was not born obsolete on arrival like the X Window System was. At least, not fully obsolete.

It will be obsolete someday, anyways.

Google doesn't use chrony specifically, just an algorithm that is somewhat chrony-like (but very different in other ways). It's called Google TrueTime.

This might be referring to k-anonymity where you truncate the hash so that it matches about 1000 hashes, then the client matches against that list. Which makes it so the operator can't really narrow down what exact license plates correspond to which searches.

Where are you seeing the other posts?

My understanding is that people who connect specifically to the NIST ensemble in Boulder (often via a direct fiber hookup rather than using the internet) are doing so because they are running a scientific experiment that relies on that specific clock. When your use case is sensitive enough, it's not directly interchangable with other clocks.

Everyone else is already connecting to load balanced services that rotate through many servers, or have set up their own load balancing / fallbacks. The mistakenly hardcoded configurations should probably be shaken loose anyways.

Wait, does that mean Manifest v3 is so neutered that it can't load a `<script>` tag into the page if an extension needed to?

If so, I feel like something that limited is hardly even a browser extension interface in the traditional sense.

> there are plenty things you can't express in jsdoc but can in typescript

This isn't really true anymore, they have systematically added pretty much every type system feature to the JSDoc-like syntax.

When it comes to VMs, most things are solved and have near native performance, but desktop graphics are not. Due to limitations in GPU architecture, you usually have to dedicate an entire GPU to the VM to have reasonable graphical acceleration. Qubes doesn't solve this either, IIRC the apps running in VMs are glued to the host with X11 forwarding without any acceleration support.