> 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.
I think from a security point of view, if a program is linked to its library dynamically, a malicious actor could replace the original library without the user noticing, by just setting the LD_LIBRARY_PATH to point to the malicious library. That wouldn't be possible with a program that is statically linked.
And unless you're in one of those happy jurisdictions where digital rights are respected, that malicious threat actor could range from a mundane cyber criminal to and advanced persistent threat, and that advanced persistent threat could trivially be your own government. Witness, the only part of `glibc` that really throws a fit if you yank it's ability to get silently replaced via `soname` is DNS resolution.
You act as though the sales pitch for dynamically loaded shared libs is the whole story.
Obviously everything has some reason it was ever invented, and so there is a reason dynamic linking was invented too, and so congratulations, you have recited that reason.
A trivial and immediate counter example though is that a hacker is able to replace your awesome updated library just as easily with their own holed one, because it is loaded on the fly at run-time and the loading mechanism has lots of configurability and lots of attack surface. It actually enables attacks that wouldn't otherwise exist.
And a self contained object is inherently more portable than one with dependencies that might be either missing or incorrect at run time.
There is no simple single best idea for anything. There are various ideas with their various advantages and disadvantages, and you use whichever best services your priorities of the moment. The advantages of dynamic libs and the advantages of static both exist and sometimes you want one and sometimes you want the other.
A hacker can easily replace your shared library with their own malicious version or intercept calls into one as needed. As the number of distinct binary blobs for an application increases, the surface area for attack vectors increases making security a nightmare. Every piece also needs to be individually signed and authenticated adding more complexity to the application deployment.
As the gp mentioned, Static libraries have a lot of advantages by having only one binary to sign, authenticate and lockdown/test/prove the public interface. The idea is extended into the "Unikernel" approach where even the OS becomes part of the single binary which is then deployed to bare-metal (embedded systems) or a Hypervisor.
Knowing what code runs when i invoke an executable or grant it permissions is a fucking prerequisite for any kind of fucking security.
Portability is to any fucking kernel in a decade at the ABI level.
You dont sound stupid, which means youre being dishonest. Take it somewhere else before this gets okd school Linus.
I have no fucking patience when it comes to eirher Drepper and his goons or the useful idiots parroting that tripe at the expense of less technical people.
edit: I don't like losing my temper anywhere, especially in a community where I go way back. I'd like to clarify that I see this very much in terms of people with power (technical sophistication) and their relationship to people who are more vulnerable (those lacking that sophistication) in matters of extremely high stakes. The stakes at the low end are the cost and availability of computing. The high end is as much oppressive regime warrantless wiretap Gestapo shit as you want to think about.
Hackers have a responsibility to those less technical.
> 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.
> I suspect common usage will practically be nonexistent, just like HVEC
HEVC is used in all TV broadcast station. FaceTime and other Cameras, Netflix, Amazon Prime, Disney+ and many other large streaming services outside US. The only one that doesn't have any usage of HEVC is Youtube.
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.
Not sure what you mean? I've hosted powershell in C# code by referencing Microsoft.Powershell.Sdk - it pulls in the dll at compile time and runs on whatever .Net runtime that is installed and matches the project target.
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.
Not sure if country of residence makes any difference (I’m in EU), but at least I got a new pen from warranty when the nib holder broke. And I think it was even little over 2 years after the purchase.
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.
> with a total of 90 dependencies[0] which is unheard of in systems programming
If the comparison is with C/C++ then the comparison is flawed:
- some you would never see in C/C++ because there's no point to them (e.g. safe bindings to system libraries)
- some are the same dependency but split in multiple crates to improve compile times (e.g. `anstyle`, `clap` and `regex`)
- some in C/C++ would just be vendored due to the difficulty of package management (see for example [0])
> This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools.
I don't know how Gentoo's build system works, but Cargo resolves the versions for *all dependencies*, including those that are conditionally compiled (e.g. based on the target OS). This is because the `Cargo.lock` file, which contains the actual dependencies versions used, is supposed to be versioned in e.g. git, and thus needs to be cross platform and be the same for everyone compiling the crate.
The winapi dependency comes from the rust tooling (cargo specifically) putting a great value on portability, and practical concerns like people collaborating from different platforms on the same project. Many Rust projects check their Cargo.lock into git (recommended for binaries, and also many libraries do it). Now imagine if the Cargo.lock changes depending on the platform, which one would you track in git?
Now, there is the separate concern of cargo-vendor downloading the winapi crate, which it does, also on Linux. It doesn't have to because winapi is never built, yet it still does it. That one I agree is a bit wasteful, but it's a known issue.
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.
You get an error that tail call can't be performed which is kind of the point of tailcall attribute. Same thing with regular c++ destructors or dozen other language features which interfere with tail calls, no need for extensions like __attribute__((cleanup()).
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.