Hacker News Reader

Comment by Gentil | Hacker News Reader

As someone who is from the era of Ubuntu as their first distro, my natural progression towards maintainable OS made me reach Arch. As an OS for your system, it seems like the perfect abstraction layer and does just enough. The next incremental update to my system could be NixOS, Nix package manager in Arch or Nix package manager in FreeBSD. But I am always happy to see old projects like this kicking.

I see many people mention the fact that they won't be coming back to Slackware. Could that be because they are not changing enough according to the times they are in? Is there something the project can do to attract new users? I definitely wouldn't want Slackware project to stall. It makes me really sad when OSS projects die.

View on HN

Slackware is really a small/bare bones distro, "old schoolers" like it because in it's time (90s era) just having a Unix like system on a PC was amazing and it is considered very stable, now that GNU/Linux is everywhere today's distros are just easier to use.

> There is no formal issue tracking system and no official procedure to become a code contributor or developer. The project does not maintain a public code repository. Bug reports and contributions, while being essential to the project, are managed in an informal way. All the final decisions about what is going to be included in a Slackware release strictly remain with Slackware's benevolent dictator for life, Patrick Volkerding.

This is from Slackware wikipedia page. If this is true, this could be the next logical step to increase some development involvement and noise maybe? Patrick should be also thinking about the future of Slackware right?

Am just an outsider since I don't have skin in the game. But Slackware is not a distro that comes in your conversations more often and I am in a lot of Linux communities. And the comments reflect the same as well. Maybe this could improve the scenario. Again, this is with the best intentions. Please ignore if the comments doesn't sit right with you. :)

---

Also, I don't think Slackware should be like GNU/Linux distros or alter course radically. But I think a small modernization of the project could help everyone who wants to keep the Slackware way of doing it alive.

This is why I abandoned slackware. It was one of the first distros that 'worked'. However, after becoming a developer with source control and some sort of system that let you track things. I did not want to go back.

They have steadfastly refused to move to more 'modern' development practices (they have been arguing about it since the mid 90s). With simple things like issue tracking. That is fine, it works for them. But after a few years I got tired of spinning my own just to have something kind of current (think that has changed). But I bailed out, when they kicked out the dudes who made it into a distro that was easier to update with some simple commands (like apt). That is something OS at the time had but them. I gave up. I just moved onto whatever my employer decided we were going to use (usually redhat or debian based). I enjoyed my time using it, but it became a chore to maintain. So I moved on to things that had automated some of that. They may have even fixed some of the issues I had with them. But I no longer have the time to bother going back.

I have seen this pattern with a few projects. Basically whoever runs the project just does not want to mess with it. That is fine. But it really holds their project back. It works fine when you have 1-2 people working on it. But you add a few dozen with people dipping in and out randomly you need to add some control to the chaos. One project I watched the main dev go kicking and screaming how it would not help. The project is now clicking along pretty good. He now does not feel like he is all alone fighting the world. He has people to help him and can track it easily. He even stated he should have done it sooner.

I considered Slackware but I'm under the impression it has no analogue to apt or dnf/yum.

How on earth do people running Slackware manage their library dependencies and keep everything up to date?

As far as I read about it, they don't! Dependency resolution is fully up to the user.

> The package management system does not track or manage dependencies; however, when performing the recommended full install, all dependencies of the stock packages are met. For custom installations or 3rd-party packages, Slackware relies on the user to ensure that the system has all the supporting system libraries and programs required by the program. Since no official lists of dependencies for stock packages are provided, if users decide to install a custom installation or install 3rd-party software, they will need to work through any possible missing dependencies themselves. Since the package manager doesn't manage dependencies, it will install any and all packages, whether or not dependencies are met. A user may find out that dependencies are missing only when attempting to use the software.

Source - https://en.wikipedia.org/wiki/Slackware#Dependency_resolutio...

Oof, that sounds like a lot of work.

Simplicity is a virtue but sometimes the juice isn't worth the squeeze.

Yes. I think the question always is where should I stop?. Cos it is a tool to get things done right?

While I think it is difficult to get Arcg going, the whole point of that effort is that I don't have to deal with it much after that. It is a rolling release and get the latest upstream releases which is not meddled with by distro much. Unless you are meddling with it too much, it is very stable IMO.

Keeping everything up to date in not usually required. But then comes a program with "bug fixes and performance improvments" which does not work with libxlst-2.67.45.35.77.so.2 and needs libxlst-2.67.45.35.78.so.4. And this lib needs another one and so on. Only if people would think a bit before releasing something the world would be a better place. That's why i like Patrick. He tries hard to make a stable release even during times when "if compiles, ship it" is the mantra.

There is no official dependency support, but there are projects out there that add dependency resolution to slackpkg[1][2] and sbopkg[3][4]. A few of the Slackware-based distros have their own method of dealing with it as well.

[1] https://slackpkg.org

[2] https://www.slackwiki.com/Slapt-get

[3] https://sbopkg.org

[4] https://github.com/McDutchie/sbodeps

> How on earth do people running Slackware manage their library dependencies and keep everything up to date?

        slackpkg update
        slackpkg upgrade-all

This is how you get the most recent version of all installed packages. You can run this every morning and you will have more modern tools than using ubuntu.

As for dependencies, as long as a new version does not add a new dependency, you are good. But changing dependencies of a software package is a major change that should not happen automatically. Recursive "dependency resolution" is a disgusting practice that has no place in a sane world. Dependencies are part of the API: changing dependencies is supposed to break your package, unless you do something about it.

In practice, in the rare case when this happens, you will not get any warning when upgrading. But you will get an error when running your program (that has become broken because of a missing dependency). The error message will be very clear, something like:

        "Runtime error: libfoo not found"

And the solution to this problem will be evident evident:

        slackpkg install libfoo

Reply on news.ycombinator.com