I consider bootloader attacks a very low-probability threat, and quite honestly I don't trust the average board vendor to produce anything that's actually secure anyway. If I were in the habit of carrying a laptop back and forth across international borders I might feel differently, but for a desktop stuck in a room in Canada that hardly anyone enters when I'm not present, Secure Boot is a major hassle in return for a small security gain. So I just don't bother.
nyan
joined 9 months ago
Dude, I've worked with all these interpreters. The JVM's startup is slow, although there's been some improvement since the version 1.1 that I started out with. The interpreter speed is quite good once it gets going, so it remains a good choice for long-running or interactive programs where the startup is insignificant as a fraction of total program run-time, but if you're running a script that takes only a fraction of a second to execute, the JVM's startup can lengthen the time by an order of magnitude or more. Horses for courses and all that—I wouldn't write a complex interactive GUI program in Perl, either.
Technically, you could bundle a Perl script with the interpreter on another system using pp and run the packed version on systems with no installed Perl, but at that point you might as well just use a compiled language.
Last I checked, the JVM was larger than the standard Perl and Python interpreters, and had a much worse startup time (which is bad for short scripts).
If it really is a .doc file and written in an ASCII-compatible encoding as most English-language documents are, opening it in a hex editor (or a non-codepage-aware text editor like the Notepad on a W10 or earlier Windows machine) will show an indecipherable proprietary header followed by the text in the file, possibly with a single space or "junk" character between each letter depending on the exact version of Word and system encoding it was written with. There may be occasional additional stretches of markup junk. At the end, there will be a footer with occasional decipherable text strings like "MSWordDoc" and font names.
If you open a .docx file in such a program, you should get a typical zipfile signature: the letters "PK" at the beginning of the file, followed by a lot of gobbledegook. If you don't get that "PK", it probably isn't a .docx.
(I've looked at a lot of MS file guts, for both curiosity and information extraction purposes.)
Because they don't want ignorant end users to blame them if the ancient, unpatched version of GRUB that's at issue is used as part of an exploit attacking Windows boxes.
I wonder if there's a Gentoo binpkg host for i486 specifically, since it might almost be practical then. (Or you could set up your own.)
Also out of the loop, but my guess is that Wayland hasn't defined a specific API for the purpose yet, and their security model doesn't allow programs to see the content of other programs' windows. X11 doesn't attempt to keep programs from seeing what other programs put on screen, so no specific API is needed there.
Actually, if you check deep down in the list of installables, you'll find that Gentoo still supports the even less capable i486 variant. A laptop from 2010 is positively a spring chicken compared to some of the things it can be made to run on. Itanium is only being desupported because it's being dropped upstream by the kernel and other chunks of the toolchain (and the only actual hardware they had to test on died a while ago).
I only need it for the very occasional testing of open-source software on Windows, using the precanned VM images provided by Microsoft (last I checked, they had none for qemu, or I would be using that instead). And if you're using software commercially, you'd better be damned sure you understand the licensing before setting up. A company of any size will have lawyers vetting that anyway.
In other words, I don't disagree with you, but those issues don't matter for my use case.
TDE has had occasional discussion and ruminations, but no action yet. Porting it is complicated by the fact that it has its own widget set (TQT, forked from QT3), which would have to be worked on first and is currently undergoing some unrelated rewriting.
The likelihood of any wayland milestones for TDE being set before the end of 2024 is very low unless some major distro completely drops X support.