sp1rit

Materialistic[0] effectively does this (minus the screenshot part), not intentional I think (I belive it makes the webview as tall as the requested page and then uses the OS native scroll widget to add a scrollbar for it). The problem I regularly encounter with this is sites that have a vertically centered popup (cookie banner, newsletter, etc.), with a backdrop that obscures the whole page. You first have to scroll down quite a bit (half the size of the article) to be able to click the popup away.

[0]:https://github.com/hidroh/materialistic

I wonder who is behind this sudden push for these age verification laws. This wasn't an issue until recently and suddenly there are not just laws in California and Colorado, but also New York and Brazil.

I quite dislike the defer syntax. IMO the cleanup attribute is the much nicer method of dealing with RAII in C.

> Static libraries have lots of game-changing advantages, but performance, security, and portability are the biggest ones.

No idea how you come to that conclusion, as they are definitively no more secure than shared libraries. Rather the opposite is true, given that you (as end user) are usually able to replace a shared library with a newer version, in order to fix security issues. Better portability is also questionable, but I guess it depends on your definition of portable.

> Why the heck would the application for the German passport or Ausweis be published by some random GmbH and not Bundesregierung.gov?

This way the government doesn't have to release information to the public (think FOIA) about it. Moving central part of government operation into a private GmbH wholly owned by the government has (sadly IMHO) become a somewhat common strategy for the government. Not just Governikus (the one with the passport) but also the Telematik (Health system) and probably some more.

It looks like VVC (H.266) will be significantly better compared to HVEC and AV1. But due to the patent issues it'll bound to have, I suspect common usage will practically be nonexistent, just like HVEC.

Yes, as unsigned overflow is fine by default. AFAIK the issue was originally that there were still machines that used ones complement for describing negative integers instead of the now customary twos complement.

> since it's .NET you can embed the runtime in any .NET application

not actually "embedded", more like a bit of shim code that extracts the runtime into some temporary directory that then runs the actual code.

Upstream is https://gitlab.freedesktop.org/pixman/pixman

They absolutely know about this, given that the seemingly reworked markers for this tablet have a redesigned nib holder that doesn't look like it breaks as easily as the old ones. This is a common enough issue that there are people on ebay selling caps to replace the broken nib holder, but they seem to expensive for what amounts to a piece of 3D-printed plastic; I might just look into your solution with the lamy pen. It's just a shame that reMarkable is handling those issues so badly. They force you to buy a new pen for $130 because a little piece of broken plastic.

Still, if you include transitive dependencies you end up with a total of 90 dependencies[0] which is unheard of in systems programming. This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools.

[0]:https://github.com/gentoo/gentoo/blob/master/sys-fs/bcachefs...

I wonder how this behaves in combination with __attribute__((cleanup(...))). Especially if the to be cleaned variable is passed into the tail function as parameter.

Reminds me a lot of Emblem[0]

[0]:https://apps.gnome.org/Emblem/

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.

You can usually with not having the initial part. As long as you do call the exit syscall, it should work.

> 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.

No, this needs libfprint-tod[0], which is built do dlopen non-free reader libraries from manufacturers.

[0]:https://gitlab.freedesktop.org/3v1n0/libfprint/

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.

[0]:https://docs.gtk.org/glib/auto-cleanup.html

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?

>> As a normal part of the just-in-time compile and execute cycle

This means a workaround is running java with -Djava.compiler=NONE, no?

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.

[0]:https://www.x.org/releases/X11R7.7/doc/man/man3/Xcursor.3.xh...

> 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.

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.).

You could probably write a custom git credential helper that does that, if it doesn't exist already.

You'd still have to parse & compile the contents of the header for each translation unit, instead of only once.

If you can use GCC to target all platforms, you can build with -std=gnu++XX to use C-like initializers.

I don't know what EPP provides (I doubt it'll help you in this case), but AFAIK least ClamAV only matches against known signatures (almost exclusively windows malware), so it can't detect newly created malware.

To protect a system, the only really reasonable approach is to not run code/binaries you don't trust. Once malicious software capable of writing files in ~, it's too late (those new sandboxing solutions are also not really solving this, as their interfaces to access files suck, so everyone continues to use the posix api with full access).

The only "Linux system" that can be considered secure in that regard is Android, as you don't have software that tries to execute "random" stuff in ~ and Apps tend to get away with using SQLite (not exposed to the user) over complex filesystem structures. Obv. you used to be able to access ~ rw, so malware could still upload/encrypt your Data, but most Users only have Pictures there (as other data was only stored in app-only storage [/data/data/<id>/] that couldn't be accessed by anyone else). Now you don't even have access to that, so malware is even more limited (but obv. legitimate software also suffered from that, for example WhatsApp used to store it's data there in ~/WhatsApp/ so you could simply access media sent/received on chat but now its far more hidden).

Well, it depends on what you consider "properly configured". But I'd say most systems used by developers aren't secured against these attacks. This mostly boils down to (like discussed elsewhere in this thread) that the developer runs his tools as his user, thus malicious software can modify his .bashrc and using that hijack a later sudo invocation to gain full access.

The thing that "protects" you is package locking, where unless you explicitly update your packages, you'll stay on an uncomprimised version (this broke with leftpad, as every available version was deleted). Locking has the downside that you don't get security updates for your software, which might be even more harmful tho.

> your package manager that uses TLS would be vulnerable most distro package managers (dpkg, rpm, etc.) tend to use gpg which shouldn't suffer from those issues (but they could obviously still have some sort of other backdoor for gpg).

Still, I feel like distro packages are really secured compared to stuff you install via pip/npm/... as I don't believe they do anything beyond protecting downloads with TLS.