Post A1ABZQq7VXVfcS4eqe by danielcassidy@mastodon.social
(DIR) More posts by danielcassidy@mastodon.social
(DIR) Post #A15jN7IoXO8maScTZ2 by civodul@toot.aquilenet.fr
2020-11-09T16:39:18Z
0 likes, 1 repeats
“Packaging Kubernetes for Debian”:https://lwn.net/SubscriberLink/835599/d241c1efac30e5d1/This raises key questions: bundling (“vendoring”) and its implications, contemporary #FreeSoftware development practices and their impact on distro relevance, avoiding/resolving technical disputes, and more.#Guix has answers to some issues but is otherwise in a situation similar to that of #Debian.
(DIR) Post #A15jN7VZlwLhE2afSK by civodul@toot.aquilenet.fr
2020-11-09T16:43:41Z
1 likes, 0 repeats
Regarding “modern” development practices, I’m both amazed at how much can be achieved with all these libraries at our fingertips, and scared at the idea that even distro “experts” give up on understanding how things fit together.
(DIR) Post #A15jN7wAB5cGYV1ttg by mikegerwitz@mastodon.mikegerwitz.com
2020-11-10T02:13:35Z
1 likes, 1 repeats
@civodul I see complexity as one of the modern barriers to practical software freedom. If a reasonably skilled person can't comprehend a system, one can't exercise the freedom to make any meaningful changes, letalone redistribute those changes.Projects that describe themselves as open source may not begin to consider that point.I feel a modern interpretation of software freedom requires mindfulness to complexity. Unfortunately, the backbones of modern systems are the opposite of that.
(DIR) Post #A15jN8DB9pE9PGzUQ4 by civodul@toot.aquilenet.fr
2020-11-10T11:16:39Z
0 likes, 0 repeats
@mikegerwitz Agreed.In some domains, complexity is hardly avoidable: compilers, video-editing applications, etc.But in other domains, it’s mostly an “emerging phenomenon”: developers focus on one thing and build upon a pile of software regarded as a black box. All developers do that to some extent, but this has reached the point where everyone gives up. Definitely a barrier to practical user freedom.
(DIR) Post #A15jN8UC8Yq2G2x4wS by ArneBab@rollenspiel.social
2020-11-10T11:31:11Z
0 likes, 0 repeats
@civodul @mikegerwitz after reading the article I mostly worry about people picking up development practices from a big team that manages dependencies and applying them in hobby projects. How will you ever update 30 dependencies if all you have are 5 hours per week? How will you ensure that your users get security updates? How can you actually find out that there are security updates in any of the 30 libs?That comes down to change management — and minimizing its cost.
(DIR) Post #A15jN8oku7HjHoZUzQ by ArneBab@rollenspiel.social
2020-11-10T11:37:24Z
0 likes, 0 repeats
@civodul @mikegerwitz I wrote "30 dependencies", because the 300 I wanted to write initially seemed like a stretch. Now this: https://lwn.net/Articles/836143/ — 2120 dependencies to show google-maps.As a user I certainly prefer installing only tools that are shipped in my distro. That’s why as a dev I mostly limit myself to using only the libs that are in my distro.Also those are nicer to install :-)
(DIR) Post #A15jN99JffjQJaBv2O by mikegerwitz@mastodon.mikegerwitz.com
2020-11-11T01:22:59Z
0 likes, 0 repeats
@ArneBab @civodul Yes, unfortunately it's not atypical for 100s of MiB (or even >1GiB) worth of dependencies in JavaScript projects using NPM. I can't speak to Go.This has also been a packaging headache in Guix. And for a FSDG distro, there's also the problem of trying to determine whether a program is actually free, given all of those dependencies.
(DIR) Post #A15jN9R2bluTCYU4fI by civodul@toot.aquilenet.fr
2020-11-11T13:48:30Z
1 likes, 0 repeats
@mikegerwitz @ArneBab Yeah, @cwebber explained it very well: https://dustycloud.org/blog/javascript-packaging-dystopia/Tools like NPM and Node support and encourage complexity by making it easy for developers to build gigantic dependency graphs and to ignore everything at the levels below.It’s both an “impressive” feature and an invitation to create this incomprehensible mess.
(DIR) Post #A16CM90NcQpgFUsyFU by vu3rdd@mastodon.radio
2020-11-10T04:47:32Z
0 likes, 0 repeats
@mikegerwitz So glad you mentioned this. Even some GNU software has fallen prey to complexity. Even some of the simplest programs in coreutils look complex compared to those in say OpenBSD. I understand that programs are what they are in its current form for various reasons and the needs to run in various platforms etc. But something got lost on the way.. @civodul
(DIR) Post #A16CMAqAnLr9wQ7qcK by colby@mastodon.radio
2020-11-10T10:59:39Z
0 likes, 0 repeats
@vu3rdd @mikegerwitz @civodul Absolutely this. Last year I wrote "Free software is not enough" <https://www.colbyrussell.com/2019/05/15/may-integration.html#free-software-is-not-enough>.Related: "one of the cornerstones of the FSF/GNU philosophy is that it focuses on maximizing benefit to the user. What could be more beneficial to a user of free software than ensuring that its codebase is clean and comprehensible for study and modification?" <https://www.colbyrussell.com/2019/05/15/may-integration.html#software-finishing>
(DIR) Post #A16CMBc1vQ8aKqW4DA by colby@mastodon.radio
2020-11-10T11:08:36Z
0 likes, 0 repeats
@vu3rdd @mikegerwitz @civodul when I search for other instances, I also find @jfred's post from a few months ago on the same topic, using the same phrasing. <https://jfred.dreamwidth.org/479.html>A key to pushing for solutions is to make it easy for allusions to the problem they solve to live as memes. Slogans and slogan-like turns of phrase are a form of such memes.It would be beneficial and convenient if "Free software is not enough" (or "FOSS...") became the shorthand for referencing this problem.
(DIR) Post #A16CMBy0bhibR0ncTA by mikegerwitz@mastodon.mikegerwitz.com
2020-11-11T01:34:24Z
0 likes, 0 repeats
@colby @vu3rdd @civodul @jfred Ah, thanks for sharing. I've always used "practical software freedom" informally, and I'm not sure if I've used the term publicly before or not.But there's a careful balance to be had. We can't take "practical" to mean "anyone can modify without any training". As @civodul said, some projects have inherent complexity.Some projects are also complex simply because they are poorly factored, planned, or authored.
(DIR) Post #A16CMCMp7RZGfyPR9E by jfred@mastodon.sdf.org
2020-11-11T01:43:33Z
0 likes, 0 repeats
@mikegerwitz @colby @vu3rdd @civodul Some projects, certainly - but not all!To use an example: let's say I'm using a phone dialer, and I want to make the "back" button clear all digits that have been entered when held. Simple right? So you:Find the relevant git repository, set up a build toolchain, get deps, find the relevant part of the code, make your change, build, run......why can't there be a "view source" button?The barrier to entry is much higher than it could be.
(DIR) Post #A16CMD30abJOmo97tw by mikegerwitz@mastodon.mikegerwitz.com
2020-11-11T01:53:46Z
0 likes, 0 repeats
@jfred @colby @vu3rdd @civodul The most notable project I can think of and use that has the equivalent of "view source" for complex programs is Emacs, where you can jump to the source code of any definition, even if it's part of the C sources.I agree that it could be more front-and-center. Many developers can't make it easy _for other developers_, let alone less familiar users.I've found what Guix has done with `guix envionment` to be really helpful for building software. (and `guix edit`)
(DIR) Post #A16CME46nzmnwVfWFs by jfred@mastodon.sdf.org
2020-11-11T01:57:52Z
0 likes, 0 repeats
@mikegerwitz @colby @vu3rdd @civodul Right, agreed - Emacs also does it well. Of course it has a learning curve of its own at this point, but once you're past it extending Emacs is very natural.I'd say for me personally, blurring the lines between using software and developing it is a key part of what I'd consider practical user freedom.(I didn't actually know about `guix edit`! Seems like a good step in this direction, though it also seems to open up a read-only copy of Guix at this point.)
(DIR) Post #A16CMEF698ZoUaoINs by roptat@framapiaf.org
2020-11-11T14:22:47Z
0 likes, 0 repeats
@jfred`guix build foo -S` gives you the sources for the software. `guix environment foo` drops you in an environment where all the dependencies for the software are available. :)@mikegerwitz @colby @vu3rdd @civodul
(DIR) Post #A16CMER9QKDZ5yRvAe by mikegerwitz@mastodon.mikegerwitz.com
2020-11-11T18:21:50Z
0 likes, 1 repeats
@roptat @jfred @colby @vu3rdd @civodul Indeed, `guix environment` is the really important part there. Any decent package manger will have a means to acquire sources (e.g. apt-get source in Debian), but there's usually additional steps to build it (apt-get build-deps), and then your system configuration may be insufficient for building.`guix environment` Just Works. And you can build in an isolated environment with `-C`. It's not only convenient, but wonderfully empowering.
(DIR) Post #A182anXrHrPqQPBn7I by danielcassidy@mastodon.social
2020-11-12T01:35:35Z
0 likes, 0 repeats
@ArneBab @civodul @mikegerwitz the answer to all of your questions is https://github.com/renovatebot/renovate
(DIR) Post #A182aoajOfJ9fbXbEW by mikegerwitz@mastodon.mikegerwitz.com
2020-11-12T01:49:48Z
1 likes, 0 repeats
@danielcassidy @ArneBab @civodul This seems more like an explicit recognition of how bad the problem is.
(DIR) Post #A182apLsZN1Q1pbFiq by danielcassidy@mastodon.social
2020-11-12T02:18:27Z
0 likes, 0 repeats
@mikegerwitz @ArneBab @civodul I would describe it as a repudiation of doing things the Debian way where every update is held up by the limited bandwidth of a handful of overworked volunteers and inflexible centralised policy, but I'm probably not going to change your mind.
(DIR) Post #A182apx6KynPtH0yjw by civodul@toot.aquilenet.fr
2020-11-12T08:21:27Z
1 likes, 0 repeats
@danielcassidy @ArneBab @mikegerwitz You’re right that doing things “the Debian way” doesn’t scale well.But isn’t it the price to pay to have a curated distribution that does license checks and QA?NPM, PyPI, Crates, etc. don’t do that, but their audience is developers only.
(DIR) Post #A182gOG8DEPvjuZ2A4 by ArneBab@rollenspiel.social
2020-11-12T14:11:18Z
0 likes, 0 repeats
@civodul @danielcassidy @mikegerwitz Why do you think it doesn’t scale well? Isn’t the problem rather that the money/development-time/… is going to projects instead of distributions?How many dockerfiles are totally outdated? How many projects are locked into very old dependencies? Who pushed the Python3-Updates?
(DIR) Post #A182gOW5FvB4XO1m1g by civodul@toot.aquilenet.fr
2020-11-12T14:19:32Z
0 likes, 0 repeats
@ArneBab @mikegerwitz @danielcassidy Guix and Debian packagers review every single package: licensing, integration, QA. Part of this work is manual, which necessarily limits scalability.Conversely, PyPI, NPM, Cargo, etc. do not do anything like that.
(DIR) Post #A182gOg0f17L2AfhUu by ArneBab@rollenspiel.social
2020-11-12T14:56:46Z
1 likes, 0 repeats
@civodul @mikegerwitz @danielcassidy It might be manual, but it scales well with additional people. It would be nice if there were a way to have kind of a master-list of packages where I can file a merge-request for my new library — a list from which all other kinds of package definitions can be built.guix define-public → [deb rpm ebuild pkgbuild (pypi npm cargo melpa …)]
(DIR) Post #A182gOnoC1M7QMJvea by civodul@toot.aquilenet.fr
2020-11-12T17:09:01Z
1 likes, 0 repeats
@ArneBab @danielcassidy @mikegerwitz I think that’s bound to fail. :-)Technically, it would be easy to implement “guix export” as you describe, but the result certainly wouldn’t meet the guidelines of other distros and, more importantly, distro X would never want to be a mere translation of distro Y.It’s a social issue that code cannot address.
(DIR) Post #A1ABZDspg8xHR6F8ls by cwebber@octodon.social
2020-11-11T14:01:34Z
0 likes, 0 repeats
@civodul @mikegerwitz @ArneBab At the time I wrote that, it was nearly 500 libraries to install jquery. My suspicion is that it is many more today. Somebody want to check? I'd rather not fire up the npm beast if I can avoid it :)
(DIR) Post #A1ABZMCyj7p7FtjLHc by danielcassidy@mastodon.social
2020-11-13T15:41:10Z
0 likes, 0 repeats
@cwebber @civodul @mikegerwitz @ArneBab jquery has and has always had zero dependencies on npm, so in the context of a conversation about npm encouraging dependency proliferation I'm not sure what you're basing that on, unless you're counting every element of a Debian system required to host jquery on a web server.
(DIR) Post #A1ABZQq7VXVfcS4eqe by danielcassidy@mastodon.social
2020-11-13T15:49:43Z
0 likes, 0 repeats
@cwebber @civodul @mikegerwitz @ArneBab oh, I found the article you were talking about. I see you mean you need a big pile of packages to build it.Well that's true, but insisting on building everything from scratch is a self-imposed problem, a classic example of distros making trouble for themselves and then wondering why their job is so hard.
(DIR) Post #A1ABZSuRoQ9y2S78s4 by cwebber@octodon.social
2020-11-13T16:09:38Z
0 likes, 0 repeats
@danielcassidy @civodul @mikegerwitz @ArneBab It's clear you don't care about reproducibility, but many of us do. There are both security and community-hacking-health reasons to do so.
(DIR) Post #A1ABZTlGe2PWgGpKCW by danielcassidy@mastodon.social
2020-11-13T16:17:45Z
0 likes, 0 repeats
@cwebber @civodul @mikegerwitz @ArneBab I do care about reproducibility, I just think you can verify reproducibility without tying it to unrelated packaging processes in a way that creates needless problems.
(DIR) Post #A1ABZUmMrQsvpyLiYS by cwebber@octodon.social
2020-11-13T16:20:21Z
1 likes, 0 repeats
@danielcassidy @civodul @mikegerwitz @ArneBab Okay, well if you care about reproducibility... to quote you:> Well that's true, but insisting on building everything from scratch is a self-imposed problemBut that's the definition of reproducibility right there, so...
(DIR) Post #A1AEWOwOPWvwiwFqZE by colby@mastodon.radio
2020-11-12T03:00:06Z
0 likes, 0 repeats
@cwebber @civodul @mikegerwitz @ArneBab npm-the-tool + npm-the-software-collection really do need to be reworked. (And Yarn is not that thing; Facebook is one of the most egregious offenders of package bloat.)Some Haxe folks at least have begun making an attempt to do package management differently, which can address some of the problems for the Haxe ecosystem. (The rest comes down to culture, though.)https://github.com/lix-pm/lix.client
(DIR) Post #A1AEWPI178ENo0N7Gy by colby@mastodon.radio
2020-11-12T03:03:43Z
0 likes, 0 repeats
@cwebber @civodul @mikegerwitz @ArneBab if source code hosting platforms made repo size as prominent as number of forks, it would lead to a form of social pressure all its own. I know that @codeberg and other platforms that use Gitea (and Gogs?) display this for every repo.
(DIR) Post #A1AEWPZ25rqGemKhnM by mikegerwitz@mastodon.mikegerwitz.com
2020-11-13T01:40:28Z
0 likes, 0 repeats
@colby @cwebber @civodul @ArneBab @codeberg Dependenices are not typically committed to the repo itself (they're downloaded after cloning via the package manager) and so do not contribute to the repository size.Even showing the size of the repository post-checkout isn't simple, since each package can run arbitrary scripts and perform environment/platform-specific tasks, including compilation.
(DIR) Post #A1AEWPvMkphrm2mXbc by ArneBab@rollenspiel.social
2020-11-13T18:29:07Z
1 likes, 0 repeats
@mikegerwitz @colby @cwebber @civodul @codeberg if most people ran Guix, there would be another kind of pressure: Users actually see the dependencies and how much needs to be rebuild when a single library has a security fix.