accelbred

Why can't webusb be implemented as an extension using a native messaging host?

Agreed. Therefore I use niether webUSB or vendor apps but rather use hardware that works with openocd and open source tooling.

Unchecking resistFingerprinting in the settings disables these. You can also use the new firefox FPP settings to enable most if RFP stuff but opt out of specific stuff like dark mode, timezone, etc. You can even add per-site exceptions.

For example, my config is at https://codeberg.org/accelbread/config-flake/src/branch/mast...

I once moved a C++ project to C, and compile times went from 15 minutes to 5 seconds. It was a huge productivity boost. LLVM being slow to compile is also one of the reasons the Zig folk are looking to make it an optional dependency.

You can use Librewolf with Mozilla's sync server; you don't have to self-host to have sync with it.

On the other hand, at Amazon, people I know like Chime. Sad its going away.

Not being able to easily write a program without Unicode being pulled in for Rust code was a reason I'd chosen C over Rust before. When targeting binary sizes measured in kilobytes, pulling in full unicode handling is not an option. Especially since programs that don't have direct human interaction rarely actually need unicode.

All the dark mode extensions I've used also would work for making pages light mode.

For me, I have trouble focusing when reading light mode content, but dark mode is perfectly fine (light backgrounds seem not still, as if there is movement, and this effect lessens the darker the background is.

I really like MessagePack as a serialization format but it does leave a lot underspecified, such as how to handle decoding/encoding integers. While the encoding has signed and unsigned types, the data model does not. Its not straightforward to translate to a data midel with separate signed and unsigned types.

The separation between str and bin types doesnt make sense for my usecases, and others with similar usecases either always use bin or always use str. logically bin would make sense, but str has fixstr and theres no fixbin, so more efficient to use str. Both are valid but thats more discrepancies to deal with.

For my personal usecases I'm thinking of forking MessagePack, removing str and ext, reallocting tag space a bit, having a clear mapping to low level language types, adding 128 bit integers, and maybe a frame type for streams.

Thats what Zig does. It compiles down to the same stuff as C. It does not have a runtime.

Worse yet, at least in Seattle, are right arrow lights that go green at the same time as the walk light. You get a green light to go and pedestrians start crossing at the same time. Having a green light and a walking sign on should be mutually exclusive.

I avoid the Rust stdlib. The stdlib uses panics and dynamic memory allocation, neither of which are great for embedded usecases or writing software adhering to safety-critical coding practices. no_std is common for embedded targets, and IIRC the linux kernel couldn't use stdlib because of panics.

Does Zig fit your bill?

Note that using this will likely violate strict aliasing due to using the void pointer returned as one type, freeing it, and then getting that same chunk again and using it as another type. You'll probably want to compile with -fno-strict-aliasing to be safe.

A good reference on strict aliasing: https://gist.github.com/shafik/848ae25ee209f698763cffee272a5...

__attribute__((cleanup)) cleans up on scope exit, unlike go.

This defer (using attribute cleanup) as well as Zig's are run when going out of scope. Go's runs at function exit.

Nice, if this is reliable across gcc versions and optimization levels, I might consider it for future stuff. Though making it such that treesitter and other tools dont barf on it would still need investigation.

The macro from the article uses nested functions which on gcc are implemented with tramolines that need executable stack.

https://thephd.dev/lambdas-nested-functions-block-expression...

Destructors are hidden control flow, and can be non-obvious for structs from other files. I find they make code significantly harder to follow than in plain C. Defer does not have the problem, as all the logic in your function is explicitly there.

The main problem I have with fuse is inotify not working. If inotify just worked for fuse, I'd just use it. Ideally I could just run the software in a mount namespace with a fuse fs, but I need inotify.

I mainly was trying to use ublk to implement a sort of fuse like thing with the kernel handling the fs and thus having inotify support.

Since when can you use a MAC as an unprivileged user on an arbitrary distro?

Unfortunately, this requires an executable stack, and only works on gcc, though an alternate implementation can work on clang.

After a few attempts at defer, I ended up using a cleanup macro that just takes a function and a value to pass to it: https://github.com/aws-greengrass/aws-greengrass-lite/blob/8...

Since the attribute or a function-like macro in the attribute position broke the c parsing in some tooling, I made the macro look like a statement.

Out of current ones, at a quick glance: connect, openat, openat2, renameat, mkdirat, and bind. More importantly, I'd like to block any opcode I haven't whitelisted, even when my software runs on future kernels with more opcodes available.

Now that I think about it, how does io_uring interact with landlock?

I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well just use epoll and not maintain two async backends for your application.

I write pure embedded C at work. I used to pretty much only write Rust prior to going into the embedded field. Rust gives you memory safety, but has costs. It is a complex language (like C++ but not to same extent) with a lot of non-local code flow. Certain patterns useful in embedded to save memory dont jive well with the borrow checker. It also makes it hard to avoid dynamic memory allocations, panics, and large binary sizes; at work, we've been considering Rust and it looks like we'll have to use no_std. That cuts out most of the ecosystem, which isn't the worst because dependency explosion is also a problem.

At work, we'll likely end up incorporating no_std rust, but for personal stuff I just use Zig these days. It a simple language that makes embedded style programming easier, and has a usable std lib due to not using global allocators or panic-like mechanims.

This is false; with formal analysis tools like CBMC, you can prove the memory safety properties of your C code. You can even statically prove lack of integer overflows and that asserts are unreachable. I'll agree this is uncommon in general, but CBMC is used for various C codebases where I work. Though this tooling is also available for Rust with Kani.

Hyperfine is a really useful tool.

Weirdest thing I've used it for is comparing io throughput on various disks.

Nice! I was planning to try this at some point to bootstrap my environment, so nice to know its possible.

I work for the team that maintains coreMQTT (https://github.com/FreeRTOS/coreMQTT)

Its a C89 MQTT library intended for embedded devices.

MMUless embedded with FreeRTOS. For example, at one point, we did not want connecting over TCP to block our command handler, so created a task that waited for a notification, and connected on that task, and went back to waiting for another notification. Though we ended up combining some tasks' responsibilities to reduce the amount of total stack space we needed.