What features/changes would you like to see in future 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.
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 10:46 AM.
0 members found this post helpful.
Click here to see the post LQ members have rated as the most helpful post in this thread.
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 12:01 PM.
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...
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.
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.
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.
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.
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.
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.
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.
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?
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 ...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.