LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 12-30-2009, 02:55 PM   #901
gauchao
Member
 
Registered: Dec 2009
Distribution: SLACKWARE 14.1 64bit
Posts: 169

Rep: Reputation: 30

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.

Quote:
Most non-technical people would respond "WTF" and demand I reinstall Windows.
- 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.

Quote:
Add a graphical background image to the installation scripts to provide the illusion of a graphical installation. The Zenwalk folks have done this. Simple polish and an air of professionalism.
- Questions is: just to "give an air of professionalism" ?

Quote:
Don't release 13.1 until after KDE 4.4.x and any kernel superceding 2.6.29.x. Reports indicate that KDE 4.3.4 is much better than 4.2.4, but is not yet as feature laden as 3.5.10. The forcedeth network driver in the 2.6.29.x kernel series is broken.
- 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"

Last edited by gauchao; 12-30-2009 at 02:59 PM. Reason: typo
 
Old 12-30-2009, 03:19 PM   #902
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,776

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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.
 
Old 12-30-2009, 04:20 PM   #903
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
Also, in what sense is the forcedeth driver broken? I don't think it just doesn't work, because I'm almost certain that I use it on my other machine with Slack's 2.6.29.6 kernel and haven't had any problems.
I shared the problem here at LQ. Browse the web for confirmation.
 
Old 12-30-2009, 04:43 PM   #904
vigi
Member
 
Registered: May 2009
Location: australia
Distribution: slackware
Posts: 177

Rep: Reputation: 27
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.
 
Old 12-30-2009, 04:54 PM   #905
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
dupe post

Last edited by sahko; 12-31-2009 at 05:12 AM.
 
1 members found this post helpful.
Old 12-30-2009, 04:55 PM   #906
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
another dupe post. scroll down.

Last edited by sahko; 12-31-2009 at 05:16 AM.
 
Old 12-30-2009, 05:03 PM   #907
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
Quote:
Originally Posted by Woodsman View Post
1. Graphical administration tools for non-technical users.
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?

Quote:
3. A graphical package manager for non-technical users. A GTK and QT version are needed to compliment both Xfce and KDE.
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...

Quote:
5. Release the Slackbook into the community for continual, real-time maintenance.
Agreed

Quote:
6. Move grub from /extra to trunk and update the installation scripts to support both boot loaders.
I would like that too but only if/when GRUB gets out of alpha status.

Quote:
9. Add a graphical background image to the installation scripts to provide the illusion of a graphical installation. The Zenwalk folks have done this. Simple polish and an air of professionalism.
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.

Quote:
15. Get KPackage and KNetworkManager fixed to function properly with Slackware. This requires working with the upstream KDE developers but these repairs are long overdue.
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.

Quote:
17. Precompile K3B to take advantage of all multimedia support although those packages are not installed in the stock Slackware. That way, when people do install those packages, K3B automatically can take advantage of that environment.
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.

Last edited by sahko; 12-31-2009 at 05:22 AM.
 
2 members found this post helpful.
Old 12-30-2009, 09:26 PM   #908
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Quote:
Originally Posted by Woodsman View Post
I shared the problem here at LQ. Browse the web for confirmation.
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:

Code:
# /etc/modprobe.d/network.conf
blah
blah
alias eth0 forcedeth
options forcedeth optimization_mode=2 msi=1 dma_64bit=1 phy_power_down=0
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

Last edited by GrapefruiTgirl; 12-30-2009 at 09:27 PM.
 
1 members found this post helpful.
Old 12-30-2009, 10:00 PM   #909
damgar
Senior Member
 
Registered: Sep 2009
Location: dallas, tx
Distribution: Slackware - current multilib/gsb Arch
Posts: 1,949
Blog Entries: 8

Rep: Reputation: 201Reputation: 201Reputation: 201
Quote:
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".
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.
 
Old 12-30-2009, 11:36 PM   #910
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
Using the bold option above, and the forcedeth NIC will not shut off indefinitely.
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 . . .
 
Old 12-30-2009, 11:39 PM   #911
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Quote:
Originally Posted by Woodsman View Post
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
 
Old 12-31-2009, 12:25 AM   #912
shadowsnipes
Senior Member
 
Registered: Sep 2005
Distribution: Slackware
Posts: 1,442

Original Poster
Rep: Reputation: 70
Thank you, Woodsman, for all of your suggestions!

Quote:
Originally Posted by Woodsman View Post
1. Graphical administration tools for non-technical users. The Salix developers are on the right track with this area. If the Salix developers and Pat are open to the idea, perhaps those tools can be slipstreamed back into Slackware trunk or /extra.
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.

Quote:
Originally Posted by Woodsman View Post
2. A boot splash for non-technical users.
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.

Quote:
Originally Posted by Woodsman View Post
3. A graphical package manager for non-technical users. A GTK and QT version are needed to compliment both Xfce and KDE.
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.

Quote:
Originally Posted by Woodsman View Post
4. I'm not a GTK fan, but additional GTK apps that provide a more robust Xfce desktop. Xfce is one of the default desktop environments in Slackware.
This is slowly happening. Perhaps having more of Robby's packages in /extra might help

Quote:
Originally Posted by Woodsman View Post
5. Release the Slackbook into the community for continual, real-time maintenance. The copyright can remain with Pat, but the Slackbook needs a community approach much like the BSD documentation. As the copyright remains with Pat, certainly then there should be an editor or three who reviews submissions and revisions, and to maintain style and structure. The LQ forum community people can all provide reviews of submissions to ensure technical correctness before merging them into the Slackbook. There is no reason whatsoever that the Slackbook is not maintained in real-time. Time to end the "good ol' boys" monopoly toward the Slackbook.
AGREED

Quote:
Originally Posted by Woodsman View Post
6. Move grub from /extra to trunk and update the installation scripts to support both boot loaders.
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.

Quote:
Originally Posted by Woodsman View Post
7. Don't release 13.1 until after KDE 4.4.x and any kernel superceding 2.6.29.x. Reports indicate that KDE 4.3.4 is much better than 4.2.4, but is not yet as feature laden as 3.5.10. The forcedeth network driver in the 2.6.29.x kernel series is broken.
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.

Quote:
Originally Posted by Woodsman View Post
8. Move the QT graphical partition manager from /extra to trunk and include the tool as a partition option in the installation scripts.
Sounds like a plan to me...

Quote:
Originally Posted by Woodsman View Post
9. Add a graphical background image to the installation scripts to provide the illusion of a graphical installation. The Zenwalk folks have done this. Simple polish and an air of professionalism.
Same as the bootsplash discussion above...

Quote:
Originally Posted by Woodsman View Post
10. Add the empty shell scripts needed to support the bash startup scripts. Nothing needs to be in these scripts other than a note how to use them. Let the users customize these scripts but include the container scripts. These empty container scripts also should be included in /etc/skel.
AGREED

Quote:
Originally Posted by Woodsman View Post
11. Add an empty /etc/rc.d/rc.firewall script container, with an internal note/link to Eric's firewall builder web page.
GOOD IDEA! Maybe other firewall script building sources should be mentioned as well...

Quote:
Originally Posted by Woodsman View Post
12. When auto-configuring the boot loader, the installation scripts should add two boot options: one for run level 3 and one for run level 4. The installation scripts should ask the user which one will be the default. Pkgtool/Setup can provide a simple script to toggle the default setting.
AGREED. WHY NOT DO THIS? Still leave 3 as the default....

Quote:
Originally Posted by Woodsman View Post
13. Colorized rc.d scripts, with the obvious option of enabling or disabling the color. The installation scripts should ask the user for the default setting. Pkgtool/Setup can provide a simple script to toggle the setting.
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...

Quote:
Originally Posted by Woodsman View Post
14. Merge into pkgtool the ncurses keyboard localization tool found in the installation scripts.
Sounds like a plan to me...

Quote:
Originally Posted by Woodsman View Post
15. Get KPackage and KNetworkManager fixed to function properly with Slackware. This requires working with the upstream KDE developers but these repairs are long overdue.
Sounds like a plan to me... Although, I think wicd has overtaken Knetworkmanager at this point.

Quote:
Originally Posted by Woodsman View Post
16. Provide better multimedia support. I appreciate the stupid political debate about adding codecs and libdvdcss. Those packages need not be installed. Yet I think the Salix developers might be on the right track. Provide a simple tool that can download the packages after installation. That way Pat and the Slackware developers remain uninvolved in any decision the end-user makes about those packages. Obviously the location of those packages must be located at a third party location, but the basic tool to download those packages could be included in /extra.
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.

Quote:
Originally Posted by Woodsman View Post
17. Precompile K3B to take advantage of all multimedia support although those packages are not installed in the stock Slackware. That way, when people do install those packages, K3B automatically can take advantage of that environment.
Would it be as stable if people did not add the extra packages?

Quote:
Originally Posted by Woodsman View Post
Hopefully everybody participating in this discussion appreciates the effort, time, and knowledge required to create and maintain a stable computer operating system. Thanks much to Pat the development team. With that in mind, as always, I am willing to help test these tools and features if they are added.
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
 
Old 12-31-2009, 12:30 AM   #913
shadowsnipes
Senior Member
 
Registered: Sep 2005
Distribution: Slackware
Posts: 1,442

Original Poster
Rep: Reputation: 70
Oh, and replace mplayerplug-in with gecko-mediaplayer...
 
Old 12-31-2009, 03:01 AM   #914
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,504

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
Quote:
Originally Posted by Woodsman View Post
Release the Slackbook into the community for continual, real-time maintenance. The copyright can remain with Pat, but the Slackbook needs a community approach much like the BSD documentation. As the copyright remains with Pat, certainly then there should be an editor or three who reviews submissions and revisions, and to maintain style and structure. The LQ forum community people can all provide reviews of submissions to ensure technical correctness before merging them into the Slackbook. There is no reason whatsoever that the Slackbook is not maintained in real-time. Time to end the "good ol' boys" monopoly toward the Slackbook.
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

Last edited by ponce; 12-31-2009 at 04:14 AM.
 
Old 12-31-2009, 04:09 AM   #915
gauchao
Member
 
Registered: Dec 2009
Distribution: SLACKWARE 14.1 64bit
Posts: 169

Rep: Reputation: 30
Quote:
What country is that?
Brazil...
 
  


Reply

Tags
cd, live


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware future? coyctecm Slackware 12 02-01-2006 11:03 PM
Future of Slackware kratunko Slackware 30 08-12-2005 01:31 PM
Slackware features? rusty_slacker Slackware 49 12-02-2004 05:45 AM
what are the features of the new slackware 9? ethanchic Slackware 2 09-27-2002 07:15 PM


All times are GMT -5. The time now is 12:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration