dezgeg

In my experience this turns to nightmare when (not if, when) there is need to make changes to the libraries and app at the same time. Especially with libraries it's often necessary to create a client for an API at the same time to really know that the interface is any good.

Possibly it's decoding MIB only, which is only 1.080 MHz wide.

No. There is no stable ABI nor API for in-kernel device drivers.

Agreed, and in the wild I've indeed seen rebasing used significantly more often than merges for this purpose.

x86 app might mmap 8kb, then munmap the second 4kb and expect that to work. But not possible on 16k pages.

I've generally found buildroot work pretty well. One common problem causing weird issues however is lots of tools from the host system are used (without any sandboxing). E.g building old releases of buildroot on newer Ubuntu will break.

Its biggest Achilles heel IMO is the need to always compile everything from scratch with no possibility of caching. Also the fact that incremental rebuilds after changing config options isn't guaranteed to work unless you manually know to know which packages to force nuke and force to recompile (this is intentional design choice for implementation simplicity and well documented). Also having two different boards that inherit from common shared config isn't really supported, everyone just rolls their own custom config splicer at that point.

Yocto fixes those issues, but IMO the most other things are much less ergonomic. While buildroot is extremely simple, yocto is total opposite to that, an architecture astronaut's dream. There is custom language to learn, ton of functionality, config and documentation split in tiny files in different repositories. Of which everyone using slightly different subset to accomplish almost the same thing.

Yeah, using serialization format that doesn't even have obvious way of representing every possible Linux filename (nothing mandates filenames to be valid UTF-8, only thing they can't contain is NUL and '/') seems bad fit for low-level system services.

I can't wait to have apps and services crash and burn left and right due to accidentally (or maliciously) created non-UTF8 filenames in world readable directories.

I found this part funny:

> Also, I really didn't want yet another thing with [...] code to debug (there comes a time in every programmer's life when they can't face debugging yet another thing that should be simple and just work)

... when two paragraphs later comes the code to generate a SVG :)

Another "fun" thing is old joysticks and steering wheels that require calibration. This used to be done in the windows control panel such that not every game needs to implement that... However it seems the latest API in fashion that eg. Unity uses just totally ignores that native calibration totally. (Could just be an Unity side problem also). So bunch of old wheels are broken on Unity.

Good example is SpaceX vs. all the others

Also not so coincidentally the 'fun' to fix debt is often prioritized over critical debt.

Case in point, the situation with our flaky/unstable test got so bad that quarter of them are now to set ignore any failures. Pretty much zero interest in fixing.

Meanwhile, the rewrite of a service that had no outstanding bugs (but was originally written by other team but handed to us) is still not done after 4 months...

It's already been in the mid range (~1 GHz CPU, ~1 GB RAM) embedded systems over half a decade.

The firmware is in control of the clocks, and in case too high of a clock is specified in config.txt it burns a 'warranty void' fuse.

The +x needs to belong inside the {}, ie. "${var+x}" not "${var}+x"

But I agree I wouldn't extrapolate too much from one such brain fart

In addition to what you mentioned, the ability to atomically commit to a library and all of its consumers. And for a change to a library run the tests of all of its consumers as well.

I'd be surprised if that was not fixable in the Jetson with pure software changes.

Not true, there are smaller companies providing closed source kernel modules as well. Check any Android image for a device with SD card slot in the era where open source exfat driver didn't exist, and you'll likely find one of the 2 proprietary exfat driver modules.

Embedded/mobile projects don't tend to use bleeding-edge kernels and stuck on one version regardless of closed source modules anyway.

I assume that's because wear leveling is something that would be implemented purely in software, so there's no much point having such info in a hardware manual.

Mainline kernel tends to have only basic support (if at all) for many SoCs that actually get used in phones, especially full power management support has been lacking.

There's still plenty of embedded shops stuck thinking "it's embedded so only thing performant enough is C++", despite having multicore SoCs with multiple GBs of memory and integrated GPU. But I agree (and certainly hope so) that the amount of those companies go down.

It sounded to me that he's just responding to a frequently asked readers question. And I'd guess it's more likely for people to ask such question if they're not familiar with US taxation.

Haven't those people who have years of experience also gone through years of forced MS Office GUI changes?

The same thing has happened in the Linux kernel - there are multiple semi-duplicate SoC USB drivers for the Synopsys core.

Haskell enforces that types and type constructors start with Uppercase, and that everything else starts with lowercase.

Somehow I had thought even in buffered mode the kernel would only accept block-aligned and sized I/O. TIL.

Isn't `nc -l -p 1234 > /dev/nvme0nX` working by accident (relying on that netcat is buffering its output in multiples of disk block size)?

Let's have a concrete example, link() in struct inode_operations is defined as:

    int (*link) (struct dentry *,struct inode *,struct dentry *);

Let's then look at the ext4 implementation of the link() operation:

    static int ext4_link(struct dentry *old_dentry,
           struct inode *dir, struct dentry *dentry)
    {
    ...
       if ((ext4_test_inode_flag(dir, EXT4_INODE_PROJINHERIT)) &&
     (!projid_eq(EXT4_I(dir)->i_projid,
   EXT4_I(old_dentry->d_inode)->i_projid)))
  return -EXDEV;
    ....

In particular that calls EXT4_I():

    static inline struct ext4_inode_info *EXT4_I(struct inode *inode)
    {
        return container_of(inode, struct ext4_inode_info, vfs_inode);
    }

Which is basically just direct unchecked pointer type conversion. So, calling ext4_link() on any non-ext4 created struct inode will blow up badly.

> I need to change the mode of a wifi driver (which I do via modprobe)

Is that something that could be added to modprobe.conf to have it work right without any modprobe calls?

> Huh, onehsot services are listed as stopped even though they've run. Do some research, find out I need the `RemainAfterExit` keyword yet. Sure, dependencies are working.

Yeah I've also been burned not having RemainAfterExit=y in a oneshot unit. What's worse, such an unit can get started multiple times.

> Well looking around at dmesg it looks like the problem is that networkmanager is trying to do something with the device at the same time I am. Looks like it's enumerating device capabilities at the same time I'm trying to create a new device?

To be fair such race condition could have happened in any init system.

> Oh well, I'll just add the retry keyword to my service.

Perhaps having a dependency to start your service before network-manager would have solved this.

> Long story short I ended up just writing a traditional shell-script based init script. Maybe I'm thinking about systemd wrong or something.

It's perfectly fine IMO to have small shell script services for such stuff.

Probably some of the problems are due to network-manager being mostly designed/used for desktop use cases. It also likes to take complete control of all the interfaces so calling iw/ifconfig behind it's back will cause tears (as you found out).

I do agree that race conditions caused by parallel service startup really suck in embedded devices. Systemd really could use a "please be as deterministic as possible" mode for embedded (if it already doesn't have).

The main problem of buildroot is the fact you need to rebuild from scratch all the time. Yocto has properly working incremental builds.

Yocto is definitely more flexible, which can be a curse as it gives architecture astronauts more chances to split up all the stuff it several repos and dozens of files.

Even the mechanism predating WALv1 (rollback journal) uses two files. I don't think there is any way of using SQLite crash-proof with just a single file.

Besides, even if the database is single-file it's still necessary to use filesystem snapshotting for live backup, or it's likely to get an inconsistent copy.