What features/changes would you like to see in future Slackware?

hitest · 02-04-2015, 11:29 PM

If the team feels it is stable enough it looks like XFCE 4.12 is going to be released soon.

ReaperX7 · 02-05-2015, 12:44 AM

Maybe 4.12 can make it in before the deadline?

genss · 02-05-2015, 06:27 AM

fluxbox looks like it'l hit a new release soon

GazL · 02-05-2015, 02:48 PM

One "feature/change" I'd like to see adopted in slackware would be to have the filenames of members of /etc/profile.d/ enumerated, so that order of execution could be enforced. So, something like:

Code:

bash-4.2$ ls /etc/profile.d/*.sh
/etc/profile.d/50-bsd-games-login-fortune.sh
/etc/profile.d/50-coreutils-dircolors.sh
/etc/profile.d/50-glibc.sh
/etc/profile.d/50-gtk+.sh
/etc/profile.d/50-lang.sh
/etc/profile.d/50-libglib2.sh
/etc/profile.d/50-mc.sh
/etc/profile.d/50-pkgconfig.sh
/etc/profile.d/50-qt4.sh
/etc/profile.d/50-scim.sh
/etc/profile.d/50-t1lib.sh
/etc/profile.d/50-tetex.sh
/etc/profile.d/90-dot-in-non-root-path.sh

This would then allow for stuff like setting the default manpath (which needs to be done before any others are added) to be moved out of /etc/profile itself (10-manpath.sh), and /etc/profile could be kept very minimal (little more than the for loop), allowing more flexibility of configuration without having to alter shipped files and generally making ongoing maintenance much easier. It also avoids ugly names like "z-dot-in-non-root-path.sh".

It's a trivial matter to change post-install, but doing it locally means that subsequent package updates can clobber it, which is not ideal.

RSanna · 02-05-2015, 10:59 PM

Quote:

Originally Posted by Alien Bob

All you KDE "bashers" - nobody forces you to use it or even install it. Slackware works well with whatever DE you choose, from Fluxbox to FVWM XFCE, and even to 3rd-party Mate to LXQT. I'd say that is a lot more freedom than you will get in some of the major distros.
Of course, there are some serious KDE fans in the Slackware core team, so it will not be too likely that KDE will at some point be removed from the core distro. But you never know what the future brings. I will keep providing the latest KDE packages until the point where Slackware is unable to support that latest KDE.

The KDE 4 in Slackware is a mature and stable desktop environment. Sure, KDE 4.0 had issues but Slackware never shipped that version. Instead we waited until the 4 series reached the point of being production-ready and then added it (coïnciding with the initial release of 64-bit Slackware).
The same will happen for KDE 5 aka Plasma 5. Currently it is lacking some features compared to KDE 4, but the migration path from KDE 4 to Plasma 5 is free from big hurdles. There are lots of applications in Plasma 5 which are still based on Qt4 and KDE 4 core libs, and with the passing of time those will be ported to Qt5 and Frameworks 5. Inbetween, you will have a Plasma 5 desktop with all the applications available that you knew fromKDE 4. The 3rd party apps that build on KDE 4 will remain functional, and there is lots of time to migrate to Qt5.

KDE 5 aka Plasma 5 is still under development, which means you won't see it in Slackware for at least another year. There will be some dependencies that I am trying to avoid: systemd (still easy to avoid in KDE but not adding it causes a minor loss of functionality) and wayland (the compilation of KWin for X11 has a hard dependency on wayland even when it does not use wayland at runtime).

In the meantime, those of you who like working with KDE can download and install the latest KDE 4, and next week the latest KDE 5 (Frameworks 5.6.0, Plasma 5.2.0 and Applications 14.12.1 combined with the core KDE 4 libs).
See http://alien.slackbook.org/blog/usin...king-on-kde-5/ for my story on KDE 5 for Slackware and http://taper.alienbase.nl/cgit/ktown/log/?h=5_15.01 if you want to follow my KDE.SlackBuild development closely.

Finally, several of you are boldly stating that KDE is a maintenance burden comparable to Gnome. Well, let me tell you that it is not. With every new major release (KDE 4, Plasma 5) there is a one-time effort to get the KDE.SlackBuild build framework adapted but then it is easy as pie to create packages and keep up to date. Adding new packages is also very easy. Effectively, I have taken the "burden" away from Patrick.

My apologies to KDE fans and supporters! I am new to forum debate and improperly seized an
opportunity to advocate a toolkit Desktop Enviroment over a Total Desktop Enviroment, not only inportuning KDE's reputation but revealing my ignorance as well. I Used KDE up until vers. 3.5 , then discovered another. Not returning to KDE at all, but relying instead on rumor. I do humbly apologize.

dugan · 02-06-2015, 10:00 AM

I'd like to see the Fish shell.

As for the "it's on SBo" response, I have this to say. The selection of shells included with the distribution is one factor that scripters will look at when deciding which one they can take advantage of to use as a shebang. It's like with web browsers on Windows, where developers have to look at which web browser comes with the installation and target that.

Besides, Slackware already includes a wide and good selection of shells. It sets itself above the rest by including ZSH, for example. Why not one more?

kikinovak · 02-06-2015, 10:42 AM

Did I say Linux-PAM? Please?

T3slider · 02-06-2015, 11:53 AM

bash recompiled with SYS_BASHRC defined (see config-top.h) and aliases copied from /etc/profile.d/*.sh to /etc/bash.bashrc or similar. Since this is a bash-specific feature I guess aliases should stay defined in /etc/profile.d/*.sh to support other (non-bash) login shells but at least bash could be fixed so that a full/typical environment is defined in non-login shells without having to define a .bashrc for every user (or having to re-run /etc/profile in non-login shells or run fake login shells, which duplicates data in some environment variables and is just poor form).

kkady32 · 02-06-2015, 12:39 PM

anacron

notKlaatu · 02-06-2015, 04:22 PM

It would be nice if the glew package were built with libglewmx enabled.

Code:

make install.all GLEW_DIR=$PKG/usr

libglewmx is not built with the standard `make install` command, so it needs re-building if you are doing high-end GL work that requires libglewmx.

Not really a huge deal, but since the question was asked, I figured I may as well respond with that small wishlist item.

larryhaja · 02-07-2015, 11:08 AM

Quote:

Originally Posted by notKlaatu

It would be nice if the glew package were built with libglewmx enabled.

Code:

make install.all GLEW_DIR=$PKG/usr

libglewmx is not built with the standard `make install` command, so it needs re-building if you are doing high-end GL work that requires libglewmx.

This is another one I'd like to see as well.

rworkman · 02-15-2015, 11:06 PM

I like the /etc/profile idea, Gazl - I passed that up the chain for consideration.
Larry and Klaatu, I added libGLEWmx.so to the glew build in my local queue.

ReaperX7 · 02-15-2015, 11:28 PM

That same enumerated concept for /etc/profile.d could be useful in other parts of the system as well Robby.

Paulo2 · 02-16-2015, 08:57 AM

Quote:

Originally Posted by GazL

One "feature/change" I'd like to see adopted in slackware would be to have the filenames of members of /etc/profile.d/ enumerated, ...

+1
lang.(sh|csh) is one that must be loaded before others to set proper language variables
(or at least before custom scripts, I have 'zgreetings.sh').

dugan · 02-16-2015, 11:55 AM

I'd like efibootmgr to be runnable from the installation DVD.