it sounds to me like if woodsman were a developer, then it would be taken care of. or if another developer had a requirement like this it would be done. hell, if i knew enough about it i would do it, but i am not a programmer. i do good to use the crap, let alone try to write it. what i really like to do is help people out, this is what i have decided to do with my company. of course it's not free, though. but really, how hard could it be? of course, i am comparing it to what i was used to using visual basic in windows to do the hard work for me.

what type of things are you looking for in the gui that exist only in terminal now? i have a buddy who likes to play with problems i present to him sometimes, i may actually be able to help us all out if this can get done. it's not like everyone would have to use it, but it would be nice to have a choice. i do see the point of not doing the work for free; if it didn't benefit me in some way also i don't think i would do it.

thanx for the advice.

I participate in the Trinity Desktop project. If I could hack C++ I would have been able to resolve several hundred bug reports, most of which I filed. I keep trying to learn C++ but a project as complex as a desktop environment adds additional layers of complexity to code.

Likewise with Python. I have long wanted to learn Python but never find the time. Seems a lot of desktop tools nowadays are written in Python but again, learning how all the dots connect in a complex project adds more challenges.

So I live with the bugs.

As a technical writer for many years, I have an eye for usability. I can see both the forest and trees. I have struggled getting fellow geeks to see and appreciate both sides of the usability picture.

Desktops were designed for computing professionals for use by other computing professionals - that gave us the usable GUI combined with the command line shell for system administration - in short the best of both worlds.

Nowadays the trend is towards hiding everything remotely associated with the command line to avoid "scaring off" new people and presenting a GUI which is designed for average joe rather than a computing professional/hobbyist/geek/whatever.

The new modus operandi is simply "be like a proprietary OS to attract new people". This means that the philosophy where new users learn how to use and be in control of their system is flushed down the toilet and replaced with the more familiar proprietary ideology of "idiot proofing" and designing UIs with as few options and choices as possible to avoid "confusion" - big brightly coloured buttons - no text, no "clutter", hide as much as possible, binary configs - which of course lend themselves perfectly to GUI config tools - next stop: regedit...

Apparently the proprietary OS were in fact doing it right all these years and the failure of FOSS operating systems was in not being like them...

Perhaps in the early years. After desktops became popular among the masses, the design had to accomodate the less than savvy users. At least in the proprietary world. Otherwise the less than savvy user would not buy the product.

My observations are that free/libre desktops tend to be designed to dumb-down usability to the point of frustration. Especially with the GTK desktops. I use Trinity on my personal workstations but support Mate and Cinnamon for customers. I am continually frustrated by the lack of configurability in the GTK desktops. In Trinity I can configure just about anything, mostly from the GUI. With the GTK desktops I can't even configure settings from the command line or gconf/dconf because the settings don't exist.

For the non techie users the GTK desktops probably are adequate as designed. Those users don't miss what they don't know. Yet the web is filled with forum queries where, as some users become more advanced, they are stymied by the inability to customize GTK desktops.

I am not as upset that a specific GUI control does not exist. I get upset when no setting exists at all through which I could modify through gconf, dconf, the command line, whatever.

In that light, that proprietary OS you are showing disdain does get things right. Users might need the registry to hack certain settings, but at least they can modify those settings. The GTK desktops have been stripped and dumbed down beyond belief.

Python is a hell of a lot easier to learn/use than C++.

Comment: This is the Slackware forum but this thread has encouraged non Slackware discussion. There is interest in my journey and this post is a continuation of post 81.

Software in LMDE, which is based on Debian Testing, can grow stale. Bug fix versions of software, as opposed to security fix versions, are slow to merge into Debian Testing. Update Packs in LMDE are infrequent, where newer versions of software are derived from Debian Testing. Whereas stability is always the primary focus --- a fine goal, a handful of packages that are released frequently do not get updated in a timely manner in LMDE.

The key word is "handful." Examples: LibreOffice is a full dot release behind. WINE is two dot releases behind. GTK file managers suck big time but a potential replacement such as Xfe is three bug fix versions behind.

Debian has ways to overcome this staleness, but users must learn a complicated package management system. A support person could learn to build packages in Debian, learn to add repos, learn to prioritize repositories, learn to pin software. Doable for a single user but what about supporting multiple users? Probably best to leave everything as is, where the upstream support structure is already well laid and tested.

For my personal usage, I find Mate and Cinnamon frustrating to use. Sometimes to the point of using angry, colorful language. For years I had read how GTK based desktops have been dumbed down. I am now finding this claim to bear truth. Features that for years I have taken for granted in KDE3/Trinity simply do not exist in Mate or Cinnamon, not even through the pseudo registry. The file managers are clumsy compared to Konqueror (or Dolphin in KDE4) or even xfe. Search tools won't look for hidden files and granularity is limited to a full day rather than hours or minutes. Yet I have to remind myself that the users for whom I am installing these desktops are not power users and never will be. To them, the desktop is merely a foundation to run a web browser. Thus these desktops are more than sufficient for these types of users. Note to readers: KDE is not an option as the people being supported are using older hardware still running XP. LXQt sounds like a potential future option but is not ready for prime time and does not yet include basic PIM apps.

LMDE does have advantages: a huge upstream repository system, graphical package managers that blend well into the desktop environment, boot splashes for non technical users, update notifiers, automated dependency checking (great for non technical users), a huge ecosystem that is friendly to non technical users. As discussed in this thread, how much work is needed to mold Slackware with the same benefits?

Would PCLOS or OpenSuse have been better choices? I don't know. Desktop environments that support aging hardware is more of a priority than the underlying operating system.

For now I have no easy answers. I plan to continue using Slackware and Trinity for personal use despite my need to support a "less flexible" system for non technical users. I need to accept the limitations of Mate and Cinnamon along with the foundation that I am not the target audience for those desktops.

And I really need to start posting all of these ramblings in a blog.

1 members found this post helpful.

I do miss your "human readable" series. Last time I went looking for it, I couldn't find it, but do have a few pages printed out and in a file for reference.

Thanks. I got tired of maintaining the site and chucking money for maintenance. Perhaps next time I'll use a blog site. I surrender control of the site and content but I lose the hassles too.

With respect to my original post:

Graphical boot splash. Seems the only method available is Plymouth. My experience thus far in LMDE is Plymouth is potentially temperamental and plays havoc with the console switching keyboard shortcuts (Ctrl+Alt+Fx). The Plymouth boot splash is not as smooth as the Windows counterpart as there are two moments when the splash disappears and stdout reappears. Could be an LMDE issue too, I don't know at all. As boot splashes are not popular in Slackware land, as a compromise I could colorize my rc.d scripts to provide less of a shock to Windows users. I have been colorizing my rc.d scripts for many years.

Graphical package manager. Despite the discussion in this thread, I have decided there is only one reasonable choice: gslapt. The Salix folks use gslapt and seem content and happy with that. Using gslapt and slapt-get means not using slackpkg, but I don't see any problems in that. gslapt can be configured to search all known Slackware repositories, which would bump the number of available packages to a decent number, although not anywhere near as high as Debian or RPM distros. Conversely, I am intimate with building packages on Slackware and can supply my own packages when needed.

Automated dependency checking. Again, the Salix folks already do this, as do maintainers of other Slackware derivative distros.

A graphical update notifier. Salix folks again have something. I don't know how well the notifier works when non-Salix repos are used but what they have should suffice as a foundation.

One area I have not answered, and not addressed in this thread, is how to handle *.new files. I know what to do but what about users who are not computer savvy? Not as easy to answer. Basically the topic is over their heads. If I colorize my scripts I have to provide a way to avoid scripts being overwritten as well.

Another issue I am uncomfortable with is updating any Slackware based system with respect to computer illiterate users. I much dislike the way Linux distros are updated. To me, a rolling release or semi-rolling release is the only model that non computer savvy users can handle, especially those coming from the Windows world. Slackware Current would provide a way to have a semi-rolling distro and to remain current with security updates. While Slackware Current tends to be stable, I probably would have to intervene to provide a semi-rolling release model, or perhaps have the update notifier work through me rather than directly upstream.

There remains a number of tweaks required to make any Linux system more usable by Windows refugees. The bottom line is I probably am still discussing a new distro. I don't know that I have that kind of energy or smarts.

If you are curious, yes, I have many second doubts about using LMDE in our venture.

well, may be you could ask in the forum of the Salix folks for advise, as well?

Now, seriously, how do you colourise your rc.d scripts?

I recently replaced a neighbor's old Ubuntu setup with Salix and it generally works for them. I did set up a few maintenance scripts and gave some minor education about Linux which I thought was needed.

Salix is good place to start for a non-technical end user. But Woodsman brings up excellent issues which also impact Salix.

Try this:

14.0 Colorized Scripts

You can adapt the scripts to 14.1. I have colorized the 14.1 scripts but at this moment lack the time to create a 14.1 tar.gz file.

Elsewhere in this forum the topic has been discussed about having the option to colorize rc.d scripts in Slackware. That choice is not mine to make but I still think having the option to toggle colorization would be an simple but elegant touch for Slackware.

Last I looked long ago, the Zenwalk folks adapted the idea into their distro.

Well, not until I spend time with the distro. I downloaded the 14.1 Mate ISO and plan to explore thoroughly.

There is a limit to what the Salix folks might want to change. Their target focus is "lazy Slackers" and not Windows refugees. After crossing the line of "lazy Slacker" I am certain any further changes are up to me.

Yes, that works for a handful of users but not as a large-scale approach. The general approach I have found best the past few months is just assume computer illiteracy. Assume point-and-click. Assume the terminal does not exist.

Those presumptions might seem difficult or perhaps even silly for Slackers but they nonetheless remain valid. There is a huge chasm between what a typical Slacker presumes is normal in an operating system and what a typical Windows refugee considers normal.

The target audience for Salix is "lazy Slackers" and not Windows refugees. I don't think the Salix devs should be pressured into changing Salix into something I am trying to support. While Salix is a few steps closer to what I am trying to support rather than the stock Slackware, Salix is not focused on the same target audience that I am focusing.

Earlier in this thread we touched upon the dilemma of Linux distros being designed by geeks intended largely for geek users. I don't have any quick answers to that topic.

For example, yesterday I spent about an hour learning to disable all password requirements when configuring a printer. For home users configuring a printer, administrative passwords are just plain annoying --- and stupid and nonsense. Little things like this is part of the reason Linux remains out of mainstream circulation.

Another example is installations. There are very few Windows refugees who are going to learn to install a distro. They are going to pay somebody else to provide a system pre-installed. Thus respective user guides should not have installation instructions. Place those instructions into an administrator guide.

Another example I found with PCLOS. PCLOS provides two control centers. This is confusing to users, let alone a Windows refugee. The PCLOS control center components should be merged into each respective desktop control center.

I could go on....

1 members found this post helpful.

+1 for that.

These are two different target audiences, the installer and the end user.

I know how to drive an automobile and even to maintain an automobile, but I leave it up to the factory to design and build it.

I'm not sure I'd follow this analogy: installing a distribution is a lot simpler than designing and building one

I will refrain to add that in the automotive industry designing and building are done neither by the same people nor at the same time, as that'd look too pedantic and would be way off topic... Oh, that escaped me, sorry.

Salix installer is very straightforward and I don't think that even a newbie needs instructions to use it.

On the other hand to use Slackware installer a newbie certainly needs instructions, just because it has more features and options.

Of course Slackware installer displays help files (one for 'setup', one for 'pxesetup' and one for 'lilo' IIRC).

But even with that and with all the information available @ SlackDocs, I bet that many Slackware users are not aware of all they can do with the installer.

Well, I just trapped my self yes, I will write "All you can do with a Slackware installer" for SlackDocs. Not very soon, but I will.

I appreciate the sentiments of both of the previous two posts. That said, changing the engine oil on most vehicles is a straightforward task yet many car owners prefer instead to have somebody else "deal with the mess." Distro installations are somewhat similar. I started installing operating systems back in the days of 5-1/4 inch floppy disks. Then life got easier with CDs and DVDs. I can install systems and just finished doing so with another test distro. Generally though, I side with the computer illiterates. I'd rather not waste time installing and tweaking.

Tweaking. That raises another example for my previous post. After 30+ years of using desktop computers I have yet to see a single system offer left-handed mouse users an immediate prompt to swap the mouse buttons. Not during installation and not during the initial login. So every time I test a distro I repeat the same act of swapping the mouse buttons. Gets old....