I can count on one hand the number of monitors I've seen with auto brightness. The number of monitors with acceptable and non distracting auto brightness is zero.
I mean, if you have a modern digital display you might be able to change the brightness through the DDC/CI protocol and a simple app or extension, available in every much every OS. With a keyboard shortcut or two clicks you change it. Fiddle with monitor settings is painful, but that protocol is a godsend. Even one of my cheapest 13 years old monitor supports it.
Finnish case markers vary a lot from word to word, because of not only vowel harmony but other features of the word stem, and consonant gradation which is a weird feature of Uralic languages.
For the subtraction example, some numbers would be 50:tä 5:llä and others 6:tta 3:lla. Of course you could encode for all those possibilities and successfully parse them, but it would feel weird for a compiler to reject an expression because it's ungrammatical Finnish.
Also it would feel weird if you first write (vähennä muuttujaa 256:lla) but then realise you made an off-by-1 and have to change it to (vähennä muuttujaa 255:lla) but that doesn't compile because it should be 255:llä, so you have to remember to change two things.
But on the other hand, that's just how it is to write in Finnish, so in prose we don't really think about it. In natural language, it's normal to have to change other stuff in a sentence for it to continue making sense when you change one thing.
Not sure I follow. Suppose you tore out a portion of libxml2 for use in your HTTP server. A CVE is filed against libxml2 that is related to the subset you tore out. Obviously, your server doesn't link against libxml2. How exactly would distro maintainers know to include your package in their list?
I believe some distros require un-vendoring before accepting the package.
If the code you vendored was well hidden so the distro maintainer didn't notice, perhaps the bad guys would also fail to realize you were using (for instance) libxml2, and not consider your software a target for attack.
That's assuming you're using dynamically linked libraries/shared libraries. They're talking about "vendoring" the library into a statically linked binary or its own app-specific DLL.
In theory yes, but in practice I don't think you could build something like Servo very easily like that. Servo is a browser, but it's also purposefully designed to be a browser-developer's toolkit. It is very modular, and lots of pieces (like the aforementioned CSS selector library) are broken out into separate packages that anyone can then use in other projects. And Servo isn't alone in this.
However, when you install Servo, you just install a single artefact. You don't need to juggle different versions of these different packages to make sure they're all compatible with each other, because the Servo team have already done that and compiled the result as a single static binary.
This creates a lot of flexibility. If the Servo maintainers think they need to make a breaking change somewhere, they can just do that without breaking things for other people. They depend internally on the newer version, but other projects can still continue using the older version, and end-users and distros don't need to worry about how best to package the two incompatible versions and how to make sure that the right ones are installed, because it's all statically built.
And it's like this all the way down. The regex crate is a fairly standard package in the ecosystem for working with regexes, and most people will just depend on it directly if they need that functionality. But again, it's not just a regex library, but a toolkit made up of the parts needed to build a regex library, and if you only need some of those parts (maybe fast substring matching, or a regex parser without the implementation), then those are available. They're all maintained by the same person, but split up in a way that makes the package very flexible for others to take exactly what they need.
In theory, all this is possible with traditional distro packages, but in practice, you almost never actually see this level of modularity because of all the complexity it brings. With Rust, an application can easily lock its dependencies, and only upgrade on its own time when needed (or when security updates are needed). But with the traditional model, the developers of an application can't really rely on the exact versions of dependencies being installed - instead, they need to trust that the distro maintainers have put together compatible versions of everything, and that the result works. And when something goes wrong, the developers also need to figure out which versions exactly were involved, and whether the problem exists only with a certain combination of dependencies, or is a general application problem.
All this means that it's unlikely that Servo would exist in its current form if it were packaged and distributed under the traditional package manager system, because that would create so much more work for everyone involved.
On mine, I don't. Any interactivity is too much hassle for me to worry about wrt moderation etc. I also don't particularly care what random people have to say. If my friends like what I wrote, they can tell me on Signal or comment on the Bluesky post when I share the link.
reply