@enorbet: Re: OS/2 - No, i'm not a programmer or anything. I was taught computing at college (Fortran IV on an IBM mainframe, and FOCAL on a PDP-8). My home computing started with building a Compukit UK-101, which was an Ohio Superboard modified for European TV standards. That came with Microsoft Basic, which we all thought was great - until the BBC "B" came along with its own Basic, and the ability to swap between Basic and machine code within a program! It blew Microsoft's offering out of the water, in every way imaginable!

So when I graduated onto PCs, I really wasn't interested in anything that came out of Microsoft! I started off with OpenDOS and GEM, and stayed with that until OS/2 came along. By that time, actually programming was getting beyond my experience (I used to be quite good at 6502 machine code!), and I was really just a user. My day job was a videotape editor for a major broadcaster, which back then required a degree (or equivalent) in electronics, as the machines were so complex! (We were required to maintain them, as well as use them!)

So when IBM abandoned OS/2, I started looking around for something that didn't involve Microsoft at all, and ended up on Slackware. I've been here ever since!

:-)

--
Pete

4 members found this post helpful.

Thanks pchristy. Cool story. Mine has many similarities. I stuck with OS/2 right up until the end and even flirted with eComStation but Linux won me over. I do still have a single core 65bit box with WSeB on it though I haven't booted it in 2 years. Oddly enough there was a TeamOS2 boast of "OS/2 a better DOS than DOS, a better Windows than Windows, and a better Unix than Unix" which was a bit over-the-top but not altogether unwarranted and that's what caused me to install Enlightenment on OS/2 and that experience led me to Linux... first Mandrake and then Slackware where I'm settled for going on 20 years now.

Anyway... Salut Brother

So... I started with 9.1 (yes, I'm a noob relative to quite a few here). As someone else said, I recall printing lists of packages to upgrade and crossing them off the list as I went. I was also on dialup internet at home, so if it hadn't been for (sorta-unauthorized) use of work internet, I'd have really been in a mess. I found slapt-get around that time, and it helped a lot, but I switched over to slackpkg at some point (I don't recall exactly when - I never dreamed I'd be maintaining it one day). Anyway, linux in general is easier these days, primarily because you don't have do a whole lot of research to make sure your hardware is going to work. Literally every computer component and peripheral *had* to be researched to make sure it worked in linux - I learned that the hard way with a cheap Lexmark printer. These days, that experience is rare; I still check on stuff like USB wireless devices on the rare occasion I need them, and printers are still worth a casual look, but for the most part, whatever you buy will work. That's not Slackware-specific, of course, but it still factors in to the big picture.

Several folks have mentioned SBo, and yeah, it's been great (though I guess I'm a bit biased) :-) I wouldn't want to live without it either these days. However, I do know of one negative point surrounding it: most users do not develop the understanding of what happens when you upgrade system libraries into /usr/local, lose track of what's there and what isn't, break the system, and have to struggle through figuring out just what the hell is going on with your system. The few times I did that were, while intensely annoying, some of the best learning experiences I ever had.

6 members found this post helpful.

Robby, its a testament to you that regardless of when you started you and Eric (IMO) are as integral as PV himself.

2 members found this post helpful.

Can you say a little bit more about that? I have no idea about /usr/local but have had no problem installing and upgrading things in stable and -current.

I remember when my aunt had given me some CDs from the office, and that they had no interest in installing Warp. I used it and was hooked.
I remember at the time you could go into stores like Electronics Boutique and get "mega packs" of OS/2 software.

I still have those CDs and 3.5" disks somewhere.

1 members found this post helpful.

I'm puzzled. I've installed a few things from slackbuilds and nothing went into the /usr/local tree. The only things in there are a few programs that I wrote and built myself, which I deliberately wanted to keep separate. Under what circumstances would a system library get into /usr/local/lib?

It was before Slackbuilds and SBo that things would be put in /usr/local. Back then, it was configure - make - make install. Some people configured the build to go to /usr/local or even /usr/opt to keep 3rd party software separate and easier to remove from the system. The Slackbuild allows the use of pkgtools to manage software additions and removal, instead of rm -rf /ooops.

Easier, largely because it's easier to find an answer to questions or problems these days and because I don't run a potato for a computer anymore.. it took forever to get anything done on that old Pentium II.

@ pchristy & goumba - Out of respect for thread guidelines and the OP, I won't flirt with OT anymore than to say I bought one version of Windows and my experience with Microsoft was painful, annoying, and expensive (felt like larceny) but I bought 4 versions of OS/2 and my experience with IBM was pleasant, rewarding and I very much got my money's worth. Now that they have bought RedHat I am sometimes conflicted about wishing them well with it, but then again I recall that IBM almost totally ignored SOHO Desktop users and always focused on Enterprise. That said, even the incidental "crumbs" that fell Desktop User's way were fantastic. Since there is almost no overlap with Slackware which is quite the opposite, assuming no niche whatsoever, and since IBM has contributed deeply to Linux, overall I wish them great success, but I'm sticking with Slack.

1 members found this post helpful.

I don't put stuff in /usr/local anymore. I do put stuff in ~/.local sometimes though.

yes

Packaged software should never go into /usr/local (though I'm sure someone will manage to find an exception). Scripts from SBo build packages, and thus nothing should ever go into /usr/local from there.
Before SBo (to be pedantic, I don't think that's a completely fair statement, as there was at least one other project that focused on providing build scripts - slackbuilds-central or some such by George Georgakis, and my spelling may be wrong there), but for the most part anyway, before SBo, you either found a package from someone on e.g. linuxpackages.net (dead now) or you downloaded the source code, untarred it into /usr/local/src/, and ran ./configure; make; make install. This installed its contents to /usr/local/bin, /usr/local/man, /usr/local/share, and so on. If you later needed to remove it, you went back into /usr/local/src/whatever/, ran "make uninstall," and hope that the Makefile actually had an "uninstall" target. Worst case scenario, you found everything in /usr/local pertaining to that software and deleted it manually.

If you were lucky and didn't try to (or more likely, *need* to) run a newer version of any software that shipped with the distribution, then you likely wouldn't run into any problem. If, however, you *did* need something newer than the distro's version of e.g. some system library, trouble was likely ahead, especially if you later determined that you didn't *actually* need that newer version and so you removed it. Anything you built between those two points could potentially be a time bomb waiting to explode. Here's a contrived example: libsomething-1.0 is part of Slackware. You need appwhatever-2.3, which needs libsomething-1.1, so you build and install libsomething-1.1 into /usr/local. What you don't yet know is that libsomething-1.1 added some new function (which we'll call "do_something_new") in the library. It didn't remove any functions, so all of the already compiled code on the system is fine with that -- it's not even aware of the new function.
A week later, you realize that your custom compiled libimportant-1.8 *package* is out of date (yes, it's a package, because you deploy it to everything in your workplace network), and you dutifully compile the new 2.0 version, package it up into /usr, and upgrade it on your personal workstation to make sure all is well. What you don't yet realize is that libimportant links to libsomething, and since libsomething-1.1 is in /usr/local/lib, that's the one it links. It really likes the added "do_something_new" function because it streamlines some code there, and libimportant devs made it use that function instead of the old way if the function was available at link time.
Everything is looking good and you're thinking it's time to deploy libimportant-2.0 to everything, but you remembered that you found a different approach to the earlier problem you were trying to solve and you don't actually need appwhatever-2.3, which means you don't actually need libsomething-1.1, so you remove libsomething-1.1 from /usr/local. Suddenly, libimportant AND EVERYTHING LINKED TO IT refuses to run, with all of them complaining about a missing "do_something_new" symbol or some such. The reason, in case it's not clear, is that libimportant linked to your new libwhatever with that function, while the old libwhatever already installed on the system doesn't have that function.
Aren't you glad you didn't go ahead and upgrade all of the company workstations? More importantly, don't you think it's time to set aside a separate machine that's only used for building updates - something that you don't use for anything else so that you *know* it's not contaminated like that?

I hope you enjoyed the story - it's remarkably similar to battles that many of us used to fight quite some time ago... :-)

7 members found this post helpful.

That's an excellent explanation. The one detail I don't quite understand is why libimportant.so linked to the libsomething.so in /usr/local/lib instead of the slightly older one in /usr/lib. Wouldn't /usr/lib come earlier on the library path?

Look at /etc/ld.so.conf
The order in that file determines the search order. To override a system-supplied library (in /usr/lib[,64]) with one in /usr/local/lib[,64] the latter has to be earlier in that config, so other programs (and compilations) will be using that one first too.
Often /lib and /usr/lib aren't even in that config at all, so they will be searched last.

1 members found this post helpful.