C with Zig's comptime is compelling though. Zig doesnt allow you to access all the features your C compiler does, and puts you in the LLVM ecosystem. I've been working on something similar; extending C with both Zig/C++ inspired reflection and linear types, with a compiler that compiles to a subset of C to allow you to leverage GCC and all its extenstions.
why? Web Serial is one of the better web-based integrations out there. There is no functionality available without an explicit authorization, all that website can do is to pop up a dialog. And you approve individual port on per-site basis, so it's not like it can grab a random port without your knowledge.
This is my favorite model for web: anything more complex should be gated behind user permission. A site which requires that functionality will get that permission with no problem, and a random clickbait fingerprinter will get nothing.
As others have said, you'll get a dialog if any site actually tries to use this. But if you want to fully turn it off, just set "dom.webserial.enabled" to false in about:config (and restart Firefox)
More like RIP bun. Wouldn't have paid any attention bun if it weren't for Zig. Now I need to figure out what the "normal" runtime is to switch my work typescript stuff to.
This level of quality is why they have my business. We had a CI setup with rpi boards that needed fans (uart clock tied to cpu clock so heat meant slowing down and the uart dropped characters). I got tired of seeing random test failures on some board and driving up to the office to replace the fan that had failed. And they were loud and annoying. I ended up frustrated and expensing hundreds of dollars of noctua fans. Dead quiet, did a better job, and not even one ever failed on me.
A quiet PC is one reason I've always removed the GPU cards from used ones I've gotten. The crappy little fans on GPUs that constantly whir up and down drives me nuts.
When my GPU fans went bad and I didn't want to buy a new GPU (nothing wrong with my 1070, it still runs the games I care about) I bought some smaller noctua fans and 3D printed an adapter plate (in PETG). The connectors were non-standard, but the signals weren't, so I had to splice together some cables with soldering and heatshrink tubes.
Nah I mean like they partner up to design that part for specific models, it would be hard to make a generic one-size-fits-all given how much PCBs differ, though now that I've looked into it it seems that they currently just have the 5080 available which is odd.
The one problem I have with the trusted files thing is that I have no way to trust non-file-visiting buffers. Why is *scratch* untrusted!? *scratch* should always be trusted, without me having to configure anything, ideally. Though a setting to automatically trust non-file-visiting buffers would be nice.
I just ended up stopping using the scratch buffer because of that issue.
Right, the fact that the initial scratch buffer is untrusted is a bug AFAICT.
I'm considering adding a workaround to this issue in trust-manager, although ideally it should (also) be solved upstream.
Do note that I only configure this for `lisp-interaction-mode', which in practice really only gets used for the *scratch* buffer. But there are a few other instances in core that also use it, and if that concerns you, you can extend the above snippet with a check like
In practice this should also work. Do keep in mind if you just add this to your init.el then this will not persist if you re-create the scratch buffer.
If we are already experimenting with different ideas, this should also work (and gives a hint of how you want to fix the issue upstream):
I have the opposite experience. I have no trouble navigating Gnome apps, and now when selecting an application for a task, I'll choose a Gnome or GTK4 one first. Other apps implement odd controls that don't mesh with the rest of the system.
Most of the deadlocks I've faced are with different proccesses/devices both waiting on reads from each end of a socket/uart/etc. I've taken to putting timeouts on read calls, though then you have to deal with legitimate long request cycles timing out.
I have anecdata from my gamedev work that people tend to make mistakes when threads are pinned to some CPUs. Normally, when only time is a variable people can understand what can happen in their code. What confuses them is that space where those threads execute can be already taken. If a thread that should make whole system progress fails to grab a time slice these deadlocks are hard to reason about. Granted that lock ordering is the basic technique and if system did not had it all bets are off.
reply