5,913 karma · joined September 10, 2011
Spare-time projects wind up here: https://code.ivysaur.me/
Later, Go's stdlib map implementation was updated to use Swiss Maps internally and everyone benefited.
Do you think the xsync.Map could be considered for upstreaming? Especially if it outperforms sync.Map at all the same use cases.
Given their goals seem to be
- Permissive use without modification, even in combined works ("MIT binaries"); but
- Copyleft with modification, including for the Affero "network hole", or commercial terms
could you suggest a clearer license option? AGPL triggers copyleft across combined works, LGPL doesn't cover the network hole, GPL has both problems. Their goals seem really reasonable, honestly, there should be a simple answer. It seems messy but I like it more than the SSPL/BSL/other neo-licenses.
126 Intel N5105, gcc -O2 (Debian)
98 Neoverse N1, gcc -O2 (Debian) - Oracle Cloud
63 Snapdragon 8gen3, clang -O2 (Termux) - Xiaomi 14
59 Ryzen 7600, clang -O2 (MSYS2 / Windows 11)
48 Ryzen 7600, clang -O2 (Debian)
45 Ryzen 7600, gcc -O2 (Debian)Why are binaries checked into the bin/ directory in the repo?
Compared to Dokku, I like how your LE support is builtin instead of a plugin. Is your main www ingress server an nginx that gets externally configured (like Dokku) or are you using net/http or libcaddy directly?
Dokku has a history of trying to compete with Heroku buildpacks - as a non Heroku/non Ruby developer this never resonated with me and there are a lot of vestigal parts (e.g. .web.1) that i would just put in my own Dockerfile directly. So focusing solely on Dockerfiles i personally feel is a good move.
One issue i faced with Dokku is eventually the build process for my Dockerized app was too memory-intensive to run on the VPS. I switched to running docker build locally, sending the container via `docker export | ssh | docker import`, and having a single `FROM myapp` dockerfile in Dokku. This was not particularly ergonomic to set up. Is it possible you can improve the UX of client-side built containers, or will you focus solely on the GitOps deploy?
I would hope "native" means at least either CPU-native code (i.e. not Typescript) or OS-native UI (i.e. not Electron) - what did you mean by it here?
(PyTorch does also support ROCm generally, it shows up as a CUDA device.)
Any SBC could buy an extra flash chip and burn an outdated U-Boot with the manufacturer's DTB baked in. Then U-Boot would boot Linux, just like UEFI does, and Linux would read the firmware's fixed DTB, just like it reads x86 firmware's fixed ACPI tables.
But - cui bono?
You need drivers in your main OS either way. On x86 you are not generally relying on your EFI's drivers for storage, video or networking.
It's actually nice that you can go without, and have one less layer.
REQUIRE_SIGNIN_VIEW=true means signin is required for all pages - that's great and definitely stops AI bots. The signin page is very cheap for Gitea to render. However, it is a barrier for the regular human visitors to your site.
'expensive' is a middle-ground that lets normal visitors browse and explore repos, view README, and download release binaries. Signin is only required for "expensive" pageloads, such as viewing file content at specific commits git history.
> I enjoy doing laundry about as much as doing dishes. I get my clothing custom made in China for prices you would not believe and have new ones regularly shipped to me. Shipping is a problem. I wish container ships had nuclear engines but it’s still much more efficient and convenient than retail. Thanks to synthetic fabrics it takes less water to make my clothes than it would to wash them, and I donate my used garments.
I'm sure i remember a few more details, like his claim that black t-shirts worn only once are the most stylish possible garment, but i'm willing to put that part down to the Berenstein Bears effect.
Chatbots are a major area to regulate. I don't see how it would be possible for Telegram (or Discord, or IRC clients...) to comply with this.
And if you browse through the ffmpeg mailing list of that historic month https://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/ you'll find his name mostly attached to esoteric video game format patches and not in the big flamewar threads.
Actually - it looks like you can also see in that same month, his post of the first SMUSH codec implementation, that we're discussing in this thread. That's probably a bigger emotional factor than LibAV.
Removing the ISA translation layer has the potential to be massively faster for full-system environments. At the expense of maybe some new bugs.
The performance should ultimately be similar to compiling your userspace application directly as Wasm, but you now get to take advantage of the full kernel ABI instead of just the minimal shims that Emscripten give you / whatever DOM glue you create yourself.
In https://github.com/golang/go/issues/64926 it was a bridge-too-far for the Go developers (fair enough) but maybe it could still happen one day.
The output is something like {precomp header}{gzip parameters}{original uncompressed data} which you can then feed to a stronger compressor.
A major use case is if you have a lot of individually gzipped archives with similar internal content, you can precomp them and then use long-range solid compression over all your archives together for massive space savings.
For small messages (open), the userspace malloc is going to have packed small buffers into a single page - so there's a chance you'd need to copy to a new userspace page, the two copies might work out better.
This gives you the advantage of Wayland's modern display stack and no legacy Xorg code while still running a classic X11 window manager.
The main downside is you have to run all X11-compatible apps, it's unable to manage any Wayland-native applications. But, X11 apps aren't going away any time soon, just the display server.