[warrenmar]

For those of you that don't know about Slackware. Slackware is the oldest distro and it is still plenty alive today. When to setup linux on my computer in the early days with other distros (red hat/suse/etc), this would eventually crap up (rpm hell) and give me something unusable. Using Slackware forces you understand how everything works in a linux distro. This lets you fix your own problems.

[baldfat]

I know you didn't mean to bring this up as a point against rpm but my ALL TIME MOST HATED PHASE is rpm hell. I still hear people say that they won't use RPM based systems because of RPM Hell which makes me inside want to jump through the screen and shake them and say "Have you ever built a single package?! Because if you ever have you would know this is 100% crap for over 10 YEARS!"

Sure there was a time frame when there was an issue with dependency and it was fixed but everyone treated it like it still was an issue 5+ years later.

Sorry rant over but I just want people to know that RPM issue was just an issue in the early 2000s and Redhat made --redhatprovides and --redhatrequires command line options that if people used them would fix the issues at the time till things got changed with libraries.

[IgorPartola]

Sorry, but I am still stuck in my own version of RPM hell, and yes I have packaged RPM's.

The problem: production servers for a client use RHEL 6.3 and are very slow to upgrade. Moreover, they don't have the subscription to RH's commercial repos, and instead host their own, which means that some packages are straight up missing.

For development I use CentOS of a matching version. All works well until I go to deploy something to production and find out that a package I need is not available. The solution has been to (a) install packages from the CentOS repos (yup, old school download them off their site and then `rpm -i` them locally) or ask the client's IT to temporarily enable certain repos of later RHEL versions they have, so that I can install packages with lots of missing dependencies. The most recent fiasco with this involved ImageMagick and ImageMagick-dev not being there and depending on a crapton of libraries that were also missing.

Now, I am not RPM-distro professional, I stick to Debian derivatives for the most part, but I have worked with them enough to know that unless you do things by RH's book, you are going to be in trouble, and even people whose full time jobs it is to maintain these production servers seem to have a really hard time figuring out how to get this right.

P.S.: One solution I attempted was to create my own RPM repo that I could these missing packages from. This worked for some, until it landed me in a world of hurt where yum really wanted to install i386 versions of the packages instead of x64, even though (a) the server was x64 and (b) both versions of the package were available. This resulted in yum refusing to do anything because it saw conflicts. I have never had these types of problems with Debian based distros and a day of Googling for answers did not solve it.

[jrumbut]

I too am mostly a Debian guy but it sounds like your situation has less to do with RPM than it does with a client putting themselves in a crazy situation.

The whole point of getting your OS from RH is that RH has a book that you can do things by and be pretty well assured of the results. When they decided to no longer subscribe to that they really should have switched to a community managed Linux version.

I can't imagine the one time cost of moving their production servers to CentOS would be more than the continual update pains they're experiencing.

[IgorPartola]

I assume so, though the part where yum could not figure out the server's architecture was really odd.

I would love for them to move to CentOS, or Fedora or whatever. The problem is that they are a huge healthcare company, and I am a part time subcontractor.

[baldfat]

This is 100% not an RPM issue. You have missing dependencies that is a repo issue. Same thing with Debian or any other package management system.

[creshal]

RPM seems hell enough in current versions: https://blog.fefe.de/?ts=a81c11aa

Disclaimer, I've never worked with it, I don't know how accurate the description is.

[baldfat]

So you post a German blog post about something you have never done. I now have gone full on salt.

Once again their is nothing wrong with RPM and this anti-RPM stuff needs to just die. Linus uses Fedora and if anyone would flip out if something was bad technology Linus would, but instead people who just heard a cool RPM Dependency Hell still continue this 10+ year old issue over and over again without knowing anything technical about why it was an issue (For a short period of time) and how it was fixed.

[creshal]

> So you post a German blog post

I'm sorry, I didn't know Germans weren't allowed to have opinions.

[adrusi]

But if your goal is to provide veracity to your claim, then posting a German article on an English forum isn't very useful.

[sbarker]

Google translate... We have the technology, just not the sense to use it :-(

[DeepYogurt]

It's not the oldest. SLS predates slackware (as do a few others iirc) https://en.wikipedia.org/wiki/Softlanding_Linux_System Slack was awesome back in the day, but the the philosophy as being "as unix like as possible" prevented it evolving and adding nice things like package managers. Using slackware is a good exercise, but I'd never use it for an application I care about.

[Tomte]

Correct, "oldest surviving", beating Debian by a hair.

[babuskov]

If you only need a couple of applications, it's great. We use it for 200+ POS terminals for our ERP/CRM software. It's obscure enough that the end users have no clue how to mess anything up (aside for occasional icon deletion in KDE, but even that needs the "unlock" step).

[JdeBP]

> the philosophy as being "as unix like as possible" prevented it evolving and adding nice things like package managers

Others have pointed out that the existence of Slackware package management gives the lie to that assertion. It remains to point out that Unices had package managers, so being "Unix like" does not involve eschewing package management at all. XENIX had a package management system, for example. It originated in AT&T System V Release 4, was also present in Solaris, and has been picked up by the Heirloom Project.

* http://uw714doc.sco.com/en/man/html.1M/pkgadd.1M.html

* http://uw714doc.sco.com/en/man/html.1/pkginfo.1.html

* http://uw714doc.sco.com/en/man/html.1M/pkgrm.1M.html

* http://uw714doc.sco.com/en/man/html.1/pkgtrans.1.html

* http://uw714doc.sco.com/en/man/html.1M/pkgchk.1M.html

* http://uw714doc.sco.com/en/man/html.1M/pkgask.1M.html

* http://heirloom.sourceforge.net/pkgtools.html

[massysett]

This is simply false. Slackware has a package manager. It just does not resolve dependencies. It has also evolved. The Slackware developers have worked on packages such as wicd, which makes networking easy without dependency bloat; other distros reap the benefits of it too.

[keithpeter]

http://www.linuxquestions.org/questions/slackware-14/wicd-re...

Wicd is proving difficult for 14.2. I must admit that I prefer network-manager because of the convenience of the modem-manager when using a usb mobile Internet dongle.

I take the general point you are making. I'm an end user of Slackware. I think that anyone who has ever successfully installed Windows on a laptop would cope with a Slackware install fine if they read the docs on the DVD. Slackpkg makes updates reasonably easy.

[creshal]

wicd is pretty much obsoleted outside Slackware because of its atrociously slow development pace. connman beats it by far in terms of "easy networking without bloat", and NetworkManager doesn't have noticeable bloat if you have a desktop environment anyway.

[pjmlp]

It was my very first one, Slackware 2 with kernel 1.0.9.

I still remember the main feature being announced was the early support for elf format.

Nowadays after a decade of jumping between OSes, I just settled on Windows, for better or worse, it does better what I need for my work (please don't start a flame war on this).

However I do owe a lot to Slackware, as before it my only access to UNIX were expensive Xenix, Aix and DG/UX workstations at the university.

[ktRolster]

(please don't start a flame war on this).

tbh I think you already flamed yourself, charred to a crisp, worse than any of us here could do. Windows User.

[pjmlp]

I don't see Windows User as being anything negative, given the pleasure I had in these 30 years developing for it, more than any UNIX platform I used in the same years.

But as I said, I don't want to start a flamewar about OSes and development tools available.

[kagamine]

And then SalixOS lets you benefit from Slackware without understanding much at all, like some kind of slack Ubuntu.

[mrweasel]

To me the understanding that Slackware forced upon you, at least earlier, was the benefit.

They could have bumped the version number to 15, I don't think anyone would mind.