What's the meaning of sr?

From what I know, is a way to define a device that a SCSI /dev/sgX is refering to. When a /dev/sgX is refering to an optical drive (read cdrom, dvdrom, cdrw, dvdrw) it's mapped to a /dev/srX.

At least, that's the info I know from the manpage of sg_map. If there's other meaning, I will like to know too ^^




Regards

Default kernel in Slackware 12.0 still uses this scheme
but that depends on the kernel 2.6.19 and above config.(CMIIW)
IMHO default slackware still uses this scheme maybe because this is the old and stable option hence trusted way for now as we all know slackware always try to be as stable, less buggy as possible.

Hmmmm...this is related to this thread

Like gnashley said, kernel 2.6.x config can be different

I would like to see mplayer to be included in slackware as opposed to xine

Java is free, now. And as far as I can tell, all stuff included with Slackware can be used commercially, so from a user's point of view there shouldn't be any real restrictions. All the resentments I know of are more philosophical in nature.

gargamel

I really don't share your opinion. I don't want to see Eclipse or Maven included with Slackware, because they are moving targets. Once they are out, they are outdated. And: What choice of plug-ins would you include with Eclipse? No single Eclipse distribution, original or 3rd party, has ever enabled me to start working without having to invest hours of searching the right plug-ins.

Netbeans is productive out of the box, but I don't want to see it as standard in Slackware, either, although it is the Java IDE of choice for me.

The point regarding Java applications, IMHO, is: They can be easily installed and removed and maintained without having Slackware packages of them.

Note, that I appreciate having a current JDK in Slackware! When Pat V. announced that the JDK would be dropped from the distribution, I tried my best to convince him to keep it in. And I am very glad that he really listened, and that Slackware is now the best Java platform available. Why?

Because the Java "infrastructure" is up-to-date and integrated well with the system. Installing Java applications is easier on Slackware than on every other system I know of.

Compare this with other distributions, like (Open)SuSE (which I do like, otherwise, pretty much): There are so many Java packages included with the distributions, but when you install them they are already outdated, or the plug-in you need is just not there. And, BTW, I usually do like the way SuSE uses RPM package management in YaST, the dependencies of their Java packages clearly show the limits of that approach: It's simply a nightmare to update a package like Tomcat.

And regarding the Apache Jakarta project: IMHO, it's a mess. The software "products" are usually quite good, but the developers are arrogant, and the community is definitely not as helpful as the LQ Slackware community. Therefore I prefer Jetty as my web container.

So I use Netbeans and Jetty, while you prefer Eclipse and Tomcat. Others use Websphere or Weblogic with IntelliJ, etc. Therefore the use of including these tools with the distribution is limited.

What we share, is the need for an up-to-date Java infrastructure, which is already part of our favourite distribution. I vote for keeping it exactly like it is!

gargamel

Now, what fetureas/changes would I like to see in future Slackware versions?

My priority 1: Include src2pkg. As some others said, this little tool is a jewel, that fits perfectly well into the Slackware philosophy, and adds a lot of comfort. It complements the Slackware tools in the most elegant way.
With src2pkg added, my list of software I would like to see as part of the distribution by standard becomes short, as package creation and installation from source becomes so easy with it:

- Kile
- T-GIF
- some better X config tool
- OpenOffice.org


But here's a point I'd like to see a solution in future versions of Slackware: OOo has an automatic updating mechanism, like Mozilla Firefox, Thunderbird, Seamonkey and an increasing number of other applications. The auto-update functionality only works well, if the directory hierarchy and the locations of the files installed are exactly where the original vendor expects them to be, and when the application has write access to these places. Which is usually not the case.

That raises the question, how to deal with such packages. Eg, the auto-updater of Firefox is non-functional on Slackware. Wouldn't it be better switched off, then, by default, in Slackware? The answer is, of course, no, as this would also de-activate the plug-in finder/installer, too (at least, that's my understanding).

To be honest, I have really no good idea what could be done, here. I just see an increasing need for having a more or less sophisticated solution approach here, as the number of packages available, and included in Slackware as standard, is continuosly growing. Probably, this is an issue for Linux in general, not only for Slackware, but other major distros already found their own ways to solve this. Eg, SuSE/Novell have their own OOo distribution as part of their Linux distribution. This is certainly not the recommended way for Slackware, but a solution of some kind is needed, I think.

gargamel

gargamel

To answer the question at the top of this page -'sr' means 'scsi ROM'.

Thanks (it's more logical, when device name has some sense).

src2pkg is just another fashion tool like checkinstall was in the past.
Softwares that automagically install others softwares are hell.

Hi,
Have you even used src2pkg?

Huh?
src2pkg is a well-designed utility, gnashley has done a great job. src2pkg functions very well.
I don't agree with you.

ciol, don't misunderstand -src2pkg is not a package management tool like swaret or slackpkg. It does not install anything. It simply creates packages from source code or other content. It does not do any sort of dependency resolution, although it does try to help you figure what may be missing if the sources fail to compile and it can produce a list of the packages that the just-made package depends on. chekinstall was/is pretty much the same, excpet that checkinstall does install the just-made package by deafult -this was one of the things that I didn't like about it and from the first made src2pkg to *not* install the package by default.
checkinstall was no 'fashion' item either -it was and still is used by many, many people on many different systems.
src2pkg is meant to fill a gap between official SlackBuilds (and those from SlackBuilds.org) for people who want or need to compile other software for their system but don't have the skills to write a build script or don't wish to spend so much time writing and debugging a script for a build. At the start it was a script-only API for building packages, but has since grown so powerful (and 'smart') that it can build most source-code into a package with a single, short command-line -about 80% of the time without any extra options at all. And, even though it does many things automatically, it still tries to 'tutor' the user as it goes, so that they may learn a little more about resloving problems that crop up with some sources. For instance, do you know what to do if you open the sources and there is no configure script in there, but there is a configure.ac and a Makefile.in? src2pkg knows -if there is an autogen.sh there then run that first, or if there is no autogen.sh then run the command 'autoreconf -if'. either way, you should then have a configure script which can be run. Do you know how to use cmake -non-interactively? src2pkg does. Do you know that when you patch *.am, *.ac or *.in files that you should run the above autoreconf command to regenerate the config files? Otherwise the changes won't take effect. Do you know that if you patch the configure script itself, that you shouldbnot run autoreconf? Do you know what to do when the sources contain a GNUmakefile.am and a Makefile? You have to rename or get rid of the Makefile, because when you run configure it's going to generate a GNUmakefile, but when you run 'make' it's gonna use the Makefile and not the GNUmakefile you just created with 'configure'. Do you know what perms should be given to the directories /var or /var/tmp which are in that package you just made? Do you know how to configure sources which use Imake, JAM or Scons? Do you know how to build and install python modules?
These are just a few of the 'fashionable' things that src2pkg knows how to do *without any help* from the user. I won't mention the other hundred things that it can do to make your life easier.
Don't get me wrong, I know there are slackers out there who are completely against such 'automatic' things(though no-one has come out plainly against src2pkg before), but I notice that even those types have no problem whatever with the few things which slackware does for you automatically. Anyway, my hope is that src2pkg helps both novices and veterans to get on with using slackware the way they want. I've been working on it for nearly four years and it has turned into a truly unique tool which is not available in any other distro -yet. Before coming down on other peoples work you should at least inform yourself about what the tool does, or doesn't do. Oh, I just noticed -that was your 8th post! Maybe I should have been nicer since you are newcomer to the forum -we do try very hard to be helpful here on the LQ Slackware forum -slackers have a reputation for 'fixing' things when others can't and this is the place where new slackers learn to be fixers instead of breakers.

Amen to that

Gnasley that was an informative post i might checkout your tool.
But i'm an script person myself. (slackbuilds.org)
But i really liked the explanation of how to do things.
I think many people can learn from that post.
If it's included in slackware or not is up to Pat.
And if you don't like the tool then don't use it.