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.
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.
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.
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.
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.
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.
A) I know 3 ancient languages and have degrees in them undergrad and grad. Google Translate German is minimally okay at best. The most important aspects of languages are not words but sentence structure. That is lost on Google Translation BUT... what I can see is this guy is just raging about a missing dependency in the repos of a library last built in 2010 (5 years old). NOT AN RPM ISSUE.
2) Oh and who the RPM file format has since devised please ?! What's that supposed to be? If the alien invaders drive you crazy, so they can not exterminate mankind? Holy shit. By contrast, even the Debian stuff is obvious and self-explanatory! And self-documenting all. As a .deb works, one can find out with file and home remedies, you do not even need a hex editor."
C) This guy is clueless he says Gnome handles this better then RPM? What does a Desktop Environment have to do with RPM? Does he equate Gnome with Debian/Ubuntu and thinks Gnome is Deb?
"Does "deltarpm". Say, is that a joke here? Even Rotz Gnome checked before building if its dependencies are fulfilled!"
"First there are RPM directly two strands, RPM and RPM 4 5, and both claim to be the "official" RPM. Lolwut?"
E) Why would anyone need a hex editor for when looking at RPM its plain text?
If you can't find anything on the issue in several languages it isn't an issue. RPM is a stable good technology that people randomly out of what need to put down without knowingly what they are talking about.
Enough said about this stupid blog post:
"My goodness. And I know otherwise perfectly sane people who swear on CentOS!
Update: Maybe I should say, as I so imagine a package management tool. My request would be that always works. Python zerschossen? Perl is not installed? glibc update failed in the middle? The package manager needs to go and can still be saved. And it must be small enough to fit with metadata in 5 MB. Must also without OpenSSL and curl and wget can work, at least in an emergency. Of the systems that I've seen so far, I like best pacman (Arch Linux). But there is something else."
In all fairness, RPM really is a shitty package format [0]. It's a binary format with a lot of different versions, and any tool dealing with RPMs needs to be able to handle all those different versions. Compare that with nearly every other package format: a standard archive file with the package data and metadata stored within. This means that you need specialized tools to deal with RPM packages, whereas packages in other formats can be dealt with using standard archival and compression tools.
The situation could be a lot worse, for sure, but dealing with RPM packages is a pain in the ass compared to practically every other package format (programmatically speaking).
(I say this as the maintainer of a tool that converts RPMs to CRUX packages [1]).
2. Most of the complaints are about RPM's build chain and the bloat included in it. NSS/NSPR: RPM doesn't care about any standard ways of configuring them – nspr-config, pkg-config, LSB default folders, … ) BDB: Needs to be copied into RPM's source tree. RPM doesn't build its python modules (needed by yum etc.) by default. Yum has a hard dependency on sqlitecachec but doesn't declare it. (sqlitecachec is the piece of software from 2010, BTW.)
(No idea whether those are accurate.)
3. The gnome comparison is, again, related to the build system: RPM does not check all build- and runtime dependencies before building, you have to determine them by trial and error.
(No idea whether this is accurate either.)
4. RPM packages are binary, and to inspect them you either need specialized tools or, well, hex editors. (Also seems to be correct.) This is a marked difference from all competing formats, which are plain text. DEB packages are ar(1) archives with some special files, all ASCII text. Same for Pacman packages (which are tars).
5. I don't think his "package manager wishlist" is unreasonable. A statically compiled package manager that works without any external dependencies is desirable, as it e.g. allows cross-installation from other platforms, and makes the system harder to break with botched updates.
6. Another complaint is the dependency bloat: Why use a mixture of XML text databases (repodata) backed by an SQLite cache (yum) and BDB databases (rpm)? (No idea what's an accurate representation.)
Generally, Fefe has been lobbying for less complex, easier to maintain, easier to verify, more resource efficient software for over a decade. His projects – gatling, dietlibc, minit, fgetty … – show it.
Sure down vote BUT defend your opposition to the point of this blog post that I pointed out. It is 100% not RPM issues that this person is talking about.
Okay so by the down votes I guess people prefer to think RPM is bad and won't take anything from anyone pointing out how it works and that the article used was full of holes by someone that doesn't understand package management.
I SAID STUPID: Ye sit is stupid to request a package manager that uses unsecured packages with disabled SSL and curl and wget to download packages and manage them so that any hacker could install any package it wants with a simple script.
"this guy" and "this person" with the "stupid blog post" is Felix von Leitner, for reference. Understand that, and understand things like diet libc, libowfat, and minit, and you will understand some of the bases of M. von Leitner's opinions here.
> Ye sit is stupid to request a package manager that uses unsecured packages with disabled SSL and curl and wget to download packages and manage them so that any hacker could install any package it wants with a simple script.
That was not the demand. The demand was a package manager that works without requiring openssl as a dynamically linked dependency, so the package manager still works if those dependencies are broken or missing (due to e.g. a botched update) and can repair dynamic libraries for the rest of the system.
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.
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).
> 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.
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.
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.
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.
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.
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.
Slackware is the muscle car of linux distros. If you don't mind getting your hands dirty, it's fast and solid. Plus if you can master Slack, you can waltz into any other distro and not break a sweat.
I've run it on desktops/servers since version 8 and love it. People knock it for not having a "real" package manager, but if you like the control of compiling from source then this doesn't really matter (and you always have the latest versions of any packages available). There's almost always a slackbuild for the project you want. Plus there is the official slackpkg (and slapt-get/swaret for dep resolution as well).
So yeah, it's a bit more work, but I guess for some of us that's fun.
After answering this f. question with the same f. answer for literally 10 years, I'm starting to feel that some kind of re-branding would be a good thing for Slackware. It doesn't matter what Slackware is, it matters what people think it is. And what they think it is isn't really what it is. It's a reasonable distro.
Anyways, I recommend you give it a shot. See the README files, and http://docs.slackware.com/. And have fun.
Just install everything when it asks you to. You can ignore the kdei disk set if you speak English (and have no plans to run KDE in, say, Urdu), and the kde disk set if you do not need KDE altogether.
Since there is no dependency resolution, when you install from SlackBuilds.org (Slackware's AUR, more or less), you have to install each package's dependencies as well. These are listed in the package info file and tools like sbopkg let you install many packages at a go through a queueing system, so this is not as bad as it sounds.
The benefit of this is a completely user-configurable system, and a lack of errors when you hosed the dependency resolver since there's no resolver to hose. :)
I just wish slack had something comparable to mkinitcpio that arch has, which makes it much easier to set up an initial ramdisk for an encrypted root partition.
README_CRYPT.TXT in the root of the distribution[0] describes how to do this, step by step, including the relevant theory so you know what you're doing. After all of that it shows you the /usr/share/mkinitrd/mkinitrd_command_generator.sh command which you can use to generate the command that you need to build the initrd. Quoting from the docs:
The mkinitrd package in Slackware 14.0 (and on) ships with a script called
'mkinitrd_command_generator.sh'. If you run this script, it will analyze
your Slackware configuration and make a smart suggestion about the 'mkinitrd'
command you have to type in order to create an initrd.gz with all the bells
& whistles. The script will recognize your kernel version, root partition
and filesystem, it will find out if you are using LUKS and/or LVM and will
determine what kernel modules your initrd needs to mount the root filesystem.
The following command will save you the headache of figuring this out all
by yourself:
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -r
It should emit a string like this (your system will probably give different
parameter values):
mkinitrd -c -k 3.14.10-smp -m ext3 -f ext3 -r /dev/cryptvg/root -C /dev/sdx2 -L
The administrator of that machine can examine the output of that command and determine if it is correct after reading the theory about how the initrd needs to be built. If it is, it's a simple one liner, but if not, it's simple enough to either write a wrapper script or copy the script to /usr/local/sbin/mkinitrd_command_generator.sh and make the necessary changes.
I used Arch for 8 months sometime in 2010. And I switched my main computer to Arch just yesterday, just to give it a shot, to see a different approach, to use a systemd-based system, to re-learn some stuff, etc etc. Basically to experiment.
IMO Slackware is definitely easier to install, more reasonable defaults, less fiddling with the system post-install. For me it's basically aiming slapt-src (something like yaourt) to https://slackbuilds.org/ (something like AUR, but the scripts are reviewed and tested by site admins) and letting stuff compile & install (with a _lot_ less interaction required than AUR stuff).
Wait for a 14.2 to be released and then give it a shot. See the readme files and http://docs.slackware.com/. I hope you like it.
I found it to be more difficult than Arch, mainly due to the ease of Pacman and the AUR (using Yaourt), other than that it felt very much the same (note my Slack experience is form years ago.) Gentoo was much harder to setup but easier to keep up to date. I still have warm feelings for Gentoo but I also landed on Arch. And, as I grow older, I like to configuration work Ubuntu does for you...
In my time I'd install Dropline Gnome on Slackware and had a nice up tot date fancy looking desktop on Slackware in about 30 min. I see that Dropline Gnome still exists [0], It can make Slack nice looking and up-to-date quite easily (although they are 2-3 versions behind, they used to be more bleeding edge than anything).
Installing it is actually pretty easy, because they provide a reasonably straightforward console-based "graphical" installer, rather than pretending that copy-pasting a bunch of commands off the [Gentoo|Arch] wiki will teach you anything beside how to install [Gentoo|Arch].
I really want the best for Slackware. I used to be a slacker 1996-2006 and grinded my Linux teeth on it. It escapes me why they don't want to innovate at all with a proper modern package manager. Also they need to remake their website and with that create a decent forum and a decent wiki just like Arch has perfectly done.
Nowadays I don't care at all about knowing every corner of my system. I have applications to manage, languages to learn, money to make and a life to live - so I lazily run Ubuntu on everything.
I still run Slackware on my home/work machines. I find that setting it up once every couple of years and moving my home directory is about all I need.
On the rare occasion software needs to be installed yes, it has to be built from source and it takes a few extra minutes. But you know what? Ubuntu package managers have failed me more than a couple of times. Slackbuilds.org has never once failed to produce a working package for me.
I know people don't want to have to know about every corner of their system. But you don't necessarily need to. Set it up and it works. But if you ever need to you can with Slackware. All the way down without a lot of cruft on top. And that's worth a lot when it's needed.
I guess the point is... I don't spend a lot of time screwing around with my Slackware systems. They are stable, simple and they work. Not dissimilar to the Slackware web site. Lacking over-engineered cruft.
I'm a bit skeptical about the word "modern" these days. slackpkg is a good package manager and does everything you need to keep your system up-to-date. From the slackware website:
"Slackware is designed around the idea that the system should be a complete installation kept updated with any official patches. This avoids the mess of dependencies that some other Linux based GNU systems face."
Why remake the website? The website is clear enough, has links to the Slackware Book and to a mailing list.
It's not adequate sorry. I am not happy with mailing lists for community building. And I know of Linuxquestions.com forums, but that's not adequate either. Seriously, it would take 60 minutes to get this sorted, and 30 bucks yearly of hosting these forums.
What are mailing lists and forums missing for you? What killer features do you think that the Slackware team need to implement beyond what they currently have? I ask in all sincerity because you haven't mentioned it in your post.
The community. As a user and potential contributor, I need that.
Also I am sounding like a downer... I'm sorry about that. My strong opinions can often be too much, and I get that because they might sound negative. I am saying the things as a long time Slack user that gave up.
But what is 'the community' to you? To many Slackware users it's precisely the mailing list, the LinuxQuestions forum, the subreddit (/r/slackware), things like slackbuilds.org and docs.slackware.com.
So what is missing from what Slackware currently offers that would make have 'the community' to you?
Using Slackware and expecting modern frills is a bit like buying an old hot rod or turbo import from the old Soviet Union and then complaining it doesn't have a factory warranty or a customer support line. You don't buy it because it's going to be easy to drive and maintain.
There is an owner's manual and a community of other enthusiasts. If you want more convenience, your best bet is to try a different make and model.
So I go down the thread from above, asking you what you would do, and your response is "nothing, don't bother trying to bring me into the fold, I'm just going to complain"?
I'd appreciate it if next time just you would just say "I'm just complaining" so I know not to waste my time.
So? Large majority code running in any distro was developed by third parties. This means nothing. It's a part of Slackware.
It was announced in Tue Sep 16 11:20:30 PDT 2003 that it's a part of 'extra' repository. So, not installed by default, but it's there.
Announcent on Fri Nov 21 13:51:57 CST 2008 says it was moved from extra/ to ap/, meaning installed by default on all except the most stripped down installs.
Also, there's nothing special in using third party tools as package managers, they all use slackwares pkg tools under the hood.
Think (apt<->slackpkg, dpkg -i <-> installpkg, dpkg -r <-> removepkg, etc etc etc).
I can't tell if "grinded my... teeth" is an accidental error, or an intentional mixed metaphor as a joke. But if it's not intentional then it should be, because I laughed.
I certainly ground my teeth while using Slackware in the 90s too, which is why I switched to Mandrake and then FreeBSD. :P
I think the desired term is "to cut one's teeth on." It refers to how babies' teeth are aided in erupting from the gums by chewing on something tough. "Grinding one's teeth" is used to indicate being under an unpleasant level of stress.
I'm not the commentator, but Mint is Ubuntu, except they've already done all of the grunt work to make it useful (like making codecs available and prettifying it up).
At least 2 years ago when I ran it exclusively, it was accurately described as Ubuntu-based, not Ubuntu, just like Ubuntu is Debian-based, not Debian. But the similarities are (or at least were) much closer between it and Ubuntu than Ubuntu and Debian.
I often said I ran Ubuntu when I ran Mint, because there was basically no difference worth making.
What I said was un-supportive and deconstructive, i sincerely apologize. I will try to contribute more positively in the open source community, of which I am a big fan, and meant to disrespect towards.
edit: I have spent a lot of time bouncing between debian, mint and ubuntu as my main distros. To me the differences are huge, and if I could go back and re-write my original comment. I might ask why you switched from mint to ubuntu. I recently moved from mint xfce to xubuntu, and now i am happily using debian xfce.
Yeah, I don't know either. I went as far as to write spkg (spkg.megous.com) in 2006, just to replace the funcionality of pkgtools bash scripts without adding new features. (imporving robustness and speed) I never got any response from the Slackware team. I guess they're just very very conservative.
I loved my Slackware times for the learning experience. But it was hell of a lot of work to use it.
Patrick Volkerding is hesitant about systemd, but not openly hostile, so he has decided to stay away from it for now, but hasn't ruled it out for the future.
People who are set against systemd should probably better look elsewhere (although their options are pretty limited).
Alternatives include CRUX (whose maintainer's systemd stance is "over my dead body :)"), Void Linux (the only distro I know of to adopt systemd by default and then migrate away from it; currently it uses runit with systemd as an option), and Alpine.
I'm sticking with Slack for the time being, but I've got my eye out for alternatives should the worst happen.
And this is why discussing anything systemd is such a pain.
Apparently you can forgo systemd_pam (a poor naming choice, given the following) if you do not use logind. And logind is used for seat and session tracking, something CoreOS likely have no need for as it is meant to handle containerized servers.
Yet all this is in systemd the project, because systemd is the swiss army knife of Linux user space.
So yes, Slackware would likely need to adopt PAM if they want to adopt systemd.
Slackware has always had a package manager, from the beginning.
What you probably mean is "does it have a package manager with dependency resolution, yet?". And the answer has been "yes" for years now. Several, actually.
They aren't included in the main installation, but they are widely used.
swaret, slapt-get, etc. listed in Unofficial Tools section on that page do exactly as you wrote.
However, I find that people who choose Slackware usually like to compile stuff on their own. It can be a painful experience with some programs that have narrow version compatibility ranges for some libraries. For example, I recall building Inkscape and Workrave to be a nightmare because you had to try 5-10 versions of some dependencies until it clicked.
AlienBob has binaries of his slackbuilds for download and the Microlinux Desktop (Nicholas Kovacks) provides a range of binary builds for a nice xfce4 desktop. 14.2: microlinux builds are on hold a bit until 14.2 gets more stable.
There is also the slackonly binaries that are built from the slackbuild scripts at slackbuilds.org. Not sure how maintained slackonly is but many of the 14.1 builds work fine.
You don't have to compile a lot unless you want special options or if you have trust issues about binaries.
Slackware does not and very likely will not have dependency resolution. Its package manager is pkg which is a script that explodes a gzipped tarball from root.
