Long time Debian user considering switching to Slackware
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Up until just now I thought my DVD-ROM was borked... I decided to see if it worked by running 'eject' on it, and after that worked, putting a DVD in...
It works in Slackware, where it didn't work for about that last like 4 years in Debian. It also hadn't been working in Windows 7. It stopped working about the time I switched to Debian Wheezy (7) from Debian Squeeze (6.0). I suppose I should try to report a bug to Debian about that, but seems like a lot of work to track down the why and when for this bug when I do not even use the distribution anymore.
Hello all, I appreciate all the helpful feedback over the last few days. I haven't been responding to the thread because I have been busy playing with my Slackware64 14.1 laptop.
It took me a few days to figure out why my video card was not working, as that is something that has always worked out of the box in Debian. The reason it was not working is because Slackware leaves the configuring up to the user. Slackware lets the user make the decision on what an installation does and does not need. I had to configure my Xorg.conf manually and boot using radeon.modeset=1. Prior to that I was booting with nomodeset until I figured out what was going on. No biggie, I have had worse in Debian. =)
I do not think that is a negative mark against Slackware and I find it refreshing to know that the Slackware developers are not making all sorts of decisions for me prior to me even installing an ISO, patch or update.
The reasons I moved from Debian to Slackware are:
* I want more control over my installation
* I want less bloat
* I like simplicity
The Debian development team seems to be making an awful lot of decisions for their users. I ran Debian Jessie (while it was the testing branch) for the last year and a half and saw immense changes from Debian Wheezy (now old stable) to Debian Jessie (current stable) that left me unsatisfied with Debian as a distribution. Every time there is a new release coming out I do the same thing and track exactly what Debian is about to do by running Debian Testing.
I find that Debian installs too much bloat these days. With Slackware, even if I install every package in the distribution, I find I am using less disk space than Debian. I can only find a few things I am missing that are rather inconsequential- all which are found on slackbuilds.org.
As far as security updates go, I do not feel that even a month of a lack updates is too long. It seems pretty straight forward to create a few Slackbuilds to update portions of the system. I did that and more in Debian testing by building .deb packages from source to fix security holes that were patched in Debian Unstable and Debian Stable, but yet to be patched in Debian testing due to how Debian develops its testing branch.
Also, if security updates are such a paramount concern that every little threat needs to be addresses, you are likely running a production server yourself, for a client or at work. In this case I think that it is a b etter idea to mirror all of Slackware on a private mirror and take a far more in depth care of what goes on your system than to wait for the developers to catch up (if in fact they are behind, which I doubt they are behind in the first place). I am not running a production server. In the passed when I was running a production server, I was a system administrator for a fortune 500 company, and there was a development team at that company managed the updates to all systems for the company (and issued their own software packages updates for that production server).
Anyway, enough of my ranting. Glad to be a Slacker!
Glad to have you as a Slacker. Yes, Slackware does propagate you do for you, not have things done for you. It is an odd trade off when you come from more automated distributions, but the learning curve of Slackware exposes you to a lot of core fundamentals of system setup, management, and maintenance you don't find elsewhere except in a few corners of the Linux spectrum. I think the only other distribution that does this is CRUX and maybe Funtoo to some extent. Plus, what you learn from Slackware tends to better prepare you for other distributions and even other flavors of UNIX.
Location: Geneva - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware 14.2 - 32/64bit
Posts: 609
Rep:
Hi,
Glad to see a new one in the Slackware crowd, and it seems that this distro is "made for you" (according to your messages). So have a nice trip around, and yes this is a great community, even if some of us disagree in endless threads, you have here on LQ one of the 'best community' for a distro (I must admit that this is the only "community" I'm registered to). A lot of knowledge people, often mature, and helpful.
It took me a few days to figure out why my video card was not working, as that is something that has always worked out of the box in Debian. The reason it was not working is because Slackware leaves the configuring up to the user. Slackware lets the user make the decision on what an installation does and does not need. I had to configure my Xorg.conf manually and boot using radeon.modeset=1. Prior to that I was booting with nomodeset until I figured out what was going on. No biggie, I have had worse in Debian. =)
What's your video card? What does /sbin/lspci | grep -i vga spit out?
I assume it's an AMD/ATi card, so there's a few things to know.
First off, start configuring and building an initrd. Take a peek on docs.slackware.com, or on my own little HOWTO on the subject. Add the "radeon" driver explicitly to the initrd. And then switch to the generic kernel + initrd.
Recent versions of X.org don't need an xorg.conf. You might want to configure your keyboard layout. So copy over the corresponding configuration file stub from /usr/share/X11/xorg.conf.d and put it in /etc/X11/xorg.conf.d. Edit it to your needs.
Don't hesitate to ask. Slackware is quite a different beast than Debian (I happen to know both quite well, but prefer Slackware). This forum is one of the more helpful places on earth.
Thanks for your suggestion kikinovak, but I have already figured out all this by futzing along on my own. I did ask a few questions about it in irc.freenode.net, #slackware but the answers I got did not really lead me to the answer. Though I wasn't really sure what questions to ask other than pastebin what I had and hope that someone could make sense of it.
As a Debian user you come to accept the convenience of a massively configured kernel out of the box which results in little to no hardware troubleshooting (most of the time). With Slackware it was just a matter of loading the radeon driver at boot time from lilo with radeon.modeset=1.
Another thing that I was confused by was: Slackware Docs: Beginners Guide - Configure X if required. Nowhere does it mention anything regarding the fact that Xorg will segfault if it cannot access some part of X due to missing drivers. I thought Xorg was broken in some way. Hindsight I felt pretty stupid after wasting the time I did on something so dismal.
Passed that I just followed the: Slackwiki: ATI Graphics page. I did however try to get the proprietary ATI drivers to compile and install for some time until I found out that the legacy ATI driver won't build with modern kernels without a patch/modification. After I gave that up, I figured it out pretty quickly.
I also recompiled my kernel following: Slackbook: The Linux Kernel. As a result my system is no longer over heating, the network connection is faster than ever, I have full use of my graphics card, and my DVD-ROM is working for the first time in 4 years. Haha.
Thanks for your suggestion kikinovak, but I have already figured out all this by futzing along on my own. I did ask a few questions about it in irc.freenode.net, #slackware but the answers I got did not really lead me to the answer. Though I wasn't really sure what questions to ask other than pastebin what I had and hope that someone could make sense of it.
As a Debian user you come to accept the convenience of a massively configured kernel out of the box which results in little to no hardware troubleshooting (most of the time). With Slackware it was just a matter of loading the radeon driver at boot time from lilo with radeon.modeset=1.
Slackware has several IRC channels, and one actually useful channel. Try #slackbuilds on irc.freenode.net, that's where all the usual suspects hang out. IMNSHO you can forget the other channels.
Slackware is not Debian. The HUGE kernel is only there to install the system, and to get a shell after rebooting. You're supposed to switch to GENERIC with a custom-built initrd. Otherwise, it's like owning a Porsche, but driving it only in first gear. You can do it, but you'll be seriously limited.
Take it from a long-time Slackware user.
BTW, if you're an Xfce user, you might want to take a peek at my MLED project (link in the signature).
That you run your servers in an insecure manner and didn't get hit by problems is nothing more than anecdotal evidence. I also didn't say that it is impossible to implement security fixes by the user, it may or may not be a 5 minute fix for the user.
All I have said is that you sometimes can't rely on the Slackware developer for getting security fixes and that the user has in those times to do that himself, and that it is up to the user to decide if that is a problem for him or not. Nothing more, nothing less.
I know that it is indeed blasphemous for some people to criticize Slackware, but quite frankly, I don't care.
Just to be clear, both on my practices and point made and Tobi's jumping to conclusions and cherry-picking to suit his preconceived notions.
Not "servers"! I have servers but ONLY the one dedicated Minecraft game server was neglected so and anecdotal != worthless. It is less than conclusive since it is only one experience on one box where there should be many but it DID take place daily, 24 hours a day, for over 2 years. That is not trivial or to be dismissed offhand. The question centered on Patrick and due diligence.
My point was that Patrick does provide at the very least the important fixes in a timely manner (and I further contend that it's quite a bit better than that) if even a neglected box remains secure. Here is where my point stops being anecdotal - Just how many boxes that apply the fixes do you suppose have actually been compromised ?, not merely technically vulnerable in some esoteric manner according to you, Tobi,...... actually compromised. I'd love to see a poll on this. I'm betting the figure is well under 2% , possibly under 1% . If Patrick is less than diligent and responsible then where are the numbers of failures to support that conclusion? I challenge you to support your contention with ANY evidence, even anecdotal.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by hitest
The main reason I suggested it to the OP is if he/she is going to do a clean install of 14.1 there will be heck of a lot of updates and it would take a lot of effort to manually download and install each security patch.
I've found slackpkg to be very robust and reliable. It is also a smart utility and it will tell you if the patch is bad before you install it (a md5 mismatch). I think you will like it, man.
When I'm getting patches I do so using wget and, just for grins, I may get all of them every so often (just to make sure I get non-security patches as well as the security-related ones).
Having the luxury of high-speed satellite service has made me lazy.
Typical, though, is something like this:
Code:
su -
cd /usr/local/patches
rm *thunder*
wget ftp://ftp.osuosl.org/pub/slackware/slackware64-14.1/patches/packages/mozilla-thund*
upgradepkg *thunder*.t?z
Or, to get 'em all every so often:
Code:
su -
cd /usr/local/patches
rm *
wget ftp://ftp.osuosl.org/pub/slackware/slackware64-14.1/patches/packages/*
upgradepkg *.t?z
It's pretty fast and not too tedious (and I only do it once for 32-bit and once for 64-bit).
I am going to look into slackpkg though -- just seems like a good idea.
I am going to look into slackpkg though -- just seems like a good idea.
Agreed. I was initially hesitant to use it, but, slackpkg is now part of my tool kit. Also, as I am primarily a Slackware-current user the slackpkg utility makes the occasional massive upgrades in -current easier to manage. I predict that you will like slackpkg after you tinker with it a bit, tronayne.
Welcome to Slackware, mralk3!
One thing that has not been mentioned here and may or may not speak against using Slackware (dependent on your view on this topic) is that Slackware can at any given time without further notice cease to provide security updates, even for the current stable version. This means it is your responsibility to keep yourself up to date about potential security problems and solve them yourself (apply patches, upgrade to newer versions of a software if necessary, create packages) if not provided with patched packages by the Slackware developer.
If you use slackpkg+ then installing and maintaining multilib is trivial.
One thing that has not been mentioned here and may or may not speak against using Slackware (dependent on your view on this topic) is that Slackware can at any given time without further notice cease to provide security updates, even for the current stable version. This means it is your responsibility to keep yourself up to date about potential security problems and solve them yourself (apply patches, upgrade to newer versions of a software if necessary, create packages) if not provided with patched packages by the Slackware developer.
Yes we've heard all of this before, and you can't recommend Slackware to anybody as a result.
Can you recommend Linux to anybody? A kernel.org server was hacked rather embarrassingly 4 years ago, and we're still waiting for the report we were promised in late 2011. This complete lack of transparency on the part of the kernel team has left me with persistent doubts about the trustworthiness of both the kernel and the inner circle of senior developers behind it.
Slackware going without updates for six weeks is small beer by comparison.
There is a conversation to be had about the ever increasing number of security fixes, and what the Slackware community can do to help ("mancha is our role model" would be a good start). But this thread is not the right place. Tobi has set a good example by unsubscribing from this thread (which in my opinion enhances his moderator status). So the only things left to do here are to praise Tobi's prudence in unsubscribing, and to welcome mralk3, who is clearly better than me in resisting thread-drift.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
.
