mastodon - Collegamento all'originale

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.

reshared this

in reply to Drew DeVault

mastodon - Collegamento all'originale

Paul Sadauskas ✊ Resist

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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

Paul Sadauskas ✊ Resist

fully aware of my ignorance, just remarking that relying on my package manager is so far out of my experience as a web developer (and every fellow dev at every place I've ever worked since 2000), I find it surprising that it's even an option. Every 5 years or so when I look into it, it seems completely untenable, all the "happy path" tooling would have to be discarded and something new written. Doesn't help that 99% off Ruby/JS devs use MacOS...
in reply to read-only account (Rain 🚱)

friendica - Collegamento all'originale

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@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.

@Drew DeVault @read-only account (Rain 🚱) @Paul Sadauskas ✊ Resist
in reply to read-only account (Rain 🚱)

friendica - Collegamento all'originale

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@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.

@Drew DeVault @read-only account (Rain 🚱) @Paul Sadauskas ✊ Resist
in reply to Paul Sadauskas ✊ Resist

friendica (DFRN) - Collegamento all'originale

Elena ``of Valhalla''

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.

in reply to Paul Sadauskas ✊ Resist

friendica (DFRN) - Collegamento all'originale

Elena ``of Valhalla''

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.

in reply to Elena ``of Valhalla''

mastodon - Collegamento all'originale

Paul Sadauskas ✊ Resist

A quick check of my Fedora 30 install shows there's 1, 250 `rubygem-*` packages available, out of 10,000 on rubygems.org. The current version of the single most popular gem, `rails` in the distro is 5.2.3, and 5.2.4 was released Nov 27. Rails 6 was released back in August. Our main production app has 318 gem dependencies, 137 are available in Fedora 30, and 37 are the version we need.
in reply to Drew DeVault

mastodon - Collegamento all'originale

Çağatay Yiğit Şahin

One of the major features of Flatpak is using container technology to make sure no matter the distro, the package is running in the same environment as the developer's machine, so there is no need to "tune for the environment."
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.
in reply to Drew DeVault

mastodon - Collegamento all'originale

Çağatay Yiğit Şahin

spoken like a person who does not have a real answer
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.
in reply to Drew DeVault

mastodon - Collegamento all'originale

Franz Geffke

I'm very much a Guix advocate. We're developing an upstream distribution, based on this (still young), but in my opinion, fantastic package manager. That being said, I have to agree with Drew. For the majority, Linux = Ubuntu. Most people don't care about the technical details, or reproducible environments - nobody would be using Windows, or MacOS if that was the case. People want beautiful, no-brainer software, that helps them accomplish stuff without reading a manual.
in reply to Franz Geffke

mastodon - Collegamento all'originale

read-only account (Rain 🚱)

I kinda agree with this but if someone's doing web development and have already installed a language specific package manager, then using Guix or Nix shouldn't be that hard for them and if they wanna distribute things with Flatpak and absolutely refuse to write a proper package instead, then I'd prefer guix pack instead of a blob that who knows what generated.
in reply to read-only account (Rain 🚱)

friendica - Collegamento all'originale

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@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.

@Drew DeVault @Çağatay Yiğit Şahin @read-only account (Rain 🚱) @Franz Geffke
in reply to read-only account (Rain 🚱)

friendica - Collegamento all'originale

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@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.

@Drew DeVault @Çağatay Yiğit Şahin @read-only account (Rain 🚱) @Franz Geffke
in reply to Drew DeVault

mastodon - Collegamento all'originale

bugmenot

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

mastodon - Collegamento all'originale

Drew DeVault

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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

bugmenot

>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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

bugmenot

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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

bugmenot

>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?

in reply to bugmenot

mastodon - Collegamento all'originale

Drew DeVault

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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

Be gay do crimes

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

in reply to bugmenot

friendica (DFRN) - Collegamento all'originale

Elena ``of Valhalla''

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.)

in reply to Elena ``of Valhalla''

mastodon - Collegamento all'originale

bugmenot

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.

@Drew DeVault
in reply to Drew DeVault

mastodon - Collegamento all'originale

federico

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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

federico

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.

in reply to Drew DeVault

mastodon - Collegamento all'originale

alcinnz

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!

in reply to apotropaic plush connoiseur

friendica (DFRN) - Collegamento all'originale

Elena ``of Valhalla''

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.

Questo sito utilizza cookie per riconosce gli utenti loggati e quelli che tornano a visitare. Proseguendo la navigazione su questo sito, accetti l'utilizzo di questi cookie.

⇧