TD-Linux

The biggest thing for me is the meson build system. newlib uses autoconf-generated files checked into the build tree, with several different versions of autoconf used depending on directory. So you have to keep several versions of autoconf around if you want to add e.g. another source file without churning the generated files.

The red content is intended to be supplied by a separate red LED. A red LED produces red much more efficiently than the phosphor on a white LED, so it saves power to leave red out entirely if you know it will be paired with red.

The loss of a higher buck ratio is not insignificant. It requires higher voltage rated mosfets which generally have worse performance, as well as increased switching losses resulting in more heat where you least want it. Most other use cases for 24/48V involve significantly longer wires than in a PC case. I think the actual net win, if any, would be quite small.

Comment 19 is 7 years old and doesn't reflect the contents of the patch that actually closed the bug, which enables HEVC both on Android and desktop when provided by the OS (but does not ship a software decoder itself).

>This is Fedora fighting against a patent troll which will cause a big legal hassle and then back off.

For a patent troll sure, but what makes you think Fedora will win for a codec that from its inception has been explicitly nonfree?

In general you can convert any speaker layout etc to Ambisonics. For Atmos specifically, no, because there is no software decoder available for it (you have to bitstream it to a receiver).

It is, in fact, Ambisonics (among other features).

Though you don't actually need any of the fancy new stuff being worked on to use Ambisonics - you can already use Opus with Ambisonics today in MP4.

Over the last couple of years, yes. The GD32 and CH32V are increasingly popular. This is not so much ARM's fault directly though, as it is the complete unavailablility of STM32s forcing many companies to look for a quick replacement.

They still mechanically open the circuit breaker, which takes time.

Linux actually switched recently to leaving the whole bottom 1MB to the BIOS: https://lore.kernel.org/lkml/YLx%2FiA8xeRzwhXJn@zn.tnic/T/#u

Apparently Windows now does it too because too many BIOSes are buggy: https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2

The patents in question are a new level of terribad. So bad that they can be trivially invalidated by prior art. Nikon's going to spend a lot of money on lawyers but is likely to win (if they don't settle out of court...)

(When reading patents, skip to the claims, they are the only part that actually matters).

7,830,967's independent claim is a 2k+ resolution video camera that records sRGB or rec709 gamma. That's it.

8,174,560 is even more ridiculous. It's a 2k+ resolution camera that records at a 6:1 or more compression ratio. No actual method or anything, just the concept of compressing at least 6:1 compression ratio. Check out indepedent claim #1.

Both of these are very likely to have very easy prior art available. Finding any camera that records high resolution video, made before the priority date would do it.

Strictly speaking, only the claims matter, and so the text if those would need to be read and used to determine whether it can be invalidated due to prior art. The claims have very little to do with the diagrams supplied, rather they are about a way to compress cache coherency transfers if the line is all zeros (kind of like LPDDR has, in a way).

That said, copying so many of a competitors' slides into figures is still stupid as it is highly unlikely to give a judge a great first impression.

This is specifically IEEE Spectrum, and yes it is part for the course for Spectrum articles.

>How does Pipewire deal with this?

It doesn't, it sets a much shorter max buffer length so that the latency is always acceptable. This does mean that in theory, with an otherwise totally idle system, PipeWire can't be quite as low power as PA.

In my case, the big advantage is the automatic insertion of resamplers between different clock domains, meaning you can connect anything to anything. Pulseaudio tries really hard to make sure there is only one clock driving any connection graph, so that's why there's no arbitrary connection support without loading things like module-loopback that add the resampling themselves.

Another thing that helps is that in some ways PipeWire is less featureful than PA. For example, it limits the max audio buffer size to ~180ms which means it doesn't have to implement rewinds, one of the buggier features of PA (with the downside that power consumption can't ever be quite as low as PA).

I have been impressed how I've been able to make arbitrarily complex audio graphs in QJackCtl and it just works. I can even activate patch bays and it forces the audio configuration and applications (even browsers) stay happy.

It's impressive how it manages to support connections that require reclocking and do the needed large ratio resampling needed behind the scenes, something that PulseAudio was never really able to do. It's also nice for monitoring while streaming and seems to have much lower latency than OBS's monitoring.

Generally no, simply publishing is enough prior art to avoid someone else getting a patent. It can be helpful in indirect ways, like being more likely to be seen by a patent examiner. Alternately, you can license it under a defensive patent license which is very useful in some situations (see e.g. Opus, AV1).

FWIW I've run a mica window geiger cointer for hours in front of my tubes and been completely unable ti measure any radiation above ambient. At some point I will do it with a large scintillator, but already it's pretty clear that those X-rays are very soft indeed.

WebEx (even in the browser) stars and stops the mic every time you mute and unmute and it works fine. There is no technical blocker.

I am surprised to see what I consider to be the most important part of signed integers in C and C++ only barely mentioned:

>use of signed integers is better as it’s the only way you can get trap behavior for integers, as using it on unsigned would trigger trap representations for valid code that relies on that behavior.

For video and audio codec code, and really anything integer math heavy, being able to use UBSan to find overflows is a hugely beneficial tool, and something you can normally only do with signed integers due to the C spec (it's less of an issue in Rust as that language makes both signed and unsigned overflow illegal).

>Trap representations are actually quite insufficient as they can only trigger at runtime when those paths are successfully executed with the correct trap-producing inputs. This coverage is impossible to expect in any non-trivial program even with exhaustive unit testing.

This was true before fuzzers existed, but now that we have several very good fuzzer implementations (plus a few smart unit tests), the coverage is well within reach.

The tradeoff makes sense mostly for many-party calls - for a 1:1 call sending multiple resolutions is a waste, but for a many participant call the downlink bandwidth usage becomes much larger than the uplink.

You layer idea is called SVC and is mentioned in the article. But VP8 doesn't support it, it is waiting on them to upgrade to VP9 or AV1.

Neat, I didn't know that the MPU fault handler was complete enough to allow for restarts.

Now that the source is available, I took a look at what hubris does - it is not actually anything fancy, just a static list of up to 8 MPU regions per task [1].

It seems that leases aren't actually shared memory, but rather just grant permission for a memcpy-like syscall [2]. This is slightly better than plain message passing as the recipient gets to decide what memory it wants to access, but is still a memcpy.

[1] https://github.com/oxidecomputer/hubris/blob/8833cc1dcfdbf10...

[2] https://hubris.oxide.computer/reference/#_borrow_read_4

I definitely didn't mean it as a feature request - blobs aren't actually that common in embedded (esp32 and some motor driver libraries are the most common exceptions), so I don't think it's important for adoption. In fact, not supporting it enables future ergonomics improvements and code sharing between tasks, so I appreciate that it's not a driving factor in the design.

It doesn't need to link any symbols, but I believe it does need to do relocations if the code isn't PIC, and to relocate the task's statically allocated RAM.

I have an embedded real-time control project that is currently written in Rust, but runs with RTIC (https://rtic.rs/), a framework which is conceptually similar (no dynamic allocation of tasks or resources) but also has some differences. RTIC is more of a framework for locks and critical sections in an interrupt based program than a full fledged RTOS. Looking through the docs, here's the main differences (for my purposes) I see:

1. In Hubris, all interrupt handlers dispatch to a software task. In RTIC, you can dispatch to a software task, but you can also run the code directly in the interrupt handler. RTIC is reliant on Cortex-M's NVIC for preemption, whereas Hubris can preempt in software (assuming it is implemented). This does increase the minimum effective interrupt latency in Hubris, and if not very carefully implemented, the jitter also.

2. Hubris compiles each task separately and then pastes the binaries together, presumably with a fancy linker script. RTIC can have everything in one source file and builds everything into one LTO'd blob. I see the Hubris method as mostly a downside (unless you want to integrate binary blobs, for example), but it might have been needed for:

3. Hubris supports Cortex-M memory protection regions. This is pretty neat and something that is mostly out of scope for RTIC (being built around primitives that allow shared memory, trying to map into the very limited number of MPU regions would be difficult at best). Of course, it's Rust, so in theory you wouldn't need the MPU protections, but if you have to run any sort of untrusted code this is definitely the winner.

Hubris does support shared memory via leases, but I'm not sure how it manages to map them into the very limited 8 Cortex-M MPU regions. I'm quite interested to look at the implementation when the source code is released.

Edit: I forgot to mention the biggest difference, which is that because tasks have separate stacks in Hubris, you can do blocking waits. RTIC may support async in the future but for now you must manually construct state machines.

Another reason many games use Ogg Vorbis is for seamless looping and zero delay sound effects. Gapless MP3 is a bit of a mess because encoders insert priming samples but there is no standard way to signal it in the bitstream. (it also compresses better than MP3)

I think the GP mostly answered it, but usually it's so that they are self-consistent with a set of design rules, and known to work. Every place I've done professional PCB work has had their own library.

I think this trend comes from exposure to really poor standard libraries - for example, I found Altium's libraries being especially inconsistent and weird (though it's been a few years since I've last used Altium).

I've personally found the KiCAD standard libraries to be very consistent and high quality in comparison (both the symbols and footprints), and have no problem using them on my own designs - in fact, if I have to make my own schematic symbol, I often reference the standard libraries' design rules when making it.

JAMMA arcade PCBs normally only use the -5V for audio opamps or DACs. The power amplifier is powered by the +12V rail (in a bridge configuration to provide +/-12V swings to the speaker).

There is a dedicated storage driver for zfs: https://www.jwillikers.com/podman-with-btrfs-and-zfs

That said, the default overlay storage driver already supports reflinks, which will get you most of the benefits.

Linux still has a lot of assumptions baked into the page size. Power9 and some aarch64 systems have 16kB pages, but occasionally you run into some corner cases - for example, you can't mount a btrfs partition created on a x86 machine on a power9 one because the btrfs page size must be >= the mmu page size.