It's single, self-contained shell script. If it's not packaged for one's distro, amd they don't know how to replace a command and keep it updated, then this shim is not for them, and that is ok.
For the technically inclined who like challenges, creating a distro package of this shim is the "hello world" equivalent for packaging.
well done.
this brought up fond memories of crackme communities in the early web... looking at asm callgraphs in ollydbg ...
I just found my +20y old patch.exe that 'NOP's the correct address of a popular windows archive handling software just to get rid of its nag screen ;-)
One of my favorite blog posts. I enjoy it every time I read it. I've implemented two C package managers and they... were fine. I think it's a pretty genuinely hard thing to get right outside of a niche.
I've written two C package managers in my life. The most recent one is mildly better than the first from a decade ago, but still not quite right. If I ever build one I think is good enough I'll share, only
to mostly likely learn about 50 edge cases I didn't think of :)
They lost me when they advocate for global dependencies instead of bundling. Are you supposed to have one `python` in your machine? One copy of LLVM (shared across languages!) ? One `cuda-runtime`?
I was involved in a very similar situation once.
I recommend wireguard for this, it's mature for years, has superb support in linux and some BSDs and there are userspace implementations if you need that.
It wraps traffic in UDP, the overhead is much smaller thus throughput mich higher than traditional TCP-based VPN (you want to avoid tcp-in-tcp!).
There were once patches posted to lkml that passed QoS-flags from the inner packet to the wireguard packet, if you need that. not sure if that landed upstream in the end.
key distribution and lifecycle management is what was still unsolved years back when this was evaluated, nowadays tailscale and its clones and similar oss should serve you well.
I have ublock origin. It's impossible to use the internet without it. Removing the top layer works for fixing mouse clicks, but in cases like these I rather just drop the whole website without reading.
I mean, if a project is not able to get a functioning website, then well...
you all make it hard by bloating your sites with Jenga tower abstractions for styling, needlessly load content dynamically via Jenga tower javascript libraries that pulls complexity into frontend and most of the time puts unnecessary load on the content generator ("backend") too.
I don't know a lof of sites where that actually makes sense, as web === text.
When html5 came about, along with CSS3, it was such a big leaf in terms of ease of use and accessibility. I argue that what most websites do to my taste nowadays can be achieved by early-stage html5+css3+ a few svg.
Nowadays on about 50% of websites it have to
* enable 3rd-party JS just to get the text
* enable massive amounts of 3rd-party JS to get the images
* enable remote fonts just to grok your pathetic icon-only menu or even spot the 'search' feature (it's not even a 'button' most of the time) because you didn't care to use a proper <img> or <svg>
I don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.
reply