LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-01-2006, 12:40 PM   #31
Waggs
LQ Newbie
 
Registered: Feb 2003
Location: SC
Distribution: Slackware, Zenwalk, Mepis
Posts: 16

Rep: Reputation: 0

I went through the same process several time to get slackware running on an older laptop, and eventually I got it through trial and error, a good learning experience. Since then if I need something small, I just use Zenwalk and then add what I need.
 
Old 12-03-2006, 01:34 PM   #32
Chikne
Member
 
Registered: Jul 2006
Distribution: Slackware 11
Posts: 140

Original Poster
Rep: Reputation: 15
Does anyone know which package contains the library libutempter.so.0 please?

Thanks
 
Old 12-03-2006, 02:40 PM   #33
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,012

Rep: Reputation: 115Reputation: 115
The install script for the utempter package in a/ disk set creates the link.
 
Old 12-03-2006, 05:41 PM   #34
Chikne
Member
 
Registered: Jul 2006
Distribution: Slackware 11
Posts: 140

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by tuxdev
The install script for the utempter package in a/ disk set creates the link.
Thank you very much!!! I should have looked better...

I am now running slack on an old pentium 2 with a tiny 3 gigs hdd... When I bouhgt that laptop it had windows xp installed and took about 10 minutes to load the os and another 10 minutes to start IE

Now it's fast as hell and the OS lives on less than a gig of memory (including x etc!!!). Got to love it
 
Old 12-03-2006, 06:55 PM   #35
dhubsith
Member
 
Registered: Dec 2006
Location: New Mexico, USA
Distribution: Slackware
Posts: 72

Rep: Reputation: 25
I don't know if this would be helpful to anybody, but this is the set of packages I select when I install Slack. In addition to these, I install k3b and kernel-headers-2.6.18. I install a "barebnz" kernel without modules from a floppy. Later I build a real kernel and install many packages by compiling. I end up with a light, fast system. BTW Frankenputer and Franz are the names of my computers.

A. floppy, gawk, glibc-zoneinfo, gpm, infozip, (and on Frankenputer: cups)

AP. cdparanoia, cdrdao, cdrtools, diffutils, dvd+rw-tools, groff, man, man-pages, normalize, vorbis-tools, (and on Frankenputer: espgs, gimp-print, gnu-gs-fonts), (and on Franz: lm_sensors)

D. REMOVE: kernel-headers

F. (leave all as they are)

L. atk, cairo, expat, glib, glib2, glibc, gtk+, gtk+2, jre, libao, libart-lgpl, libidn, libjpeg, libmad, libmng, libmusicbrainz, libogg, libpng, libtiff, libungif, libvorbis, libxml2, libxslt, mpeg_lib, ncurses, pango, pcre, zlib (and on Frankenputer: libusb) (and on Franz: glut)

N. dhcpcd, nmap, ntp, tcpip, wireless-tools

X. (leave all as they are)

KDE. kdeaddons, kdeadmin, kdebase, kdegraphics, kdelibs, kdeutils, qt
 
Old 12-12-2006, 03:45 PM   #36
Chikne
Member
 
Registered: Jul 2006
Distribution: Slackware 11
Posts: 140

Original Poster
Rep: Reputation: 15
Gosh something gave me quite a headache. Does anyone know what kernel headers are there for? I mean I know that they are needed (I kept getting errors with cpp while trying to ./configure squid without kernel headers) but is it some kind of thing that's used to compile the whole distribution??
 
Old 12-12-2006, 06:12 PM   #37
dhubsith
Member
 
Registered: Dec 2006
Location: New Mexico, USA
Distribution: Slackware
Posts: 72

Rep: Reputation: 25
I'm sure no expert in this but this is what works for me. You need kernel headers from somewhere to compile, and you should either use the 2.4 kernel headers that come in the "D" library, or the 2.6 headers from testing.

I use the 2.6.18 headers, and I'm running a 2.6.19 kernel.
 
Old 12-13-2006, 04:08 AM   #38
mikieboy
Member
 
Registered: Apr 2004
Location: Warrington, Cheshire, UK
Distribution: Linux Mint 19.1 Xfce
Posts: 555

Rep: Reputation: 33
Kernel headers? Its one of those things you never really think about. I got this quote from http://linux.maruhn.com

Quote:
Description: Kernel-headers includes the C header files for the Linux kernel. The header files define structures and constants that are needed for building most standard programs. The header files are also needed for rebuilding the kernel.
 
Old 12-13-2006, 06:01 AM   #39
Chikne
Member
 
Registered: Jul 2006
Distribution: Slackware 11
Posts: 140

Original Poster
Rep: Reputation: 15
I just find it a bit odd that we have to keep some completely different (2.4.33 for instance)kernel headers files to build a 2.6 kernel...
It is certainly something that I never thought about

This website:

http://linux.maruhn.com/sec/kernel-headers.html

keeps some kernel headers but it seems a bit of a mess (unless it's me), it's all mixed up between different versions and might need a bit of patience to find the right files ^^
 
Old 12-13-2006, 06:33 AM   #40
mikieboy
Member
 
Registered: Apr 2004
Location: Warrington, Cheshire, UK
Distribution: Linux Mint 19.1 Xfce
Posts: 555

Rep: Reputation: 33
Chikne, the kernel headers on that website are debian. I wasn't suggesting you should use them, I was just quoting their explanation of kernel headers. They do seem a bit mixed up but, since debian apt resolves dependencies, it will automatically install the correct headers when you upgrade the kernel. Hence I don't suppose debian users are all that worried about the order of them.

I'm sure someone will correct me if I'm wrong but if you're downloading a new kernel for slackware you should be able to determine the correct kernel headers by looking for dependencies on the download site.

For example look at:

http://packages.slackware.it/browse....inux-2.6.17.13
 
Old 12-13-2006, 07:20 AM   #41
KleB
Member
 
Registered: Jan 2006
Location: Slovenia
Distribution: Slackware, Gentoo
Posts: 97

Rep: Reputation: 15
The first thing is, you *don't* need kernel headers installed to compile kernel itself. All the relevant headers for the kernel being compiled come with sources for the kernel.
Kernel headers package is used for programs that link to some kernel stuff. The headers are put in the standard include path, so that compiler finds them easily. And you must note that external programs don't really need all the headers there. There are a *lot* of internal kernel structures that no other program should ever worry about them. That's why there are folks who do some "cleanups" of kernel headers to remove unnecessary stuff, and so on. There is a lot written somewhere in this forum about this subject. Search...

What you need to note is, that the majority of this headers are compatible between different kernel versions. If they weren't, you'd have to recompile everything that linked to the old kernel upon installing new one (most notably, glibc, but also nearly everything else). The main reason that kernel headers are not completely compatible, are new features and, from time to time, removal of obsolete legacy structures. In case you want to use the new features, it's often not enough to replace the headers, but also recompile glibc. And if your system uses some functions that are gone, you also have to recompile that stuff upon changing kernel (but I think that's a quite rare thing, you have to use an extremely outdated kernel to experience these problems).

So, as a logical conclusion of these facts, it is recommended to use the headers that the glibc was compiled against. In this way you achieve maximum coherence of your system. As in the case of slackware, glibc was compiled against 2.4.33 AND 2.6.xy headers (2.6 was used for NPTL support). So, if you *want* other programs compiled with NPTL, you use 2.6 headers, otherwise it's doesn't matter which you use.

This is, how I understand things. I know that I know very little, so feel free to correct me or enlighten me more!
 
Old 12-13-2006, 08:22 AM   #42
Kingscriber
Member
 
Registered: Nov 2004
Distribution: Slackware, CentOS
Posts: 85

Rep: Reputation: 16
As a slack user, and a fedora user and an experienced developer, I am seeing a couple of different scenarios here with depenedencies. I recognize that there are libraries on linux called shared objects which are basically dll's in windows lingo. Lets say Program X uses method or function signature Y of shared object(s) Z on the system..

Now I have heard that in this scenario :
Quote:
the beauty of Slackware is that dependencies, if there are any, are in the program you are trying to compile.
Well that would ultimately be depeneded on the person writing Program X. But lets say that Program X depended on shared object(s) Z being on the system.

Lets say I want to install Program X, but I have a different version of shared object(s) Z on the system with either no function signature Y or changed function signatures. We all of a sudden have a problem, because Program X needs shared object(s) Z but all of the other programs that come with that distro happen to need that particular version of shared object(s) Z.

I suppose my question is, what is the frequency like for how often this happens? I personally haven't ran into this issue on slackware, but I haven't considered myself to really be self relying on slackware either to the point where I have fully installed everything that I need. I have only installed what I currently needed for whatever job that I have had to do. However for people that use it and no other OS, that might be a different story. I only ask that because of the alternative, such as fedora.

Fedora for the most part has the end user happier on how they manage their packages now. At any rate, programs are built exactly for that distro version and all programs are expected to just 'work'. It's quite simple. You download it, and just install it and it does what it needs to do for you to access and just use it. From a productivity standpoint, I see this as really being the way to go, and I can't see it going in another direction such as slackware, where you have to spend time typing in commands like ldd to find out what deps a program has and reading their site and their readme's and all that other BS as to where I should be able to just 'install' it. Quite simple.

I also say this because of Mac OS. Programs are installed as images and they are basically single folder installations that are dragged and dropped. Their dependencies are tightly nit but where it must make a system call , the OS is being managed to the point where you really don't run into dependency conflicts even across minor revisions, not necessarily revisions. I see fedora almost taking this philosophy and I think it's really working out for them.

If anyone has ever played around with InstallShield or Wise for Windows Installers or even just plain 'ol Windows Installer you will notice that shared objects (in slackware / linux terms) are revisioned and your program relys on those certain revisions. When you start overwriting or installing certain modules you do have a chance that you could break other programs on the system. Luckily Microsoft handles certain important shared dependencies for you so that you as a developer can count on things being there and 'just working'.

I suppose what I am trying to say is, there is a speed and time detriment here with slackware because programs aren't being managed for the distro at hand.
 
Old 12-13-2006, 05:16 PM   #43
KleB
Member
 
Registered: Jan 2006
Location: Slovenia
Distribution: Slackware, Gentoo
Posts: 97

Rep: Reputation: 15
I think that dependency checking is the least important feature of a package management system/distro. It's not difficult nor does it take a lot of time to find out all the neccessary dependencies of a given package, the most time is consumed while compiling things and possibly find an obscure build bug, try to find a patch for it, usually a trivial thing, but still it takes time.
So the thing that matters is just the number of programs that you can just type install_me_that_thing - and it gets installed for you.
Dependency checking can just introduce a lot of trouble into the simple process of installing a package. If you install the package, try the program, see that it doesn't work, install another package,... and so on, you don't loose much time. Where you really loose time, is when compiling all this stuff from source.
I speak this from my personal experience with fedora, debian, mandrake, suse, ... which were all so difficult to manage and I was never satisfied with how things work. The only package management system with dependency resolution that seems to work is portage from Gentoo (mainly due to the *lack* of reverse dependency resolution!) - but thats just my observation of people who have gentoo installed - I really don't want to spend so much time installing my system.
So I "ended" up with Slack, which has a good package manager, no unnecessary dependency resolution, but a smaller pool of packages. This is the *only* downside of Slackware, and the strongest point of gentoo. So, when I have to compile an rather obscure program, I often take a look at what patches gentoo ebuilds apply, this really helps saving time...
 
Old 12-14-2006, 08:10 AM   #44
Kingscriber
Member
 
Registered: Nov 2004
Distribution: Slackware, CentOS
Posts: 85

Rep: Reputation: 16
Quote:
KleB: I think that dependency checking is the least important feature of a package management system/distro. It's not difficult nor does it take a lot of time to find out all the neccessary dependencies of a given package, the most time is consumed while compiling things and possibly find an obscure build bug, try to find a patch for it, usually a trivial thing, but still it takes time.
So the thing that matters is just the number of programs that you can just type install_me_that_thing - and it gets installed for you.
At some point you want a distro that you can just "use". That's it, you shouldn't have to fiddle with package this .so that. You just want to install it, start installing some of your applications and just use it. That's it. When you start taking time for a particular package...multiply that by the number of packages. It can add up.

Now in slackwares defense, you shouldn't be installing programs everyday. There is a threshold as to where you are done installing programs and you should be able to just 'use' the programs you installed, however you did them or even how long it took you. What about upgrades? What kind of issues would that introduce that you really don't want to encounter vs. a distro that has the package custom built for that distro anyways? It would just install...where it should be..properly.

Here is my main point. The same reason as to why windows is successful is for the same reason that slackware isn't. I define successful in this case in market shares and desktop preference, even though slackware is a very successful distro flavor of linux bar none. When everyone is experiencing the joys of package management and all the slackheads are still fumbling attempting to install x y and z, it just seems like people are sticking to it for legacy reasons.

Some of you make slackware work in a professional environment and have success, my hats off to you. However, from a business stand point, I am not too sure where superiors are comming from when they can save time ( = money ).

I look at slackware and other distros as tools. Slackware is great for a server. Easy to setup and deploy as a rock solid server. Fedora I use it or even Suse for different reasons, such as development and entertainment. Am I off on those?
 
Old 12-15-2006, 04:25 AM   #45
mikieboy
Member
 
Registered: Apr 2004
Location: Warrington, Cheshire, UK
Distribution: Linux Mint 19.1 Xfce
Posts: 555

Rep: Reputation: 33
Originally posted by KleB:
Quote:
I speak this from my personal experience with fedora, debian, mandrake, suse, ... which were all so difficult to manage and I was never satisfied with how things work. The only package management system with dependency resolution that seems to work is portage from Gentoo (mainly due to the *lack* of reverse dependency resolution!) - but thats just my observation of people who have gentoo installed.
Of course all of this is subjective and each of us has a different experience. My personal experience of Debian vs Gentoo is that, while both package management systems are equally good, Debian has the advantage in that it doesn't mess with configuration files when you do a global upgrade whereas with Gentoo you have a significant amount of work to do on your config files afterwards.

In fact it was performing etc-update which screwed my Gentoo installation so totally that I gave up on it and moved to Debian. I was a bit upset because it takes quite a long time to get a Gentoo system compiled and configured and I didn't want to start all over again.

Again my experience; Debian is very low maintenance and I'm not clear why you found it difficult to manage. It's true that some of it is a bit peculiar to Debian and I'm still on that particular learning curve.

As for Slackware, I used it happily for eighteen months but an upgrade from v10.0 to 10.2 defeated me. It still remains to be seen what will happen when I dist-upgrade from Sarge to Etch when Etch becomes the stable version.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Dependency Hell Mithrilhall Linux - Newbie 5 04-28-2006 10:29 AM
please help me I'm in dependency hell baronsam Linux - Software 5 11-05-2004 09:33 PM
dependency hell riseringseeker Linux - Newbie 3 09-22-2004 01:57 PM
Is this what they mean by dependency hell? john_walsh54 Linux - Software 1 10-10-2003 07:52 AM
Dependency Hell Time Lord Mandriva 2 09-09-2003 03:48 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:41 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration