The whole thing is built around pulling binary packages from servers, and there's no consistent way of building those things from source.
It's extremely difficult to package anything non-trivial without referencing those binary blobs.
They had to build this whole custom thing (https://github.com/dotnet/dotnet) just to make the SDK itself buildable from source, and most releases still have some binary dependencies. They only did it for the SDK so it could be packaged in Debian, etc.
All the core parts of dotnet (e.g. roslyn) seem to be built that way. I find them very frustrating to work on. Between that and the whole nuget thing being somewhat FOSS unfriendly, I'd steer people away from C#.
I don't have any previous knowledge of this at all, but from reading the docs, nothing you're describing sounds wrong.
A u32 selector will match 4 bytes (u32 meaning unsigned 32bit presumably, which is 4 bytes).
It makes sense that you'd only be able to configure the matches on 4 byte intervals, because keeping them aligned may make the implementation simpler and more efficient. You can still match any set of bits this way.
Perhaps you could describe what you're trying to match exactly and the selectors you tried.
They are now going to be an advertising driven company, regardless of what tier you're on.
Instagram has a 10 euro/mo premium to remove ads, and they still would rather you take the ads. How long before Netflix starts nagging you to save money by turning ads on?
They're talking about Spirit AeroSystems, which I believe is an unrelated company that just coincidentally also happens to be terrible at what they do.
I get why you'd do that for the flight control stuff, but is there a reason to think that the loose-bolts/side-falling-off thing is specific to this plane? It seems like any new Boeing plane would be vulnerable to the same process failures.
I guess they are 3/4 of the planes Boeing delivers, and the only ones likely to be used short haul.
It's not just the visible complexity in this one file. The point of it is to keep a subscriber count in sync, but you have that code I referenced above, plus:
IMO that's a lot of code (and a whole dedicated file) just to (magically) hook a global event and increase the subscriber count when a link object is added.
The worst part is that it's all copy/pasted into a neighbouring file which does the reverse:
The one I was able to test on qemu was a reliable failure of memory management syscalls triggered by a certain usage pattern. Unfortunately yours sounds like it's probably hardware dependent. People in that Reddit thread mentioned video decoding, so you could try hammering that.
The nice thing about bisecting is that it's mostly logarithmic, so doubling the commits should only take one extra step. I'd be surprised if you had to do more than a 10-12 steps.
You may already have a good kernel config, but for this sort of thing I usually use make localmodconfig. That'll build all the modules that are loaded when you run it, which can cut down on compile time massively.
I did this recently and it was extremely quick to bisect and debug, but I was lucky enough to have a simple repro that worked in the emulator.
I think if I were you I'd try to repro on bleeding edge first. Then if it's still broken, I'd try to get the repro time down as much as possible and automate it. Then I'd either bisect on qemu if possible, or bare metal.
I think in theory it's great. Email already has solutions for:
etc