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.
It seems to me that, as the Slackbook is included in the release and the CD sets, it would not be in Slackware.com's interest to transfer it to a wiki. It should be something that could easily be assembled into a cohesive structure.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Ideally, there would be one main document catered towards those with no Slackware (or Linux) knowledege, and one catered to experienced Slackware users looking to do advanced things.
Probably the best way for the potential SlackDocs writers to keep up with things is to run -current while participating in the communication channels mentioned previously.
It seems to me that, as the Slackbook is included in the release and the CD sets, it would not be in Slackware.com's interest to transfer it to a wiki. It should be something that could easily be assembled into a cohesive structure.
The 'Slackbook' is also downloadable. Why wouldn't the composition of a 'Slackbook wiki' be in 'Slackware's' interest?
I think it would still be a major task to assemble the 'Slackbook' into a 'wiki' along with updating to bring it current. 'Wikis' are great but do require a lot of time and effort to maintain properly. Add to this the participation one can expect too spend more than originally anticipated. Believe me I know!
1. Fix those everyday bugs in the 12.x series. I've posed some.
2. Add udev to the install ramdisk. It's super easy. Just install the udev package and use the real bash interpreter for /etc/rc.d/rc.udev. Then remove the ancient network script, which is for linux-2.4.
I'd like to see the back of kde for 5 years, until those guys stop writing code and scripts, and start deleting them.
I've a 2.6 Gig Athlon XP, 1 gig of ram, and all I see is an hourglass.
I'd like to see LD_LIBRARY_PATH set by default in terminals.
That is odd, KDE 3.5.10 runs well enough on my IBM Celeron 850 with 768 MB RAM running Slackware 12.2. On my main Slackware 12.2 work station, a Dell Optiplex GX620 Pentium D, 2.80 GHz, with 2 GB RAM, KDE 3.5.10 is ripping fast!
I'm not experiencing a lot of lag. KDE should be quite fast on your unit.
It seems to me that, as the Slackbook is included in the release and the CD sets, it would not be in Slackware.com's interest to transfer it to a wiki. It should be something that could easily be assembled into a cohesive structure.
There are wiki backends which could produce latex, docbook outputs, whichever you prefer.
Anyway, projects needs to get some official support (best way would be with appointed native speakers experienced in technical writing like woodsman as responsible editors) or otherwise it will stall soon (as being yet another separate project).
BSD handbook is a state of art, which a distro like Slackware should have had 10 years ago or smth.
Last edited by Alien_Hominid; 01-03-2009 at 01:29 PM.
My wish list:
|_
Slack 13
_/
1. http://www.tiddlywiki.com/ -- Create a Slackware Cook Book, Diary
2. http://packages.debian.org/lenny/acpi-support -- Several scripts that enable control of various laptops (minor tweaking necessary to run on Slackware)
3. Avoid SCSI emulation for IDE devices (hda -> sda) Ubuntu/Debian? What a mess
4. Avoid SELINUX.
5. NetworkManager should be included, it's not that hard to build.
# = build order
a.libnl-1.1
b.libtasn1-1.1
c.gnome-keyring-2.22.1
d.GConf-2.22.0
e.ORBit2-2.14.12
f.dhcdbd-3.0
g.network-manager-0.6.6
h.KNetworkMananger
6.Hand over KDE packaging to a 3rd party. Focus should be on the base system, we only see a subset of the possible functionality. I'm sure there are volenteers.
7.GTK-QT should be included by default!
8.libFreetype, I seriously doubt MS or Apple are going to make good on their patent claims so go ahead and enable the sub-hinting techniques.
9.PostgreSql and MySQL
A.Include a few custom kernels, HugeP4, HugeP3, HugeXenon, HugeIbm, FailSafe there is a noticable difference.
B.More utilities for Busybox, lilo, full vim, mc
C.The modules built for the kernel being used. I think they lack a few, but I could be wrong.
D.Continue to include all source code on the media.
My wish list:
|_
Slack 13
_/
...
A.Include a few custom kernels, HugeP4, HugeP3, HugeXenon, HugeIbm, FailSafe there is a noticable difference.
...
I'd especially like to see a minimal failsafe kernel provided on the installation media, not just huge.s and hugesmp.s.
A couple of us have run into a situation where the both the huge kernels lock up at boot, likely because some device driver is incorrectly autodetecting SCSI RAID hardware we do not have. It would be good if we could simply boot a more minimal kernel so we could complete the install and compile a custom kernel.
5. NetworkManager should be included, it's not that hard to build.
# = build order
a.libnl-1.1
b.libtasn1-1.1
c.gnome-keyring-2.22.1
d.GConf-2.22.0
e.ORBit2-2.14.12
f.dhcdbd-3.0
g.network-manager-0.6.6
h.KNetworkMananger
Most of those are at least include on SBo (all but the last three). Though according to SBo you build order appears incorrect. gnome-keyring needs GConf which in turn needs ORBit2.
Have you actually looked at the contents of that package? Unless one of wakes up one morning with a desire to maintain a bunch of kludges, don't expect to see that in Slackware.
Quote:
3. Avoid SCSI emulation for IDE devices (hda -> sda) Ubuntu/Debian? What a mess
Generally speaking, you can expect Slackware to do whatever the kernel's default is. What would be "a mess" is trying to do something else.
Quote:
4. Avoid SELINUX.
Um, sure. In other news, there are no plans to include Mono, VMWare, or the Hurd kernel either.
Quote:
5. NetworkManager should be included, it's not that hard to build.
# = build order
a.libnl-1.1
b.libtasn1-1.1
c.gnome-keyring-2.22.1
d.GConf-2.22.0
e.ORBit2-2.14.12
f.dhcdbd-3.0
g.network-manager-0.6.6
h.KNetworkMananger
Right... Let's include a few core gnome libraries. Once those are in, we can add libgnome and a few friends too, since they're small. Hell, why not just add gnome back to Slackware.
Okay, so that's not what you were saying; fine. Either way, it's not that simple.
First, these requirements were for the older <=0.6 NM versions, which were horribly unreliable, even for many people on distributions that actually supported it. The nm-applet requires gnome, and while you may think KNetworkManager is plenty enough, it's not -- a sizable portion of Slackware's users are Xfce folks, so shipping a network management app that requires them to load kde libraries is a bit appalling, if only to me.
Second, the newer 0.7.x versions of NM have a hard dependency on PolicyKit, which is not even close to stable/usable for us, and in fact is being rewritten right now. Based on the current status, I can't even say *if* we'll ever see PolicyKit in Slackware, so I certainly can't say *when* we'll see it. I said all that to say this: even if NM-0.6.6 is rock-stable and works for every person every time, it's dead code. Sooner or later (probably sooner, like yesterday), someone else will be whining about getting the new shiny version of it. Now what? Not only can we not do that, it's going to be even worse -- once the core libraries and such that it's built on become incompatible, and/or there's a security hole that upstream doesn't address (because it's unmaintained code, remember?), guess what happens to NetworkManager? Yep, it gets a "Removed: ..." line in the ChangeLog.
Quote:
6.Hand over KDE packaging to a 3rd party. Focus should be on the base system, we only see a subset of the possible functionality. I'm sure there are volenteers.
Whether there are or aren't volunteers is irrelevant. All things considered, maintaining the kde package set is EASY.
Quote:
7.GTK-QT should be included by default!
Why?
Quote:
8.libFreetype, I seriously doubt MS or Apple are going to make good on their patent claims so go ahead and enable the sub-hinting techniques.
This might be the most ridiculous thing in your entire post. Note that I said "might" - in the law enforcement world, they call that a clue.
Quote:
9.PostgreSql and MySQL
Um, MySQL *is* included. If you want pgsql, then you can build it yourself. You should be okay with that -- after all, you just said earlier that "focus should be on the base system."
Quote:
A.Include a few custom kernels, HugeP4, HugeP3, HugeXenon, HugeIbm, FailSafe there is a noticable difference.
Remember that "might" above?
Quote:
B.More utilities for Busybox, lilo, full vim, mc
Look! There it is again!
Busybox is only used in the installer - is that what you're talking about here? If so, maybe there's some room for enhancement there; we've discussed a few things. However, a full vim and mc were not (and probably will not be) among them.
Quote:
C.The modules built for the kernel being used. I think they lack a few, but I could be wrong.
That doesn't really make sense, so I'm leaning toward "yes, you are."
The Five key features that slackware needs to have before I will ever use it are as follows:
1. A graphical user interface from ground zero (first boot) as i am vision impaired and it gets hard for me to see the command prompt.
2. Out of of the box support for Lenovo 300 N5900 series lap tops.
3. A pre-compiled binary package of Virtual Box
4. An AMD 64 specific release
5. Out of the Box support for nVidia graphics and on board Network interface Cards (NIC).
#1 and #3 probably will never happen.
If #2 is fine on other distributions, it should on Slackware.
#4 may happen sooner or later.
If #5 is fine on other distributions, it should be fine on Slackware. If #5 is dependent on having the binary blobs, well, tough shit.
Conclusion: nothing has changed. Either you'll use Slackware, or you won't use Slackware. Nobody is going to come throw rocks at your house if you don't, and nobody is going to bring you a cookie if you do.
"Either you'll use Slackware, or you won't use Slackware. Nobody is going to come throw rocks at your house if you don't, and nobody is going to bring you a cookie if you do."
I love it, Robby!
Can I have my cookies now? Yeah? Yeah?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.