It's funny but this brings me back to the good old days of mainframes. I go back to the days of Autocoder and SPS and board wiring the computers. Then we got to assembler on the bigger mainframes.

A few years later and they came out with COBOL and RPG and other languages that were further divorced from the nuts and bolts of the computer. I started consulting about that time. What I found with the mainframes (and I think this is transferable to PC's as well) is that the further you get from the basics, the harder it is to solve problems. I know that since I knew exactly how to interpret core dumps on mainframes, when I had to fix a problem I could very easily see exactly what was where and how it got there. That made it easy for me to fix. I still remember a friend who was a newbie who got a data exception (bad input) when he ran a program. I stopped by and he was reading a 10K line file line by line to see where the error was and had been doing so for a couple of hours. I looked at his core dump and told him where the problem was and also how to fix it. My time - 10 minutes.

The same holds true with PC's, I think. If all you can do is apply things done for you by others (the situation I find myself in when it comes to PC's), then when you get a problem that is a little sticky you will be totally lost. That is where distros like Slackware and Gentoo come in handy. If you use them and have paid any kind of attention at all, then you will be able to quickly analyze the problem and fix it no matter what distro you are working with. The others will be lost and crying for help.

Sure it is nice when the distro does it all for you, but then you had better hope there is no problem that is not catered for by the distro or you will be haunting the forums crying for help. I just wish I knew the best way to get that knowledge for myself. The way the system is set up on PC's is so different from mainframes that I need to relearn it all. Since I am now retired, I just hope I can find the right place to get the info so that I can learn it.

actually it's quite to the contrary. the higher-level language are less error prone.
as to your friend, a debugger would have helped him a lot

It is not that they are less error-prone. It is that when there is an error it is harder to see exactly what the error was - plus all the overhead of the debugger and the bloat of the programs generated by the higher level languages.

I once had to work with some programs that were created by a high level language into COBOL. It was a simple report program. The language generated 11 pages of coding to do a simple report. That means that the program had to work its way through all those extra instructions to do a simple move, add and print.

BTW higher level languages are only as good as the person who developed them. The same with the operating systems. Given that the basic kernel is essentially the same and a lot of the packages are also the same for various distros, why else is there such a vast difference in the performance of the distros. Compare Slackware or Gentoo to Ubuntu for example.

Good point. In my experience with distros I notice that the biggest differences are in the desktop and window managers. When you get down to the commandline the differences are smaller - package management, sudo usage, some locations...

Good point, also. I've been using Slackware for several years. With my technical background I feel right at home on the commandline. I recently got my dad on Ubuntu, and I've played with it in a VM, and I would say it's right for someone who is moving away from Windows but wants things to be Windows-like. You're right, they do still need help in the sticky situations because the automation and reduced need for the commandline has reduced the learning curve. On the other hand, though, Ubuntu has made it possible, and appealing, for many people to at least try Linux. When they're comfortable with Ubuntu they can choose to move to another distro. The world of Linux is full of choices. After using Slackware, Ubuntu and SLED10, my choice is still Slackware.

rhomp2002: you know, some people find it offensive to speak of COBOL in public...

Sorry but I made a damned good living from COBOL from 1964 when it started until I retired in 2003. I know it is supposed be beyond the pale in polite society these days to mention it but it is still in wide use (see how IBM is still making a big profit on mainframes these days - and that ain't C++ being used there). I still have to laugh, though, about a comment from a salesperson from Unisys back in the days before Unisys had a decent COBOL compiler who claimed that COBOL was invented so that non-programmers could call themselves programmers (you know the old saying - 6 months ago I couldn't even spell programmer; now I are one).

I think the reason why Slackware is so popular is that people know its been around since the beginning, that it's closer to the kernel than the rest, that's it's bit of a tougher learning curve, but when you get past that you feel as if you've got much more control over your hardware.

It has a resilience about it that is kinda like a drug... gives you that "you can do anything" feeling!

Moreover, for me it's about the only place left that feels "real" to me... everything else and everyone else have been "turning Japanese" on me but that's a different story.

Cheers,

- Perry

Hi,

Well if it works then use it. I haven't used COBOL since the old days, late sixties and early seventies. Yes, I too use to program unit records with wired plug boards. Even used 360/20 for a while and too hell with those damn punch cards/readers. The 1103 was OK but really didn't care that much for it. I moved over to DEC 11s minis but the birth of the micro-processor really changed that arena.

Sure, COBOL is still used throughout the industry by hospitals, financial and anything with heavy record use. Yes, IBM mainframe is still viable but the micro-farms are changing that too.

Heck, I still feel BAL is still a good way too program. Assembly has always been a fun way too program for me. Sure C/C++ can be fun but it can also be restrictive compared to assembly. If your tool kit is large enough then you can do just about anything with asm. But that is true for any programmer that keeps a valid tool kit.

This Is one awesome thread in time. This shows what get the slack back is all about.
I use Slackware because I can slack away with ease.
This thread is truly a part of the computation world and should be put in a special Slackware archive for people that want to learn.
For people that need to understand slack, to feel the slack coming back.
Life is good in slackville

Hi,

Yes, sometimes resurrection(s) can be good. Reread the posts.
Slackware is a great tool and useful to someone who really wants to have true control of what they want to do.

I like to be able to accomplish my task(s) without to much getting in the way. Been that way for most of my professional days. Early on I had to reform my way of doing things by fully defining how to accomplish the required task(s). Breaking things down to the simplest terms then perform from there. Sure, more work but worth it if the task(s) are to be accomplished and fully functional.

Hello!
There is any news of that topic?
not in style, as in almost all that answers "i and my buddy using slackware", but really large companies \ products based on slack?
Today i have that question from my colleague - i frequently advice it switch to slackware, because on that, "all works great", and today he say - he hear about redhat and debian - these are frequent found in some business based products, but he not heard something like on slackware.
i too.
maybe anyone know...?

1 members found this post helpful.

I've been approached recently by a big french company selling voice-over-IP solutions. They're 100 % Slackware on their servers.

http://www.thinkrosystem.com/

My own modest company uses about 99 % Slackware and about 1 % RHEL.

http://www.microlinux.fr/

2 members found this post helpful.

Greetings
While this thread has drifted away from OP, which was a query into how popular Slackware is, especially in larger, public environments, I still have an interest in that answer (even though the "Memory Lane" posts are fascinating). It seems to me it is a vector analysis of trends that affects all of us who use Slack.

The power of Slack is also it's weakness (at least as far as "market share", IMHO. I LOVE Slackware because it does exactly what I tell it to do and not a stitch more. This ties in w/ Mr Mainframe Cobol's assessment of debugging. If things are kept simple and direct, and you are responsible for EVERYTHING that occurs, then it is easy to locate any problem. It is only when we allow the system to install, remove, setup, etc etc things for us that we never even see, that it becomes a chore to narrow down to the essence of the problem.

This, of course, requires that an Admin/Sysop, actually knows the system deeply and also is not pressured by those who don't know but have decision power and assume that saving time on the upside is a fair tradeoff for losing time on the downside. To be clear, automatics (as in dependency resolving package managers) are really fast.. during installation! - and often I grouse at a string of inherited dependencies I have to wade through to get some simple libraries loaded or an app working, BUT IT IS WORTH IT.... to me. However the general PC/Code ignorant public and business bean-counters don't think like that... or at least it surely seems that way.

So I would like to know how many mission-critical systems use Slackware, if nothing more than to feel out the trends of where Operating Systems and Admins are headed. It feels like (by analogy) that we now have many race car drivers who couldn't tell a piston from a universal joint. I'd love to know I'm wrong.