@ocratato The problem is if you have something like:

typedef int foo_t;
typedef int bar_t;

void f(foo_t a, bar_t b) { .. }

foo_t myfoo = 1;
bar_t mybar = 2;

f(mybar, myfoo);

Compiles just fine.

That's why I was thinking about wrapping it in a struct -- you can still pass by value, but get an error if you mess something like the above up.

Has anyone else (in C) wrapped an int type in a struct to avoid accidental mixing of ints with different semantic values?

Oh firmware, will you ever not stop being terrible?

@jlevon @jmc The half-baked ideas (e.g. defer working at the function level instead of at the scope level) tend to be what annoy me the most.

Really annoying when industry groups produce _large_ PDF specifications without a table of contents that you can use to skip to sections. Or when they do, they, completely screw it up. Looking at you trustedcomputinggroup.

Thou shalt accept, DEI didn't hold your career back -- you're just mid, bro.

@mjg59 Pretend for the moment Sun chose Apache 2.0. The FSF itself to this day proclaims that it's not GPL 2.0 compatible -- it's right on their website -- https://www.gnu.org/licenses/license-list.html#apache2

Even if people disagree with the FSF's position on the license, they carry enough weight that people would have still pointed to that as proof that it was all a part of some vast anti-GPL conspiracy.

@mjg59 Which does nothing about the patent peace provision.

@zwol @mjg59 I keep hearing this from time to time, but the only actual source I've ever found for that was traced back to _one_ person who worked at Sun (amongst tens of thousands of others) at the time claiming this.

On the other hand, the explanation given by others at Sun was that they did not have the rights to open source all of the pieces of Solaris, so licensing it as GPL would have meant no one but Sun would have been able to build Solaris. At the time, there was no interest from anyone to just open pieces of (i.e. just open source ZFS, etc). If anything would have led to accusations of 'oh, they're deliberately withholding pieces' for some perceived nefarious intent.

So Sun wanted a license that was copyleft, but at the file level to get around the problem of the bits they didn't have the rights to license so others could build Solaris (so it didn't give Sun any special advantage -- aside from having more experience with it). They also wanted something with a patent peace provision. NetApp had sued them over ZFS, and at the time IBM was somewhat notorious for bullying other companies with their patent portfolio, so these weren't exactly idle concerns. There wasn't an open source license at the time that fit the bill.

So on one hand, you can believe that everyone at Sun was all of one anti-GPL mind complete with pictures of RMS on dartboards in their offices, and did all of this just to spite the open source community, or you can believe that they made an honest effort to do the best they could given the constraints.

Having known some of the people that were actually intimately involved in the process, and knowing that they are in fact big advocates of open source, it always annoys me that they get shit on for trying to get the best results they could given the constraints they had because they weren't able to achieve 100% perfection.

Once you're used to ZFS boot environments and are used to things like pkg(1) née pkg(5) just working for decades without any major problems (and none that could't be fixed with a quick and easy rollback), it's a stark reminder how pampered you are when you have to deal with systems that are every bit as clunky and brittle as they were 30 years ago (I'm looking at you RedHat).

As much as I like rust, every time I look at async rust, I really think they missed the mark. It feels like a bolt-on to the language that interacts poorly instead of being a part of the language. I strongly suspect a future edition will need breaking changes to fix it.

So far I've only found 1 other relevant (why TF did they have to pick the same name as something commonly used when preparing Windows images.. grrr) that seems to be the same issue..

Any UEFI experts out there? I have a (physical) system that claims to support SysPrep (BootOptionSupport is 0x313), but trying to run a simple UEFI app via SysPrep doesn't appear to work. Any ideas how to troubleshoot?

Ran into this a while ago (unfortunately I can't recall from where now)... https://research.swtch.com/ub

@georgetakei I'm still trying to repair the damage they caused (and not sure I'll ever completely succeed).

Fair point...

@danmcd And I guess to be clear, it doesn't break anything.. just if you're trying to match a device from UEFI to your running OS, it just makes it a pain since the bytes are reversed.

@danmcd It's annoying.. I'm guessing it was too late to fix (without causing device paths to change) before it was spotted...

Apparently UEFI (at least on this Supermicro system, but I suspect they're probably all using the same source from Intel as a base) treats an NVMe namespace EUI as a little endian value in the device path node (at least the text version) despite the standard (and every OS I'm aware of) treating it as a big endian value.... so your UEFI device path nodes show up backwards from what you see in the OS.... sigh...

YUP, anyone else?