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.
Try to remember that Slackers are technical people, computer savvy people. A majority of the computer users today are office people and non technical users of computers. That does not mean they like Windows but without the technical expertise they are not going to try to install a new operating system. A Live CD allows people to test systems.
To most non-technical users, the GUI is the OS. Sorry if I sound negative (I'm trying not to ) but I hardly think your average office worker can tell the difference between Kubuntu or Slack. A 'Slackware LiveCD' to them is a 'KDE-preview CD'. And the default KDE, again, I love it because I don't need to turn things off but only need to build it up... but as a preview it's quite plain and little exciting.
Perhaps that technical users would benefit from a LiveCD though. But I'm thinking, they might just as well benefit just as much from a VirtualBox image?? I mean, I understand your point, but virtualization has become childsplay. It may have more to offer than a LiveCD? I've not run a physical LiveCD in ages, and I've not dual booted either, because it's fast, stable and very convenient to run something virtually.
Quote:
Originally Posted by shadowsnipes
One of the Slackware team members, for instance, could make a copy of their custom setup to a VirtualBox image (BSD girl background images and all). They would also probably want to take out any sensitive information or user docs that others don't need and change any configs needed to fit the default virtual hardware. A brief description of the setup could be included where the VBox image is hosted. Multiple images could even be included for different setup examples- or better yet, one image with multiple Slackware installation examples on separate virtual partitions.
Yeah, this seems like a good idea to me. It would be easier than creating a LiveCD/DVD in terms of hardware compatibility, and images can be more focused towards a task. Slackware desktop/Slackware webserver/Slackware whatever.
I'm almost thinking it would be Instant Slackware.
Last edited by /dev/me; 07-02-2009 at 04:14 AM.
Click here to see the post LQ members have rated as the most helpful post in this thread.
As I mentioned previously, one way to at least minimize the second problem would be to create a VirtualBox image instead of a LiveCD.
A VBox image demonstrates the system better than a LiveCD, but does not allow to see how the system works with user's actual hardware. Installation to a file system image in a file, like Wubu, is even better. I guess Slackware may be simpler than Wubu - install to a file system in a file and boot that image from the installation media, so that the addition of a single file is indeed the only change to the user system, be it Windows or Linux.
Another problem with live CD/DVDs is they run from a noisy drive buzzing in your ear and can be relatively slow. Live mini distros (Wolvix cub - or Puppy linux etc) that run off USBflash-or loaded into RAM are far better for a user experience. One can then experience the slackware zippy response.
A VBox image demonstrates the system better than a LiveCD, but does not allow to see how the system works with user's actual hardware. Installation to a file system image in a file, like Wubu, is even better. I guess Slackware may be simpler than Wubu - install to a file system in a file and boot that image from the installation media, so that the addition of a single file is indeed the only change to the user system, be it Windows or Linux.
The problem with that is that the user would have to configure the mini Slackware for their hardware, so they would not be able to get a quick snapshot. The main draw of the VBox image is that it would be instantly ready to allow the user to preview some example Slackware setups. The user could start imagining the possibilities they could create with Slackware. They could experiment with pkgtools (and that sbopkg they heard about), etc to see if they like the "admin tools". They could marvel at the stability of a properly setup Slackware install. If a new Slackware user botches a fs on file system Slackware install they will probably just assume that Slackware has a lot of bugs or isn't compatible with their hardware. I highly doubt Slackware is incompatible with any typical (non-exotic) hardware, so spending a lot of dev time for startup tricks to autodetect and configure hardware is probably unnecessary. Slackware has proven over and over to stable. Is it a system that the user can make their own? Can they make it what they are looking for? The VBox snapshots can quickly give them a ballpark answer for this.
One challenge to a virtual imaage is the size. A Live CD can fit on a standard 700 MB disk. Even with compression a virtual image will be larger.
I'm thinking in terms of downloading, not storage requirements. Downloading a CD image is one thing, downloading a virtual hard drive image might be too much for many people.
OMG this thread on the 8th page? Must be a sin. Or i guess too many people are content with the 64bit port and KDE4 in -current.
Earlier in ##slackware , Lord_Khelben asked the following:
Quote:
i read the new updates in -current yesterday and there was an update for shadow. i have always wondered why is shadow-4.0.3 still used ? are > 4.0.3 versions PAM only or something ?
i have the impression that there was a discussion in the slack 8.0 time but i may be wrong. i cant remember (and there are even major releases since there)
But he didnt get an answer. Does anyone know whats the deal with shadow?
shadow is a low priority consideration, to be honest. Is there some good reason that a newer version needs to be considered? Otherwise, what we have works just fine and doesn't have any known bugs.
Pre-install or make available compiled packages of
fftw
What needs this? Nothing in the tree now can even use fftw iirc, so it's only some other additions (perhaps suggested here) that would need it.
Quote:
ffmpeg
Patent issues in USA, right?
Quote:
vlc
Patent issues in USA
Quote:
aqualung
What the hell *is* this? More importantly, that's a rhetorical question. If I've never heard of it, there's a better than average chance that it doesn't belong in a "general purpose" OS.
Quote:
virtualbox-ose ver. 3.0.2
That's easy enough to install yourself, and it's large, and then it opens the door to other virtualization software. Why not qemu and kvm too?
Quote:
jack-audio-connection-kit
What needs it?
Quote:
pulseaudio (if it works!)
You don't even know if it works, and you're suggesting that it be added??? WTF?
For what it's worth, do a google search on pulseaudio - I don't think too many people are happy with it.
Quote:
enable UTF-8 in X & console
Enable it yourself - see /etc/lilo.conf and /etc/profile.d/lang.sh
Pre-install or make available compiled packages of
fftw
ffmpeg
vlc
aqualung
virtualbox-ose ver. 3.0.2
jack-audio-connection-kit
pulseaudio (if it works!)
enable UTF-8 in X & console
some of these packages takes considerable time to compile. Took me a few hours to complete, especially with the required dependencies.
Why not build packages for Slackbuilds or wherever if you feel that others would need such animals? Just because a few might use there's no reason to include in the distribution.
Most of those things are available from slackbuilds.org, and using SlackBuilds is easy with sbopkg (not that it was difficult before, but it was slower).
shadow is a low priority consideration, to be honest. Is there some good reason that a newer version needs to be considered? Otherwise, what we have works just fine and doesn't have any known bugs.
No reason it *must* be updated AFAIK. It works reliably here too.
Like i said in my post shadow is in the same version at least since Slackware 8.0 (which was released 8 years ago) and the specific version has been rebuilt 18 times, even for fixing minor issues.
I guess at some point it could have been updated to some more recent version instead of just rebuilding the same one, as there have been many shadow releases since 4.0.3, and i was curious if there are any reasons for not being doing that all this time.
Like PAM or something else.
After all, most of the parts of Slackware that are essential to the system's well being are updated regularly and shadow seem to be an exception.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.