LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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 04-02-2011, 11:29 AM   #1156
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138

Quote:
Originally Posted by Alien Bob View Post
I would not agree to that. You know, Qt is not KDE specific at all, I run applications here that do not care about KDE at all but do have a Qt interface (VLC, qbittorrent for example). Other packages in "l/" series sucn as akonadi, nepomuk maye be required by KDE but who says that other apps would not like to use those as well?

Eric
Indeed, Qt is not only needed for KDE. Maybe it was a bad example. However, the L series are a lot of libraries that are used only by KDE today. Or others that are used only by GUI.

What I want in the future in Slackware?

First, a clear series division between console applications, the graphic medium / light, such as XFCE, and KDE. What's the point to install akonadi, virtuosso or strigi, into a LAMP server, for example?

Secondly, I would like to perl, python, ruby to be moved from the D series. You need them in a server, but a very good rule of an admin is 'DO NOT INSTALL THE TOOLKIT INTO A SERVER! NEVER!'. I would like that I would not touch the D series, when I make such an installation.

Thirdly, I subscribe to introduce dependencies, for the information, of course, not as automatic system. That would ease my work very much. For that, one of company policies, where I work, is "any unnecessary package is a vulnerability, install only what is necessary." Therefore, when I install an application into a server, I need to find dependencies, to avoid any unnecessary package.

Last edited by Darth Vader; 04-02-2011 at 11:46 AM.
 
0 members found this post helpful.
Old 04-02-2011, 12:58 PM   #1157
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
And another idea ...

As we know, SlackPkg supports Templates. How about an integration of this feature in the installer and have a punctual installation packages for different targets? Maybe something like:

* A stupid console.
* A Mail server.
* A LAMP server.
* An light desktop with XFCE.
* KDE with all the bells.

Last edited by Darth Vader; 04-02-2011 at 01:01 PM.
 
1 members found this post helpful.
Old 04-02-2011, 02:14 PM   #1158
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
Quote:
Originally Posted by ShellyCat View Post
What I meant is I hope Patrick will include python-devel and many other python/qt/sqlite-related packages and header files in Slackware in the future, as increasingly required by several popular, one-of-a-kind software packages. (I use Anki as an example because it's a deal-buster for me, but there are others out there, which I can't recall at the moment.)
I had anki running in 13.0 and it runs fine in 13.1 as well. I haven't tried installing it system-wide and just ran the 'anki' python script in the extracted source archive but there's nothing insane about the two setup.py files it tells you to run so it would probably work as well. Slackware doesn't arbitrarily split applications into runtime and -devel packages so any python headers you need should be installed as far as I know...
Code:
Prerequisites for Linux/FreeBSD/etc:

- a recent Python (2.4 should be fine)
- python-qt/pyqt 4.4+
- sqlalchemy 0.4.3+
- simplejson 1.7.3+
- pysqlite2 1.3+ or python2.5
Slackware 13.1 ships with Python 2.6.4 so the first and last items are satisfied. 13.1 ships with PyQt 4.7.2 so item 2 is satisfied. SQLAlchemy and simplejson are available from slackbuilds.org (and no python recompilation or any such thing is needed).
Code:
For graph generation:

- python-numpy (numpy)
- python-matplotlib (matplotlib)

For audio playing support:

- mplayer

For audio recording support:

- sox 14.1+
- pyaudio
- lame

For importing SuperMemo XML and exporting text files:

- python-beautifulsoup
The only thing that is not available from slackbuilds.org (and does not ship with Slackware) is pyaudio (python-beautifulsoup is known as BeautifulSoup at SBo), so you'd have to get it elsewhere or install it manually. That is of course an optional dependency (which itself depends on PortAudio, which is available at SBo).

If something's not working, I don't think it's a python headers issue...
 
1 members found this post helpful.
Old 04-02-2011, 03:27 PM   #1159
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
What I meant is I hope Patrick will include python-devel and many other python/qt/sqlite-related packages and header files in Slackware in the future, as increasingly required by several popular, one-of-a-kind software packages.
Is the problem that python headers are not included or only that certain apps can't find the headers?

Quote:
As we know, SlackPkg supports Templates. How about an integration of this feature in the installer and have a punctual installation packages for different targets? Maybe something like:

* A stupid console.
* A Mail server.
* A LAMP server.
* An light desktop with XFCE.
* KDE with all the bells.
That is an idea to consider. That can be challenging because there are so many options and cross-options that could be listed.

Yet I hope that if Pat decides to offer such options he always installs all development related packages as part of the default.

One reason I stick with Slackware for my personal use is Pat does not split packages into user and development packages. I hope he never does. I like all-in-one. Often I test other distros in VirtualBox, which to be useful requires the VirtualBox guest additions, which to compile requires the kernel headers. To a high degree most distros do not include the kernel headers and that requires additional steps to download. Frustrating in a 800x600 screen. I have been testing Current in a virtual machine and I never blinked about installing the guest additions.

Debian based systems are frustrating in this way. Installing the VirtualBox guest additions is a mini-circus because the development build system has to be installed as well as kernel headers.

In this day and age of testing in virtual systems, including basic build systems and kernel headers should be automatic for any distro, even if that adds another 50MB or so to the CD/DVD size.

This is true too for installing any software that requires the kernel headers, such as the nvidia drivers or VirtualBox.
 
Old 04-03-2011, 01:10 AM   #1160
DragonM15
Member
 
Registered: Sep 2003
Location: USA
Distribution: Slackware (Multiple Versions)
Posts: 455

Rep: Reputation: 31
Quote:
Originally Posted by Darth Vader View Post
To be honest, avoiding installing KDE is much more complicated than it seems.

In L set we have a lot of KDE-specific libraries, starting with the famous Qt. Maybe we should move all the KDE-specific libraries in the KDE set, or even in its own set, KDE_LIBS?
I agree with this idea. Maybe not the Qt specifically, but other kde-specific libraries definitely.
 
Old 04-18-2011, 04:43 AM   #1161
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
Does anyone know why does rc.M have those lines for updating mime db, ldconfig, font cache and those gtk stuff run on each reboot? I am talking about the situation described here

My only guess is that those were added at some point in order to make sure they were applied to all applications without rebuilding them and gradually adding a post installation script to the packages thats needed in order to take advantage of them.
Pkgtools are perfectly capable of handling post installation scripts in doinst.sh but i dont think i see them gradually get added there if that is indeed the case.

Boot time is delayed significantly for absolutely no reason, at least from my point of view.
I doubt there is even one person who needs those to run during every system boot.

Last edited by sahko; 04-18-2011 at 04:45 AM.
 
Old 04-18-2011, 04:51 AM   #1162
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
Actually i just thought of a case where a person will need those to run on every boot.
Its a person who (re)boots once per Slackware release doing a clean installation each time.

edit: Another use case where these might be needed. Probably a more common one.
When someone builds packages from source and neglects or doesnt know he has to run those himself.
All packages from SBo contain post installation scripts for those so it shouldnt be a problem then.

Last edited by sahko; 04-18-2011 at 09:51 AM.
 
Old 04-18-2011, 11:57 AM   #1163
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Quote:
Originally Posted by sahko View Post
My only guess is that those were added at some point in order to make sure they were applied to all applications without rebuilding them and gradually adding a post installation script to the packages thats needed in order to take advantage of them.
Pkgtools are perfectly capable of handling post installation scripts in doinst.sh but i dont think i see them gradually get added there if that is indeed the case.
A post-installation script won't work very well if the commands that it needs to use are in another package that isn't installed yet. Rather than introduce install-order dependencies, we make sure those things are run at boot time. Now, I can't say that I'm 100% happy with it (and I'll avoid ranting about registry-like systems), but I would rather have it take 10 more seconds to boot if it means that a few percent of machines out there will catch a problem at boot and work fine when they otherwise would have suffered strange problems.
 
5 members found this post helpful.
Old 04-18-2011, 12:12 PM   #1164
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
Well, my boot sequence always goes like this.

Power-on PC...
wait...
enter luks password for rootvg.
Go to kitchen and power-on kettle...
wait...
Come back to waiting login prompt with steaming cup of coffee in hand.
Use steaming cup of coffee to Power-on brain.

One thing that could be done to speed up the boot would be to signal to the boot scripts whether running the updates is required, in much the same way as fsck doesn't need to run when the filesystem was unmounted cleanly. Could be something as simple as touching a file whenever anyone runs one of the package tools commands and have the boot script check for it's existence, run the updates if it's found and then delete it once the updates have been run.

Having said that, as long as Slackware boots faster than my kettle boils, I don't really care.
 
Old 04-18-2011, 02:56 PM   #1165
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
Does anyone know why does rc.M have those lines for updating mime db, ldconfig, font cache and those gtk stuff run on each reboot? I am talking about the situation described here.
I wrote that article soon after Slackware 12.1 was released. When those tasks were added to rc.M in 12.1, they were run sequentially. The increase in boot time was noticeable. Search the forum for those original discussions.

I go through periods when I tend to reboot often because I experiment often. I never explained that in my original article. Many people boot once a day and the increase in boot time with 12.1 was not painful.

Starting in 12.2 those tasks remained in rc.M but were run in the background. That helped restore the boot time. I never added that information to the original article.

The original article therefore implied those tasks remained as a cause of a perceived slow boot time.

A handful of people who tinker might want to move those tasks from the boot sequence. Most folks won't notice or care.

I updated the article to avoid those misperceptions.
 
3 members found this post helpful.
Old 05-08-2011, 12:06 AM   #1166
afreitascs
Member
 
Registered: Aug 2004
Location: Brasil
Distribution: Slackware_Cur-64_mult
Posts: 433

Rep: Reputation: 30
Have at the time of installation of Slackware, the option to use lilo or grub ...

thanks
 
Old 05-08-2011, 01:27 AM   #1167
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
grub 1 needs a ton of patches and grub 2 is still marked as "Enhancements to GRUB are still being made, but the current released versions are quite usable for normal operation." Lilo just works. Why change?
 
1 members found this post helpful.
Old 05-08-2011, 12:55 PM   #1168
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: SlackwareŽ
Posts: 11,450
Blog Entries: 4

Rep: Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505Reputation: 1505
Hi,

Quote:
Originally Posted by afreitascs View Post
Have at the time of installation of Slackware, the option to use lilo or grub ...

thanks
Personally, I prefer 'lilo' for Slackware. If it ain't broke, don't fix it!
 
1 members found this post helpful.
Old 05-08-2011, 01:41 PM   #1169
afreitascs
Member
 
Registered: Aug 2004
Location: Brasil
Distribution: Slackware_Cur-64_mult
Posts: 433

Rep: Reputation: 30
Hi :-)

I'm not saying to change the lilo by grub, but to add.
Those who prefer lilo, use lilo, those who prefer grub, grub use ...

thank

ps: inclusive, would be more democratic ;-)

Last edited by afreitascs; 05-08-2011 at 02:06 PM.
 
Old 05-08-2011, 06:34 PM   #1170
afreitascs
Member
 
Registered: Aug 2004
Location: Brasil
Distribution: Slackware_Cur-64_mult
Posts: 433

Rep: Reputation: 30
Furthermore, it would be easier for users of Slackware (Slackware which has as its default distribution), which want to install or test other distributions that use grub as boot loader. ... eg:Fedora 14

Of course I think the maintainers of Fedora 14 should also give the option to install lilo ...

Fedora cited as an example only ...

thanks
 
  


Reply

Tags
cd, live


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
Slackware future? coyctecm Slackware 12 02-01-2006 11:03 PM
Future of Slackware kratunko Slackware 30 08-12-2005 01:31 PM
Slackware features? rusty_slacker Slackware 49 12-02-2004 05:45 AM
what are the features of the new slackware 9? ethanchic Slackware 2 09-27-2002 07:15 PM


All times are GMT -5. The time now is 07:32 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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration