Developer-driven software distribution is a bad idea, which is why I dislike things like Flatpak.
Having distro maintainers involved in the process and installing your software from a free software distribution like Debian or FreeBSD is a much better distribution of power. The packages can be tuned to suit their environment without the developer having to repackage it for every distro, and the distro maintainers can keep out anti-features like telemetry and advertising.
The middleman may seem annoying to developers, but embrace the model and it'll work for you. Landing packages in your favorite distro isn't actually that hard, and the rest of the distros will follow. If you're an end-user who wants to see some software available for your distro, look into packaging and volunteer - it's easy.
like this
reshared this
Drew DeVault
in reply to Drew DeVault • •Elena ``of Valhalla'' likes this.
federico reshared this.
Drew DeVault
in reply to Drew DeVault • •Drew DeVault
in reply to Drew DeVault • •(basically, fuck flatpak)
Antonino Siena
in reply to Drew DeVault • •Haelwenn /элвэн/ :triskell:
in reply to Antonino Siena • •Antonino Siena
in reply to Haelwenn /элвэн/ :triskell: • •Drew DeVault
in reply to Antonino Siena • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
Wolf480pl
in reply to Drew DeVault • •>The middleman may seem annoying to developers
which is a good thing ;)
Brian Pepple
in reply to Drew DeVault • •Paul Sadauskas ✊ Resist
in reply to Drew DeVault • •as a Ruby app developer, it seems odd to me that I would find Ruby gems in the Fedora package manager. As a Ruby gem maintainer, I wouldn't want to burden distro maintainers every time I release a new version.
Do distro package managers even have features like version pinning? Seems like the repos are stuck with the major version that was out when the distro was released, and in a fast-moving world like web app development, you'd be hamstrung to old gem or npm versions.
Drew DeVault
in reply to Paul Sadauskas ✊ Resist • •Drew DeVault
in reply to Drew DeVault • •Paul Sadauskas ✊ Resist
in reply to Drew DeVault • •Paul Sadauskas ✊ Resist
in reply to Drew DeVault • •Drew DeVault
in reply to Paul Sadauskas ✊ Resist • •Paul Sadauskas ✊ Resist
in reply to Drew DeVault • •Drew DeVault
in reply to Paul Sadauskas ✊ Resist • •read-only account (Rain 🚱)
in reply to Paul Sadauskas ✊ Resist • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to read-only account (Rain 🚱) • •@Rain 🚱 @Drew DeVault @Paul Sadauskas Nix works great on MacOS, it's my main package source for non-Mac-y things there.
I have zero need for macports or fink these days, and get only a handful of Cocoa things from Homebrew, or actually mostly from Homebrew Cask.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to read-only account (Rain 🚱) • •@Rain 🚱 @Drew DeVault @Paul Sadauskas The importer situation on Nix is pretty bad. Every new language reinvents the wheel and code reuse is low because the documentation is sparse.
When I can create the time to work on racket2nix again, I hope to generalize a few things and reduce the fragmentation, but I can't say which year that would be.
Elena ``of Valhalla''
in reply to Paul Sadauskas ✊ Resist • •As a (python) developer and a distro maintainer.
In many cases, upgrading a package to a new version isn't a big deal: most of the time is taken by giving a quick review of the code to check that upstream hasn't gone insane :) and then it's a matter of running a few commands to upgrade the package and run tests to check that everything is still working. This is especially true for packages that release relatively often and don't change everything from one release to the next, of course, but many python modules are like that, and I supposed ruby gems are too?
As for version pinning, yes, with stable distributions you are basically pinned to the version available when the distro was released and get no new features, but you do get security fixes (when possible, and when the maintainer gets to know that there is a need for one). On the other hand, it also means that you can be sure that your software will not break until the next *predictable* distribution release.
It is true that as a developer I tend to work on things that are supposed to be maintained for years with minimal developer effort (because there isn't a developer working full-time on them), so I'm especially uncomfortable with the common web approach where you have to either rewrite your code every other month to keep it working with your dependencies or keep it stuck on the version that was out when you wrote the code even if it has known security vulnerabilities.
Paul Sadauskas ✊ Resist
in reply to Elena ``of Valhalla'' • •Elena ``of Valhalla''
in reply to Paul Sadauskas ✊ Resist • •The distro tooling only influences the availability of those modules that are specific to distro work: on pypi there are lots of packages that are not available inside distributions, some of which are indeed quite useful. I don't have numbers, I just have the experience that finding a module that does what you need and is not in debian is not that unusual (and in a handful of cases it wasn't in debian until I needed it).
And the majority of python developers tend to just get everything from pypi because it's convenient, like developers in other languages do with their own repos.
Neal Gompa (ニール・ゴンパ) :fedora:
in reply to Paul Sadauskas ✊ Resist • •Paul Sadauskas ✊ Resist
in reply to Elena ``of Valhalla'' • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
Drew DeVault
in reply to Paul Sadauskas ✊ Resist • •federico reshared this.
Paul Sadauskas ✊ Resist
in reply to Drew DeVault • •Drew DeVault
in reply to Paul Sadauskas ✊ Resist • •reshared this
federico reshared this.
Neal Gompa (ニール・ゴンパ) :fedora:
in reply to Paul Sadauskas ✊ Resist • •Çağatay Yiğit Şahin
in reply to Drew DeVault • •For the anti-feature point, if you have problems with the source, you should fork it, not pretend you are distributing the app while in reality you are distributing something else.
Drew DeVault
in reply to Çağatay Yiğit Şahin • •federico reshared this.
Çağatay Yiğit Şahin
in reply to Drew DeVault • •Seriously, I don't maintain any apps. Even if your reply was in good faith, it is incorrect.
Second, it was clear in my first reply: just fork it. It will "hold me accountable." Who is not accountable is the maintainer who changes the code while not changing the brand. The one who should be accountable for the resulting errors is the maintainer but often the user does not know because the downstream is using the upstream's brand.
read-only account (Rain 🚱)
in reply to Çağatay Yiğit Şahin • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
Drew DeVault
in reply to read-only account (Rain 🚱) • •read-only account (Rain 🚱)
in reply to Drew DeVault • •And its developers aren't elitists who joke about mentally ill homeless people.
Call me when another distro gets an equivalent of `guix environment`.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
Drew DeVault
in reply to read-only account (Rain 🚱) • •read-only account (Rain 🚱)
in reply to Drew DeVault • •Drew DeVault
in reply to read-only account (Rain 🚱) • •read-only account (Rain 🚱)
in reply to Drew DeVault • •Drew DeVault
in reply to read-only account (Rain 🚱) • •read-only account (Rain 🚱)
in reply to Drew DeVault • •Drew DeVault
in reply to read-only account (Rain 🚱) • •read-only account (Rain 🚱)
in reply to Drew DeVault • •Ah well. I think most people will like them.
Drew DeVault
in reply to read-only account (Rain 🚱) • •Franz Geffke
in reply to Drew DeVault • •read-only account (Rain 🚱)
in reply to Franz Geffke • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to read-only account (Rain 🚱) • •@Rain 🚱 @Çağatay Yiğit Şahin @Drew DeVault @Franz Geffke The major difference between language-specific package managers and guix/nix is that the former generally:
- Work out of the box on Windows
- Are installable by non-root in an arbitrary location
I believe that at least one of buck/pants/bazel do this to some extent already today for some languages.
I hope we can one day have a guix-lite that while giving up on some features of full guix can fulfill the above two requirements and make cross-language deps normal rather than fringe, and stop new languages from inventing the 847th wheel.
And, of course, it should fit well with guix-full so that a real guix can benefit from the packaging work done for devs.
read-only account (Rain 🚱)
in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 • •hpc.guix.info/blog/2017/10/usi…
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to read-only account (Rain 🚱) • •@Rain 🚱 @Çağatay Yiğit Şahin @Drew DeVault @Franz Geffke Cool! So both Nix and Guix support PRoot. It's a bit awkward, but it checks the box.
Still need to cover all those Python devs on Windows. But maybe all of them will be on Linux on Windows sooner or later.
Neal Gompa (ニール・ゴンパ) :fedora:
in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to Neal Gompa (ニール・ゴンパ) :fedora: • •@Neal Gompa (ニール・ゴンパ) :fedora: dnf on Windows using minipix? Now I've heard everything.
I hope Windows doesn't become a usable development platform before most of the devs have moved to Linux already.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 • •Wu Wei :xfce: :rss: :terminal:
in reply to Drew DeVault • •codesections
in reply to Drew DeVault • •> I'll take 90% the stability for 10% the complexity any day of the week.
Yeah, me too if it's reducing complexity by 90% in return for reducing stability by 10%.
Out of curiosity, how much increased complexity (if any) would you accept for 10% more stability?
(Not that I have any idea how to measure either in practice…)
Drew DeVault
in reply to codesections • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to read-only account (Rain 🚱) • •Çağatay Yiğit Şahin
in reply to read-only account (Rain 🚱) • •gist.github.com/cagatay-y/8f0e…
Drew DeVault
Unknown parent • •bugmenot
in reply to Drew DeVault • •I get where you're coming from, but I don't agree on the middleman with you here, @sir.
The point of the distro is not to safeguard the user from upstream misfeatures. That's not why the distros arose in the first place. A software entry barrier is a mere byproduct.
Certain distros will go beyond providing you with the base system, true. I think Debian is the one which stores patches for upstream code when the publisher avoids addressing his users' demands.
Arch and Alpine will only recommend pristine upstream software, even if that introduces hostile functionality. The rationale is that, once the program is popular enough, not having it is a strike against the distro. And they can't go the Debian way either, for that will violate the design principles.
Offhandedly, it is simply a false claim that packaging software for your distro is easy as an entrant contributor. Sure, if you lack social credit, you can go the AUR way, but that is unsupported content and therefore can't be in any way considered part of software distribution. At which point we're back at square one, if users want to get the software, they'll have to ask the upstream.
Drew DeVault
in reply to bugmenot • •I don't agree with any of this, except what distros were originally for - though not the implication that they need to still serve that original mission in order to be useful.
Arch tries for pristine upstream stuff, but Alpine is no stranger to patches when appropriate. No one is thinking about upstream software popularity's influence on downstream distro popularity, that has never been a problem for any distro.
And I also disagree that packaging is inaccessible. On Alpine at least, which is the distro I focus on, it's extremely easy.
bugmenot
in reply to Drew DeVault • •>though not the implication that they need to still serve that original mission in order to be useful.
I don't know what this actually means (what you're accusing me of) but I'm in favor of distros taking on tasks that help their users.
>On Alpine at least, which is the distro I focus on, it's extremely easy.
So a total stranger, can just get in touch with Alpine devs to package stuff that interests him? No vouching, no laundry lists, etc?
That is to say, I've known you primarily as an Arch user.
>No one is thinking about upstream software popularity's influence on downstream distro popularity
That doesn't apply to Web Browser packagers in general and distros, which strive to break free from proprietary software, will still package it in a separate repo making it clear it's only because users demand it.
Drew DeVault
in reply to bugmenot • •you can make your own package trivially for Alpine, docs exist to help you and I'm sure you'd get help on IRC if you asked for it, and then sending it upstream is as easy as a gitlab MR or email to the appropriate mailing list.
I don't know what you're talking about with respect to web browsers.
bugmenot
in reply to Drew DeVault • •Help and IRC don't belong in the same sentence. At least that's my experience with any kind of IM. Self-help all the way!
Devs will package Web Browsers because users will complain if they're absent. Look at Arch's PKGBUILD for Firefox. It contains references to unique browsing trackers. Not cool they've to go to these lengths to be able to provide the software to their users.
Drew DeVault
in reply to bugmenot • •oh, you can shove it, IRC is great and it's your own damn fault for not reaching out on it.
And it's very cool that Arch Linux is in a position to remove telemetry crapware from Firefox. That's the whole fucking point behind my argument.
bugmenot
in reply to Drew DeVault • •>And it's very cool that Arch Linux is in a position to remove telemetry crapware from Firefox. That's the whole fucking point behind my argument.
My point is they ain't doing that. They do the opposite.
>oh, you can shove it, IRC is great and it's your own damn fault for not reaching out on it.
That was your experience. A person with no credibility will find himself isolated on IRC.
Also, how Alpine deals with situational package contributors? Let's say a package breaks and the packager is nowhere to be found. Do they just strike it off the list and ban the (ir)responsible person?
Drew DeVault
in reply to bugmenot • •IRC has nothing to do with credibility. If you ask your questions politely and wait patiently for an answer, you will get one. You're talking about some strange social credit system which simply doesn't exist.
As for absentee maintainers, packages may eventually be moved into the unmaintained repo, or another volunteer will jump in. The contributor is not banned for abandoning a package, yeesh, everyone understand that we've all got shit to do. There are tools for auditing the staleness of packages.
bugmenot
in reply to Drew DeVault • •Being genuflex and waiting for days didn't cut it for me. I usually got a few fleeting responses then silence. That being said, I am interested in obscure stuff, so YMMV.
I'll try Alpine even though I see a few roadblocks already. I respect their vision but it doesn't mean it's the right choice for everything.
Be gay do crimes
in reply to Drew DeVault • •Opensource social credit system tends to be opaque and deniable. Once the project reaches a certain milestone or a critical threshold some aspects of it start to become more enshrined. No use digging our heads in the sand about that one.
I see reason behind excommunication process. The community was trusting you to be there when it breaks. You wasn't, so no one wants to deal with you anymore and waste their time. This also encourages maintainers to seek replacement for themselves
Drew DeVault
in reply to Be gay do crimes • •Be gay do crimes
in reply to Drew DeVault • •apotropaic plush connoiseur
in reply to bugmenot • •Drew DeVault
in reply to apotropaic plush connoiseur • •apotropaic plush connoiseur
in reply to Drew DeVault • •Drew DeVault
in reply to apotropaic plush connoiseur • •avocado goblin
in reply to Drew DeVault • •Elena ``of Valhalla''
in reply to bugmenot • •On Debian (the distro I know best) anybody can prepare a package and submit it for inclusion into the distribution: it will then be reviewed by debian developers who will (usually) suggest a number of fixes to bring the package up to the high standards of the distribution and then, if those have been applied, one of those developers will sponsor the package in the distribution.
People must be willing to actually maintain the package and not just submit it once and then disappear, and I admit that there are areas where it's easy to find a sponsor and other where there may be none (software written in languages few people know, and/or targeting very specific use-cases).
This is however a well-established and generally nicely working way for somebody that is completely unknown to start getting social credit and eventually become a debian developer themselves.
(terminology note: because of decades of history, debian developers aren't simply people who work on debian, but it's the term for people with access to debian infrastructure and systemwide package upload permissions (the latter unless they are non-uploading debian developers). debian maintainers aren't those who maintain packages, but people with limited upload permissions, usually as a temporary step on the way to become developers. Yes, it is confusing. That's what you get when a project grows and changes with time.)
bugmenot
in reply to Elena ``of Valhalla'' • •Debian's process seems to resemble open source development model. Arch is somewhat different, your options are either a third-party repo or applying for a TU status. I suspect the third way is to ask a TU to "adopt" your package, though I'm not aware of any willing to take on someone else's burdens.
If the goal is to package Node programs and their deps like @sir suggests instead of defaulting on npm, I can imagine being in for a lot of frustration trying to convince Debian's maintainers to accept all this mess one by one.
federico
in reply to Drew DeVault • •I’ve done quite a bit of packaging as a Debian developer, and inside Amazon (yes, the company uses OS packages), as a SuSE and HPE employee.
It is sad to see how uncooperative upstream developers can be, mostly due to myths around software lifecycle and the needs of end users.
Most software in the world is developed -> built -> distributed -> integrated -> deployed & mantained -> used by 4 to 6 different individuals/entities. Often different organizations.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
federico
in reply to Drew DeVault • •Software distributed with shorter “chains” is the minority and the majority of software and hardware deployed in the world lives for many years.
Unfortunately there’s some disconnect between these lifecycles and the ones known by the most vocal crowd of developers on the Internet.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
federico
in reply to Drew DeVault • •Compile-time and run-time dependencies should be unbundled from sources to allow maintainers and system engineers to update components independently.
Software should be modular where reasonable: allow disabling ancillary features and remove dependencies
Backward compatibility is important: hard dependencies on libraries released a week ago are painful; hard breaks on ABI/API/etc are more painful.
Gentler deprecation and upgrade paths are preferred.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
alcinnz
in reply to Drew DeVault • •One vital need operating system package repositories fill in my opinion is to keep the riff-raff, the unmantained toy projects written for educational purposes and forgotten about, out. And indexing them so apps can ask you to install the software they need, I wish more browsers did this!
I've read an anti-opensource article which in large part seemed more to be against these uncurated repos.
Why do people think computers have solved this problem? They're doing a poor job!
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
zem
in reply to Drew DeVault • •apotropaic plush connoiseur
in reply to Drew DeVault • •Martijn Braam
in reply to apotropaic plush connoiseur • •clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to Martijn Braam • •@Martijn Braam @Drew DeVault @hacking for the moonrabbit
> the MP3 technology became patent-free in the United States on 16 April 2017 [ . . . ] As a result, many free and open-source software projects, such as the Fedora operating system, have decided to start shipping MP3 support by default
en.wikipedia.org/wiki/MP3#Lice…
Elena ``of Valhalla''
in reply to apotropaic plush connoiseur • •counter-counter-argument: fedora users can be sure that the distribution they get is safe to use in any environment, without risking being sued by malicious entities for patent infringment.
The problem here are software patents, not the distributions.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 likes this.
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛 reshared this.