Very interesting. I'll have to read more about this. The sbo stuff is new to me.

The more I think about it, I may have been on dialup the last time I used Slackware. So, the more packages I had installed, updates took that much longer. That should be less of an issue now.

I'll have to reread the Installation notes, but wouldn't a full install have more running than I will likely need? For example (and this may not be exactly true) would a full install leave me with a running postgres server and web server? I don't intend to run those.

As for "nor will it put it at risk", I've been doing some security related stuff at work. We've been following the philosophy of "minimizing attack vectors" -- the more software you have running, the more opportunities for problems. Having something extra installed doesn't bother me as much as having things running that I don't need.

services are not enabled just because they are installed, like on other distros. so no, slack will not be slower just because you have more things installed.

as for updates. slack only updates packages in stable if they are critically needed. so even with a full install you will likely get far less updates than a slimmer install of most other distros.

you might find this interesting:

http://my.opera.com/ruario/blog/2011...ncy-management

3 members found this post helpful.

Especially now as Slackware have begun to ship ESR versions of Firefox (which is a wise move IMHO), so update of it should become less frequent.

During installation you are requested to tell which services (mostly daemons) you want to start at boot time (or not).

And forbidding a web or database or other service to start at boot time after installation is just a "chmod -x /etc/rc.d.rc.<service name>'' away.

Oh and for the sake of accuracy, postgres is not shipped in Slackware, and /etc/rc.d/rc.httpd and /etc/rc.d/c.mysqld are not executable by default.

Personally I just disable rc.sshd and rc.inetd among the ones proposed to be "on" by default, as this is for a laptop.

Yeah, so just review all scripts in /etc/rc.d and make non executable those you don't want to run.

2 members found this post helpful.

Very well done!
Thanks.

This reminds me -- I wanted to look at how Slackware handles security fixes (i.e. CVEs). Thanks for the reminder.

When I said I'd accept an "RTFM" as long as someone pointed me to the manual, this is what I had in mind. Thanks for the link. This (or something like it) should be on the "Must Read" list of new Slackware users.

Cool, more of my questions/concerns are answered.

You guys (and gals?) are great!

The main issue with Linux application software is not how you track dependencies. It is that you have to track them, even if you don't want to. It may even be the main reason, why Linux fails so hard on the desktop.

Ingo Molnar wrote a insightful article on the topic: https://plus.google.com/109922199462...ts/HgdeFDfRzNe

1 members found this post helpful.

My bad, I misread the statement as referring to packages rather than files.

Brian

If you go for this approach you might want to copy the README files also, since you possibly have installed a package with an optional dependency. Those are not mentioned in the info files.

I'm having trouble understanding both this article and the argument.
To me, Paul-Henning Kamp characterizes the problem (or what I think of as the problem) more clearly and convincingly here: https://queue.acm.org/detail.cfm?id=2349257
The answer long term, IMO, is to go back to the source of the good things in UNIX for what they've decided was wrong with it, starting fresh on top of plan 9 while at the same time ignoring Mac OS, Windows, and mobile device design choices (thus avoiding the difficult design point of having to try to be all things to all people).

IMHO, it's better to use "readelf -d" to check for library dependencies than it is to use "ldd". That way you only see which libraries are directly linked with the binary (and not all the libraries linked to those libraries, etc.)

Using ldd can leave you thinking that there's a lot more stuff to rebuild after an soname bump than there actually is.

5 members found this post helpful.

Hmmm... I expected more, but I find the article neither insightful nor particularly applicable to actual 'package management', but rather totally focused on the app marketplace point of view - marketspeak.

He states...

But that is neither good enough nor sincere. Freedom "for all practical purposes" or "from the user's point of view" is not freedom at all... but that at this point we are straying far from the topic of package management.

Molnar discusses why people actually use operating systems: to run applications of their own choice. Most mainstream Linux distributions make that especially hard. They either try to choose applications for you or try to provide distro-modified versions of everything in existence on their own (and then end in the dependency hell).

Upstream is at fault too. Most FOSS developers provide OOtB Windows and Mac Binaries. When you ask for a Linux version, they send you to your Linux distributor, provide their own Linux (live) distribution or throw source tarballs at you. (Mozilla is an exception, they actually provide a working self-contained binaries of Firefox.)

For Linux success on the desktop, that has to change immediately. If someone wants to try out a new KDE version, it has to work this way:

1. Go to KDE.org
2. Choose your Platform (Linux, x86, x86-64 etc.)
3. Download the KDE installer
4. Run it to install KDE into /opt or $HOME on every major Linux distribution without interfering anything.

If you're on Windows, it actually works this way: http://windows.kde.org/ (which is sad for FOSS)

If you're on Linux, they send you there: http://techbase.kde.org/Getting_Started/Build/KDE4

And there the journey of the desktop end-user abruptly ends...

Did you read Part II?

https://plus.google.com/109922199462...ts/VSdDJnscewS

If you watch the "average Windows user" you will recognize that this is exactly not the way it works. It rather works this way:
If someone wants to use a new version of a software (which actually rarely happens, most people never update unless a dialog asks them to) he does this:
1. Go to Google, search for the software.
2. Click on whatever link Google spits out first, irrelevant how shady that site is.
3. Download that binary without ever thinking about things like signed software packages and checksums.
4. Start the installer, give it admin privileges and click next as often as you can, without reading what is written on the screen or thinking about the implications of giving some random software admin privileges.

Having repositories has an advantage that you will see very rarely on Windows machines: A trusted software source. Not having repositories is a serious disadvantage for the average user and everyone who maintains Windows systems from those average users knows that.
Funnily, things like app-stores on Android and iOS devices teach people the simplicity of this approach without giving them the real advantages, because the apps are not really tested (why should they care anyways, more sold apps mean more profit for Apple/Google, you can delete them from the store if someone reports the malware).

4 members found this post helpful.