Gentoo Blogs

I wish the modern web was usably renderable by Lynx. Obviously there are still great sites which are, like HN and many tech blogs. But AFAIK none of the major platforms are particularly usable on Lynx. I have fond memories of using Lynx and third party CLI messaging apps for AIM, IRC, etc when installing Gentoo on my iMac in 2004 for my first foray into linux. X needed modifications to the Gentoo bootloader to run on my hardware so it took a month or so of assistance from people[0] on #gentoo IRC before I had GUI running. But my digital life was entirely accessible with the CLI apps and 'screen' for multitasking. Living and breathing CLI for that long really went a long way to helping me learn Linux (as well as suffering Gentoo's propensity to require make configure for everything and its excellent guides to choosing between innumerable compile-time customizations of each package). Nowadays that's very hard to do as iChat's XMPP has been replaced by iMessage's very closed system, IRC certainly isn't dead but Discord has taken front-and-center for many communities of high-interest, and websites are essentially impossible to navigate in CLI. It's not necessarily a problem with HTML, but it is a "problem" with so much being moved to React / SPA architecture. A niche problem, to be sure. But it makes me sad that other young netizens can't have the same opportunities that I did. 0: Shoutout to Joseph Jezak ( https://developers.google.com/open-source/gsoc/2006 ,…

Well said. Dynamically linked packages managed by a package manager and created and distributed by maintainers is the Linux Way of doing things for multiple very good reasons. In fact, the article brilliant describes one of them: > Modern software distribution: AKA "actually free with no-ads apps store" of the Linux and BSD worlds. That's it. That's the advantage summed up in a single description that wasn't even intended as a description of the advantages of the current way of doing things! The article has a list of "cons", but it utterly fails to consider the possibility that this overwhelming advantage of what it calls "modern software distribution" is simply and inescapably tied to the maintainer-oriented approach that currently underlies it! Attempts to create modes of distribution that are even slightly different from maintainer-distribution (think Google Play) suck ass. For all its faults, F-droid is a vastly better platform because it insists that the software must be built and distributed by an F-droid maintainer. Stepping even further away into the realm of developer built opaque binaries is begging for chaos and misery. As you say, it's ultimately a security concern [1]. The article claims that a change is necessary because of "increased usage of languages and run-times that don't fit the current build model", "some of these new projects have large numbers ... of dependencies", but these are themselves problems with modern software development. Even putting…

So this is non issue you say? https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to…

See also on the same general topic: “The modern packager’s security nightmare” (2021) [1] by Gentoo maintainer Michał Górny, and Drew DeVault’s posts on why FOSS developers should not distribute software directly or try to impose their will on distros[2,3]. [1] https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-securi… discussed at https://news.ycombinator.com/item?id=26203853 (320 points, 278 comments) [2] https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html… no notable HN discussions [3] https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html, no notable HN discussions

Not only does the guide not mention it, it seems to actively disagree with you: > The cargo-outdated tool must be used to check dependencies status. Then, each outdated dependency must be updated or the choice of the version must be justified. Especially for open source projects, there are also some other arguments against vendoring, see e.g. https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-securi… If there's something that's missing mention, it is imho that the Cargo.lock files should be committed, and also included e.g. in docker builds. (I don't believe in offhanded "cargo update". And even if you did accidentally type it, nothing will be built/executed yet. There's ample opportunity to git restore Cargo.lock.)

I read this interesting article recently about all the security problems that static linking, bundling and pinning cause for Linux distributions: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-securi…

https://blogs.gentoo.org/lu_zero/2015/02/20/demotivation-fud-and-why-i… My take.

I suggest take a look at a different point of view (https://blogs.gentoo.org/lu_zero/2015/02/20/demotivation-fud-and-why-i… This post is from someone involved in libav but it refers to the different public e-mails that were exchanged when the fork was originated and they document factually things (at least, as far as I can understand)

Thanks; we changed to that from http://blogs.gentoo.org/blueness/2014/10/03/sthttpd-a-very-tiny-and-ve… which is down.

My point is that your argument is comparable to faulting Ford for making cars disposable with crumple zones when nobody else has found a better way to meet the crash-safety requirements while satisfying the other requirements too. As for "and also not that Rust's design makes it more difficult to package", give https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx-templates… a read. TL;DR: It's not a Rust thing. C++ suffers from the same problem when you use templates in your APIs... it just emits a .so file with no contents if you expose only templated APIs. It's fundamentally a problem of "Unless you're willing to spend Swift-level engineering money and still accept compromises Rust and C++ can't afford, dynamic linking in the presence of monomorphic generics is a problem even research languages haven't solved". ...same as the warts in async Rust. What you're seeing is a cutting-edge language slamming up against the limitations of what cutting-edge programming language research has figured out. At least, with Rust, you've still got the dependency tracking and automatic RUSTSEC advisory tooling you don't get with header-only C libraries.

Impressive trolling. > deepSeq is basically useless because of how almost every datastructure is ciruclar Circular references will cause "infinite recursion", and these will cause evaluation errors. So valid nix code will not contain circular references. Compositions of derivations create merkel DAGs. There are also fixed points, but deepSeq can still handle those scenarios. > trace is almost useless because you can never know if a statement is a value or a computation. use of trace creates a thunk. So it will always be a thunk. > Derivations actually put something in your store when you evaluate them. No. Instantiation will create store derivations, realizations will perform a build, and successful builds create store paths. `nix-instantiate '<nixpkgs>' --eval -A hello.version` Evaluates the expression, but doesn't produce a store derivation. > Except that I don't need to know this for apt or any other package manager. You're also probably not creating your own .deb's. You would seek other options. > Nix is the only one that forces me to learn endless minutia about every single language. Eventually you will to learn your problem domain. Just because you do python dev on ubuntu, doesn't eventually you will eventually need to know how python finds modules. > Haha. HAHA. HAHHAHAHAHHA. Oh sorry. That wasn't laughter. That was me trying to hide my tears. Hmm, I can't see your face. So don't worry about saving it. > show-trace is about as useless of an addition as I…