Obligatory Lunduke warning, but I feel like the main point of the article (that the project was led by someone without any qualifications in leading such a project) still stands.
The ESP is just a FAT-32 partition, so its capable of being up to 4GB (by default).
At 4GB you can probably store most linux distributions on the ESP, so the title makes it less impressive than it is.
Technically the ESP doesn't have to be a FAT32 partition. UEFI has file system drivers installable at runtime [1], so you could have an ESP partition that isn't FAT32... assuming that the file system driver for it is loaded. UEFI implementations must have built-in support for FAT per the specification, but you'd need to slipstream any extra EFI drivers into your platform's firmware that are required to get to the ESP.
I think that ESP partitions formatted as HFS+ were a thing on Intel Macs, but I've never had one to try it out.
IIRC FAT32 is the only that needs to be supported for a valid UEFI implementation. So to actually have something like that alpine image work for most it does need to be limited to that.
There are also standalone EFI drivers that can be loaded by other means: https://archlinux.org/packages/extra/any/efifs/ (e.g. systemd-boot loads these if they are installed to `<esp>/EFI/systemd/drivers/`)
> This C program doesn’t use any C standard library functions.
This is only half true. While the code doesn't call any stdlib functions, it still relies on the the c stdlib and runtime in order to get called and properly exit.
I'm somewhat perplexed why the author did do it with the runtime, given that he doesn't really depend on features of it (except maybe the automatic exit code handling) instead of building with -ffreestanding.
GLib also provides macros that use autocleanup.[0]
Using a bunch of macro magic, they allow you to write `g_autoptr(GPtrArray) arr = ...` to automatically unref arr when the scipe exits.
One footgun that autocleanup has and C++ smart pointers don't is, that the cleanup function isn't called on reassignment, so reassigning on a autoptr causes the previous value to leak.
Wouldn't it've been easier to compile mono for Windows 95 instead of spending countless hours debugging an ancient release of .net without any sort of debug symbols?
I was thinking more about -Xint, or in Docker, or x86 JVM, but my guess is that somebody already tested it ;-)
Other thing is that one of developers in my team who is on M1 and 14.4 is able to run Java app, so...
This disables use of all signal handlers, which means Java apps will also e.g. fail to quit cleanly in response to issuing SIGQUIT, or hitting ^C at the terminal. Better than "no workaround whatsoever" but far from ideal!
The thing I like about the Xcursor image format is that it so extremely simple[0]. Every semi-competent developer should be able to implement a parser/writer for the format in under an hour.
But encoding the images with PNG does make sense, given the wide availability of libpng and the potential file size savings. I don't know how the feel about SVG support. One the one hand using vector graphics for cursors seems like a great idea but SVG is a very complex format, with the only real parser available being librsvg, which massively increases toolchain complexity. Too bad PostScript doesn't support transparency.
> Are there any good solutions that would convince a non-technical judge?
I feel like the best you can do is either to publish a cryptographically secure hash or to publish something encrypted and share the key/password when you want to reveal the secret.
- Immutable (or at least with edits marked as such).
- Widely trusted (or too big to be bribed in small cases, e.g., Google).
- And keep those features for many years.
Twitter was surprisingly good at that in the past, but no more. Blockchains, as mentioned in other comments, give excellent immutability; but the field is such a minefield that I'd struggle to find a trustworthy blockchain explorer.
Why would you trust only one Blockchain explorer? You'd trust the blockchain by using several explorers, and by confirming that they all agree on the same value, to assuage any fears you have about any one particular blockchain explorer lying to you. Write your own, even, if your level of confidence needs to be that high.
I'm repeating what I said above, but just send yourself an gmail with the hash in the Subject. Gmail will kindly timestamp it and provide a DKIM signature. Publish the mail headers gmail includes in the signature (which includes the timestamp and subject, but not the contents), the signature itself, and a link to hashed the document and you're done.
This is only true if Google never release old private keys for DKIM signatures, which various people have been campaigning for them to do in order to provide long-term deniability around DKIM-signed mails.
> This is only true if Google never release old private keys for DKIM signatures, which various people have been campaigning for them to do in order to provide long-term deniability around DKIM-signed mails.
> Are there any good solutions that would convince a non-technical judge?
Judges can be aided by expert reports.
And not all judges are non-technical.
The fact that you can defend your documents with timestamps is often enough: the other side won't challenge them knowing that they are likely to lose the challenge.
If you can prove the existence of the encrypted thing before some point in time than you could prove the existence of the unencrypted thing before some point in time.
There isn't any way to do this without one or more trusted third parties. Traditionally that would involve someone like a public notary or a lawyer.
I was amused to find that there is a service that cryptographically timestamps things over email via PGP that has been running since 1995:
It's common practice to have the committer not match the author (especially in environments where only patches/diffs are sent). I can't imagine the git project having any issue with that, given that the author field stays retained (ignoring this bug ofc.).
I tried to do some more research on this. Unfortunately the search combination
> rewrite commit github verified
is so insanely SEO-poisoned by (1) StackOverflow questions about how to rewrite commits and (2) GitHub’s docs about regular (built-in Git commit verification) commit verification.
But I thought about it some more. And I guess them hijacking the committer on pull request merges is not that insanely bothersome. It’s their platform after all.
Just yet another reason to not interact with forges in a way that affects Git itself.
But another thing I’ve noticed is that sometimes my committer becomes the stupid initial (legacy) email I used to sign up there. Why in the hell? My current email is already registered there. But I tested this now and at least I got the option to merge as one of my addresses. So I guess it was fixed?
> It's common practice to have the committer not match the author
When the committer and author are different people. And apparently when GitHub tries to insert itself as a pseudo-person.
I expected that my own actions would be tied to my own identity on GitHub. Not for them to shoehorn GitHub Verified™ into commit objects that I create through clickity-clacking around their UI. But it is after all their UI and they can poison commits however they like since they create it (i.e. I didn’t create it and send it to them; then I would have noticed if they tried to rewrite it). So shame on me.
> especially in environments where only patches/diffs are sent
Clearly doesn’t apply here.
> I can't imagine the git project having any issue with that, given that the author field stays retained (ignoring this bug ofc.).
Given that they don’t use GitHub for anything directly related to Git (PRs and such) and that they have their own way of indicating code provenance: No, I guess they have no reason to care. (Other than in spirit.)
But it matters in general (in spirit) that if I pick up some patch by Jack Cooper and apply it then the committer is me. Not outlook.com. Or whatever program did it for me.
The commit object has a few metadata fields. I’ve never seen anyone say, “Oh yeah sure, just use that field for whatever it’s not like it matters anyway”.
