I'd prefer this myself, but sometimes users want control of their own system. I know from what you said elsewhere you don't pursue this customer type. But let's say what if, a customer/friend wants a gui like what they are used to. Slackware doesn't provide distro specific gui tools, like in package managing. If it did, I probably would have more home users on slackware right now. Yes, not having the strict separation of admin and user control is bad, but that is a risk many small-time / home users take as they are used to it. Familiarity/compatibility is a strong selling point and it doesn't have to violate the slackware philosophy, nor take away admin choices in different settings. I am willing to build on slackware as it is a strong base for simplicity and user control even when it might mean I am going to spend a little more effort making it easier for everyone. At least when I get something done, it's always reusable many times over with no effort.

Could you give an example of an easy installation with dependency handling? Even better if it is slackware centric. I think the closest I can think of is sbopkg & queue files. But I'm guessing you would not want the user to compile things?

For those rare cases like for example my dad who lives 1.500 km away, I usually use Ubuntu LTS with a few tweaks.

Niki, I much admire you and your business. Yet that business model has limitations for us. The majority of your customers are multi-user environments and not single point home users.

I don't believe that model will work for most home users. To home users, that model is the equivalent of a store policy that nobody can buy a computer unless they also buy a service contract. To home users this model is vendor lock-in.

Yet I envision a corollary model that would be more palatable for home users. A fixed fee for installation and migration of data and the fee includes, for example, 2 hours of support time. Sell that approach as a package.

Another approach is to offer optional service contracts. A challenge with this approach is the provider needs to work as efficiently as possible to make a profit because service contracts tend to be fixed fee. Offering such contracts is a game of numbers with the presumption that most people will never ask for help.

Many business people more than likely expect to buy a support or service contract, perhaps even demand such a contract, but home users don't. This is the "appliance" mentality. Home users expect the computer to "just work."

I am well aware of the counter arguments against supporting "brain dead" home users. I have my own reservations about such support. At the moment those users remain a target audience we want to consider.

That would be part of our initial discussion too. Yet again, there is a difference between supporting multi-user environments and single point users.

Conversely, to play devil's advocate, I envision some people with some computer knowledge to argue with me that if a Linux based system is that complicated as to require additional support contracts, that they then have no interest, and they might as well update to Windows 7 because they then would have no migration issues or learning curve.

Despite many arguments against using Windows, XP did more or less "just work" for most people, especially at the home user level. Most home users are not tech savvy people. Generally, they brought a new computer home with Windows XP preinstalled. They pressed the power button and everything "just worked." They will expect the same thing with a Linux based system.

I am not claiming Windows is without problems and challenges. There are just as many online forums for helping Windows users as Linux forums. Yet the overall perception by most people is the computer should "just work." This attitude is becoming more prevalent with the advent of smart phones and tablets.

For me, a big concern with supporting Linux based computer systems is not the initial migration, or even conversion of user data, but peripherals. Primarily printers and scanners. Printers and scanners are not the best supported area with Linux based systems. I can't tell customers to just buy a supported printer or scanner. They will scoff and walk away.

Separating system administration and system use is viable for certain types of customers but not all. :)

I agree. Computers are complex tools. Yet as I mentioned in my previous post, there is a growing perception with the usage of smart phones and tablets --- right or wrong, that these complex tools should "just work." The tinkerer's and geek's brains are wired differently from the majority of people.

Analogies always have limitations, but that was the same basic attitude of Henry Ford: "You can have any color you want as long as you order black." Aesthetics are important to a significant number of computer users. A boot splash might seem irrelevant to you and me, but not to many other users. I much prefer having the boot process output scroll by, but am not so naive as to ignore that such output horrifies many users.

Hmm, I almost forgot..

http://www.pclinuxos.com/ is also something you might consider..

Again, I'm still pressing on about the actual use of Slackware..

On one hand, even XP is hard to install for normal day-to-day end-users and the most difficult cases in my last few years of free-lancing was exactly based upon people trying to do that the wrong way (the problem was that most of them did not know how to handle partitions or, if they throw that part, they didn't know to get proper drivers and ended up needing support after installing some weird program that searches for them automagically -- in exchange for a few malwares.. )

So, installing a modified version of Slackware and getting away with it might be a good idea.. But what happens when they start browsing and finding programs that they would like to try (most of them have precompiled .deb packages for Ubuntu or Debian.. or .rpm packages for SuSE.. on Slackware things are different)
Also, even the stuff from SBO will not be available for them...

Don't get me wrong, I love Slack.. I use it.. I would recommend it to someone that can pick up the phone if has any questions and neither of us mind (nor pay anything).. But to actual end-user customers that expect things to just work!? Nope.. Wouldn't do it..

Try to find and use the best tool for the job, Slackware just isn't in this situation, in my opinion..

The stability of Slackware was never a point of discussion. I have been using Slackware for at least a decade, probably longer. Moreso, this entire thread is not about vanilla usage. :)

In a previous post I agreed that Slackware can be used as a base. The challenge is whether I can massage Slackware into a product similar to LMDE. From my perspective I do not believe any existing Slackware derivative has the same degree of spit and polish as LMDE. The discussion never was about whether Slackware could be massaged as such, but whether any GUI tools already exist to move toward such a goal.

Correct. I have no expectations that customers are going to start compiling packages. Although I compile all of my own packages outside of the stock Slackware, as I age I am leaning more and more toward getting away from that. I just want to use the software. Similarly, customers want and expect a GUI package manager. Point, click, download, and use the app.

I have considered that distro. I haven't yet tested.

That would be my preferred choice, if I can find all the appropriate tools. Yet while a hodge-podge collection of tools likely would satisfy most Slackers, that design approach won't suffice for our customers. :)

Another concern of mine, not addressed in my original post of this thread, is wide-scale software selection. While Slackware has a decent third party repository selection --- when combining the repositories of Eric, Niki, Robbie, Salix, Absolute, etc., the number of available packages still pales compared to other distros. A quick example is another thread I started. No such packages or build scripts exist for Slackware. In this particular example, the customer is a computer savvy person who uses Linux systems. Explaining that the packages do not exist won't fly, especially when the packages do exist for the specific distro he wants to use.

I agree with your statements, but none of our costumers will be installing the operating system. We will be offering turnkey preinstalled solutions.

I agree. This ties into my reply above about repositories. In the case of SBO packages we would have to maintain our own repository.

Yes, points I offered in previous posts.

Yes, this will be a challenging project if we move forward. But there is the potential to have a lot of fun too. :)

Well, if you do decide to continue, please, if possible, share some of your work :)

I don't do home users, so I can't really tell. When a company approaches me, they usually have very clear specifications about tasks and corresponding applications. My job is simply to install an environment that meets the specs, no more no less. Eventually I do a little training for the users, and then I'm coming over from time to time to do a little maintenance. Which is way less than most of them had before on their Windows installations. So far, everybody's happy.

Technically, there is a complete suite of applications with graphical user interface for configuring Slackware.

It's called ALICE, is made up of no less than 10 applications, the installer is called YaLI and it supports three different distribution types for installation. It even has a graphical partitioner, in the style of GParted...

It was developed by DARKSTAR Linux, in collaboration with two other distributions derived from Slackware, namely easys GNU/Linux and Bluewhite64 Linux, also its development was sponsored by a German company.

As an interesting note, ALICE supported a Slackware x86_64, before the advent of Slackware64.

True, now it 's at the level of Slackware 12.2, and ALICE is written in Qt3, which is now history...

But its code is there, and ALICE/YaLI could be rewritten in Qt4 and updated to today technology.

But at the level that is ALICE, this suite of applications is too complicated to be developed as a hobby. It takes at least a programmer in C/C++, connoisseur of Qt and Slackware, to work full time for maintaining and developing it. That's why it took the collaboration of three Linux distributions for its development... :hattip:

The graphical tools are very nice, but them require a huge amount of skilled work, that make a must for someone to pay for them... ;)

Hmm. I hadn't thought about that. Intriguing idea: maintain a journal that later can be transcribed into something useful for others.

Yes, I understand that you don't support those users. :)

I agree and that same approach is useful for home users. Their list of specifications and applications usually is shorter than business users, but the bottom line is both types of users expect everything to "just work." Both types of users have budget and skill restraints. They are willing to buy solutions and products, but they expect to receive value. The definition of value varies wildly and is part of the contract discussions, even if the contract is "only" installing a Linux based system on a single system. Regardless of that definition or perception, they still expect to press the power button and everything "just works."

That is a good point. With Windows they almost always bought a product that came with no support. Some business users bought service contracts from somebody, or hired IT professionals in house, or took training classes, etc. I do not expect a Linux based system to be any different. The difference is nobody in this geographical area offers full support or training classes for Linux based systems. Thus, there is a nice opportunity here for steady business growth in providing those missing services.

That really is the end of the story, regardless of who the customer might be. :)

Interesting. Too bad the project withered away.

I think it was Slackware 10.0 around there. I took the kde package manager and hacked it some to do slackpkg update that was years ago. it was kind of fun kept me busy for a while. It really was not the that great LOL.

I think Slacko Pup has done well keeping up with the puppy package manager for the Slackware programs. It really tries hard for dependencies. Plus the way for a simple interface to the gui. While back I did a base install of slackware 14.1 then ported many of the puppy no arch scripts and the desk top from slackbuilds. it was a super light system and had a lot of fun.

I was amazed how easy it was to port the scripts to 64 bit system.

Actually, professional users usually have short and clear specifications, compared to home users. This being said, I'm also the sysadmin for nearly all my friends and neighbors, and I installed my personal blend of Slackware on their computers.