1. The first paragraph has a callback and link
2. You're not the intended audience of the post most likely
158 karma · joined January 14, 2026
They are careful to not exactly claim the same anonymity properties of Tor, though I think a lay reader will read that differently (ie, that they do have the same anonymity property as Tor).
That said being able to verify the inner wireguard conn to mullvad is nice. Of course you have to trust them that they aren't colluding with mullvad to share your identity/ip. But same goes for OHTTP.
> I conjured a bit of software to manage this for me[...]
I don't understand how the annotation application shown helps with the stated goal of preventing the model from praising you. What's the actual software assisted workflow?
The argument seems to take the leap from 'Ring is the wrong abstraction for what I want to do' (fair enough) and concludes 'Ring is inadequate, and therefore Clojure has a viability problem.'
Ring is explicitly designed to be web-server agnostic and therefore intentionally does not expose the full Jetty/Jakarta surface. Many using ring aren't using Jetty!
If your app requirements are specifically EE/Jetty-centric, then bypassing Ring may be entirely reasonable, but I don't see how that becomes an argument against Ring's design, much less against Clojure’s viability for enterprise applications...when enterprise means "serious business" not "Jakarta EE".
There are a few actual issues with Ring's design (that are in the issue tracker) I can think of when it comes to it's ability to express valid HTTP semantics. But "it doesn't OIDC" isn't one of them (that's sort of a category error?)
All that said... The charitable reading of "Clojure has a larger problem for its future [...] in which we can produce enterprise-grade web applications" is one where the "we" is limited to Derek's company/team, which yea, sounds like they need more Jetty/Java EE than Ring provides. But if the "we" is the Clojure community as a whole, then I would dissent.
Like this self-hosted project aims for "simple deployment"/less infra, but I can't imagine how you end up at "use Cloudflare proprietary offerings" and reconcile that with "self hosted".
But if you host the node app yourself and point it at your own seaweedfs/minio/garage that's still more infra than node process+SQLite file.
For example look at this arc from sqlite4clj https://github.com/andersmurphy/sqlite4clj/blob/master/src/s... it's very elegant.
(Also can plug my own libvips wrapper using coffi https://github.com/outskirtslabs/vips)
Using FFI/FFM "vanilla" with java interop is also viable, and in my experience the SOTA models do just fine with it (with or without jextract).
* "internal services" = on a single server that is publicly routable
Your definition of "most people" must be very different than the literal meaning.
> I disagree. It is not the model alone. It needs a system which capitalizes on it. And this is very complex. Hardware, software, architecture - it takes a lot to get it right.
What do you disagree with exactly?
> This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development
Your "patently false" is not true. There are nuances here that you are glossing over or ignoring.
Yes, the Kobo Libra Color uses secure boot.
But, you can still get root and install KOReader on it.
What is "custom development" if you mean "boot my own operating system" because, then yes. But the 90+% of the Kobo hacking community has never meant that.
For most folks in the community "custom development" means being able to install/side-load applications like Plato and KOReader alongside the existing Kobo/Nickel software.
Yea, I agree it sucks that the new Kobo uses secureboot, but it was never an open development platform. I feel for the quill-os folks, that sucks. I'm glad they found a home with the PN as they won't get a rugpull.
But the Kobo is still a system where you can trivially get root on it without having to jailbreak or otherwise exploit a vulnerability.
And +1 for the xteink x4 (though if you're rabidly against manufactures locking down their devices, you should look at the recent xteink developments where they are only releasing unlocked devices to the western market.)
With EPUB compatibility issues CSS should always be suspect number 1. Using "modern" CSS features and complaining about missing flex boxz grid, etc is a web developer's mindset.
Just because EPUB shares some of the stack with the web doesn't mean they perfectly overlap (or even should).
Hardly any e-ink embedded e-reader devices use a browser for rendering, they all use purpose built HTML/CSS parsing and rendering toolchains, are baked into firmware and updated once in a blue moon. (If you're interested look at koreader's crengine or Crosspoint reader which runs on an ESP32!)
The blog post reeks of overly confident AI prose. But don't be fooled.
https://github.com/pyrmont/jeep/
It let's you vendor deps and easily install modern Janet bundles without jpm.
shout out to one modern feature: sandbox
"Disable feature sets to prevent the interpreter from using certain system resources. Once a feature is disabled, there is no way to re-enable it."
Do you have any sources to back these claims up?
https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...