Woodman, isn't there Debian and Ubuntu? Isn't Ubuntu derived from Debian? Why can't we keep Slackware the way it is and let different groups make their "slack-based" distros? If they want to use slackware and they don't want to learn anything from Linux, let them use a "slack-based-distro" that does not make them "frightened" showing an "ugly text-based console". I am the one who will be scared when I have to use something like "Slackubuntu" or "Slackdora"-distro. Let other groups make a slack-based distro that will play their protected DVDs out of the box.

- it will always be this same way... over and over. People want windows or anything windows-like. In my country, the stores are selling cheaper PCs, without window$, but with some poor linux distro and a windows manager configured to resemble XP, saying that these PCs come with a "generic windows". They don't want to learn, and we don't have to forget what we know in order to satisfy the dumb or lazy people. Slack is for advanced linux users who want to know where they are stepping. Not simply point-and-clicking, format/reformat.

Well, for now, I would suggest not to add grub and keep lilo. Grub is unstable and slow. Lilo is great, stable and fast, easily customisable.

- Questions is: just to "give an air of professionalism" ?

- Now I agree with you, totally. KDE 4.3.4 is better than 4.2.4... and the network driver is really broken in k 2.6.29.x.

I think the other suggestions are being discussed elsewhere in this forum.

----------------------

"DON'T MESS WITH SLACK"

Speaking of spkg and mpkg, Sasha pointed out the 'beautiful' installer used by MOPSlinux. Their 'mpkg' is a fork of spkg, with the addition of a QT-based GUI and an ncurses-based TUI. It also has other enhancements for creating packages etc.

I was glad to see that lufbery pointed out the we do already have a GUI installer -well TUI, but still it ain't command-line. The fact is, you could alias dialog to Xdialog, have X running and use the exact same installation routines we have and then it would be a GUI installer -but somehow just the idea of that is so evil...

As for the pros/cons of 'offshoot' distros based on Slackware or other distros, I don't recall hearing die-hard debianites call ubuntu a 'parasite'. Point of fact is that lots of ubuntu stuff filters its' way back into debian -but only because debian never turns down a real fix -no matter who it comes from.

I shared the problem here at LQ. Browse the web for confirmation.

I used wolvix as a path to slackware and it is a great allround desktop system that I recommend to my MS friends that consider linux. It certainly follows the slackware ideal "Ït just works". However what I love about slackware IS the graphical ncurses installation, IS the slackpkg packaging system that allows me to install ONLY what I choose, and delete ONLY the pkg I choose. What other system allows you to slackpkg clean you system back to your original standard installation (If I still used windows I would be using this once a month). Now that I am a little more knowledgeable, I love the power of the terminal, that gives me a sensable message when I have stuffed up. However as much as I love slackware, I recommend it only to friends that are prepared learn by them selves. I also have LXDE-ubuntu installed simply to try new applications, and offer to interested newbies. I am a relative newbie to slackware, yet I would not like to see any default graphical changes. Graphics hides important messages from the system, and us less knowledgeable need all the clues we can get.

dupe post

1 members found this post helpful.

another dupe post. scroll down.

Such tools are already available at least through KDE. Why dont Slackware people (read: users) who want GUI tools help KDE development providing patches that make em work on Slackware?

For example like this one?: http://slackpackpkgman.wordpress.com
AFAIK there are other graphical frontends too. The Slackware team doesnt feel the need for one and IF the community did there would be at least one developed, maintained and used for years now. I guess the only example that comes to mind and is worth mentioning would be gslapt...

Agreed

I would like that too but only if/when GRUB gets out of alpha status.

I dont agree with this. Creating illusions is not a valid excuse for anything, ever.
Its insincere and unethical.
edit3: The above goes to the illusion part. I dont mind as a feature but doing it just for being there is pointless. Either do it properly, or dont do it at all.

Sorry to dissapoint you but kpackage has been declared as unmaintained by KDE.
edit2: heres a link: http://comments.gmane.org/gmane.comp...vel.core/62682
Regarding knetworkmanager (and wicd) i am guessing there will be some changes when KDE 4.4 gets released which will have some parts of knetworkmanager intergrated.
edit: BTW when you say "This requires working with the upstream KDE developers" you mean Pat and Alien BOB but not you and me?
It seems that you expect everything from Pat when Pat expects everything from upstream.
And this obviously cant work.
If you and anyone else feel the same way i suggest you get involved with upstream projects.

This is silly. Why only K3B? What makes it so special?
Q:Why not do the same for every package in Slackware?
A: Because its not worth it and it doesnt make sense anyway.

2 members found this post helpful.

For those interested, WRT the forcedeth driver:

I remember when the 'hibernate..' bug showed up. It was indeed caused by one of the items/links mentioned in Woodsmans other thread there; the PHY was shut off, and didn't shut back on after resuming.

That bug was addressed in relatively short order, several kernel updates later, and a new module option was added to the forcedeth driver, which you can implement using your /etc/modprobe.d/... configuration files, like so:

Using the bold option above, and the forcedeth NIC will not shut off indefinitely.

As for NAPI with forcedeth, it's been labeled EXPERIMENTAL for like forever, so if it doesn't work, file a bug report if one like yours has not been filed, or avoid using NAPI.

FWIW, NAPI has been working fine for me ever since I started using it, and the forcedeth driver itself as a whole, has worked just great for me for as long as I have been using it (a couple years now), so it's definitely not "just broken". I just built & installed kernel 2.6.32.2 the other day, and it still works.


Sasha

1 members found this post helpful.

What country is that?

I haven't been able to find anyone selling a machine with linux on it at a discount, not that I'd buy one, except for maybe a laptop, just because I like to build my own.

I'll try that with the 2.6.29.x kernel. I never could get the network driver to shutdown correctly. Some days I do a lot of testing that requires rebooting and the latching was frustrating. I had no problems with the 2.6.28.x or 2.6.30.x kernels, only 2.6.29.x --- every release in the series.

Regardless, I think one of these days Current should move to at least 2.6.30.x . . .

YEP, IIRC it was somewhere in 2.6.29.x where this "bug" was introduced, and IIRC is was fixed by 2.6.30.1 or so, and the module option was added..

Cheers!
Sasha

Thank you, Woodsman, for all of your suggestions!

I have not used Salix, so I cannot speak for what their tools are. "Graphical administration tools" is a rather general statement. If we are to attempt to integrate some GUI admin tools into Slackware I think it needs to be clearly defined as to what is really needed and what is not. In general I would say that Slackware should avoid adding too many of its own suite of GUI admin tools. I like the fact that I can apply the majority of my Slackware knowledge to other distros because I do things "by hand" versus learning Fedora Core's GUIs, etc.

Granted, a good GUI shouldn't be hard to learn whatsoever. Unfortunately, I find that particularly new GUIs tend to have bugs, so I end up having to fix/do some things by hand regardless. For Slackware's purpose, I think that those Slackware users interested in GUI admin tools should make more requests (or provide code) to upstream DE developers to include/fix Slackware compatible (stable) GUI tools. Beyond that, if people really think xdialog is easier to use than dialog, then making pkgtools compatible for both does not seem to be a huge stretch.

I'd say include it as long as it is OFF by default and as long as adding this as an option doesn't complicate anything too much. If it would need significant tweaking every Slackware version then development time would be better spent elsewhere. People can just turn their monitor off or look at a wall for a minute if they hate the text boot up. Twiddling thumbs is about as useful as a bootsplash.

This is similar to #1. As mentioned previously, I think this should be focused upstream if possible. Slackware package management is so darn simple that I don't see a significant benefit to development time cost ratio that justifies a home brewed GUI package manager. If a custom Slackware setup (distro like Salix) can consistently prove over time that its GUI package manager is stable, KISS, and useful, then it might one day make it way to official Slackware as other tools have.

This is slowly happening. Perhaps having more of Robby's packages in /extra might help

AGREED

Agreed as long as lilo remains the default. Some people say grub still isn't stable, but I've seen it used successfully in large scale production environments with very little or no issues. I think more people probably run into the "ooops I forgot to rerun lilo" issue than any grub bugs.

But why not wait for KDE 4.6.x!? Surely it will be even better! Making people wait, however, might be a good strategy to get more Slackware testers on -current...hmmm...

I'm confident Pat won't release a Slackware version that is unstable.

Sounds like a plan to me...

Same as the bootsplash discussion above...

AGREED

GOOD IDEA! Maybe other firewall script building sources should be mentioned as well...

AGREED. WHY NOT DO THIS? Still leave 3 as the default....

AGREED! Having no color in the boot scripts might bore people so much they consider putting a bootsplash in instead! As long as it is off by default it should not negatively affect function or stability. Done correctly, it should not complicate the scripts either.

I do this for my own scripts and would offer to provide patches, but many of my scripts are already thoroughly customized for other reasons. It is a pain to integrate the new changes with each Slackware version, but I like the coloring. Sometimes I think I turn on my computer just to look at it...

Sounds like a plan to me...

Sounds like a plan to me... Although, I think wicd has overtaken Knetworkmanager at this point.

This certainly would be a plus for desktop users! It might be a pain to maintain, though. Should there be alternative (differently compliled) versions of K3b, etc as well?

Along those same lines, a lot of end users might appreciate OpenOffice being easily accessible via the same tool. I know it is easy to get via sbopkg, but if the tool can grab codecs, why not OpenOffice? This would save the Slackware servers from hosting OOo, but OOo could practically still be included in the distro as a lot of users would expect.

Would it be as stable if people did not add the extra packages?

AGREED

I'd also like to add that significant discussion has danced around the idea of needing up to date centralized documentation and extra packages. LQ is probably the best starting place after Slackware.com, so OneBuck's Slackware Links is a step in the right direction. Maybe if Salix or a similar project gains enough credibility then that could become a main source for the extra packages.

My recommendation for Salix and other projects with similar goals to benefit Slackware is to maintain the project in such a way that I could slap on a Salix pack (group of packages) on top of vanilla Slackware and be able to run a partial or full Salix with the same stability I'd expect from Slackware. The project should maintain a tool/script to do this if necessary. That same tool should allow me to easily undue the changes, including reinstalling any stock Slackware packages that were replaced. The project could still provide the completed iso as well. The point is to show that it is easy to extend Slackware, rather than replace it with a derivative.

If Salix and other similar projects can consistently show that certain added functionality fits well with Slackware, then maybe it might one day be included. Some software I see on SBo makes its way to Slackware...If it doesn't get included then maybe at least OneBuck can link to it

Oh, and replace mplayerplug-in with gecko-mediaplayer...

sorry if I stress this point but can be interesting: looking at slackbook site, the book itself is released as GPLv2, this can implicate a lot of things

Brazil...