Re: linux annoyances

Christopher Taylor wrote:

> Ok here's my first listing of major linux annoyances. I do a lot of 
> customer support and although I can do most of these things just fine 
> I believe they are the major stumbling blocks to Linux being accepted 
> by the common majority of non-geek business users. If we want to take 
> market share away from the evil M$ then we have to incorporate these 
> things and a lot more to make it possible for linux to be configured 
> in a completely user friendly manner.
>
>  
>
>  
>
> 1. The support for interoperation with windows filesharing is crap. 
> When I fire up a box and put in the workgroup/domain in the install I 
> should have a "network neighborhood" style browsing through the 
> network immediately available without further configuration, just like 
> in windows. Configuring samba is just plain stupid. It should work 
> immediately. You should also be able to right click on folders in the 
> gui and share them just like in windows.
>
>  
>
> 2. Auto mounting of hard drives. No normal user is going to know how 
> to use the mount command. Its ludicrous, auto mount them and put icons 
> on the desktop. Give them their windows labels if they have them. hda 
> is a stupid name for a drive.
>
>  
>
> 3. A unified installation is needed for application installations. All 
> dependencies should be included in an application installation.
>
I'm sure we can all agree that we need a unified installation.

The problem is, we have trouble agreeing which one it should be.

> Screw the geek install crap.
>
???

> It should be one executeable file that has EVERYTHING it needs to install
>
Doesn't need to be an executable per-se. It only needs to
*look* like an executable to the eyes of non-geek users.

If it is in a standard format then the GUI desktop should be
able to recognize it and automatically invoke the installation
application without the user having to specify the program.
Thereby, in effect making it *look* like an executable to
non-geek users, but without the limitations assocated with
it actually *being* an executable under-the-hood.


> and it should be smart enough to adapt to all major distributions with 
> absolutely minimal user input and all options available as check boxes 
> or some other menu.
>
I'm working with something that has that ability. Instead
of hardcoding the locations where files go, the installation
program automatically customizes the package based on
preferences that are stored on the system.

With something like this, all that would be needed for the
package to automatically configure it's self for the current
distro would be the preferences for that distro.

I hope I can get more people to notice this program, because
I really believe that it has the ability to unite the distros
into one formidable force that can defeat Micro$oft.

It's an Open Source program under the terms of the GNU
General Public License, and is hosted at SourceForge.net.
http://boxenv.com
(If you enter the URL above, it will automatically
forward you to the SourceForge-hosted web-page.)

The only thing currently lacking in it is the ability for
it to detect dependencies *before* it begins the install
process. There are plans for it to *eventually* include
that feature. I would be greatful for any help that could
make the day that this feature is implemented come sooner.

Oh, and it would also be nice if it had a GUI to deal with
situations in which a preference variable is missing or has
an invalid value. But I believe that it eventually *can*
have that feature.

This software can work either with tarballs or with it's own
*native* packaging format. Based on your call for "one ...
file that has EVERYTHING" I would guess that you would prefer
it's native packaging format.



> Some kind of utility that will repackage those ridiculous compile 
> installations into an install would be good too.
>
Regarding installation programs that have the user compile
the program: when you really think of it, the problem is not
that the program is *compiled* at install-time, but rather,
that the non-geek user has to be *aware* of this fact (plus,
of course, that all too many times this compliation process
is not propperly debugged, but that's a separate issue).

The advantage of having software compiled in-advance is that
it speeds up the installation a little bit. Plus, if you're
shipping a proprietary program, you don't want to ship the
source-code too, so it will *have* to be compiled in advance.
(Yes, some people might consider having a free OS to be more
important than all the high-end applications that run on it
being free: and therefore it makes perfect sense for an
open-source OS like Linux to be supportive of proprietary
applications.) The reason I do not count ease-of-use as an
advantage to compiling things in-advance is because a decent
packaging format will make run-time compilations transparent
to the non-geek user.

The advantage of having software compiled at install-time is,
of course, ease of customization. A program compiled in
advance is going to be limited not only to a specific Operating
System, but to a specific CPU instruction-set as well. Also,
if you want the program to run on different distributions, it
might be necessary in install-time to customize certain things,
such as where certain files go, where certain files are to
be found, and so on and so forth. Though there may be ways
to do this on executables or on object-files, it would no
doubt be easeir to do this on the source-code.

Then there is also a thrid-option: compiling part of the
program in advance and part of it at install-time. For
example, let's suppose you're releasing a proprietary
application, and don't want everyone to see your source
code, but you want your program to run on different
distributions. You could have everything compiled in
advance, except for one file (or a few files) containing
the variables that need to be customized from one distro
to another. Of course, if you do this, you'd have to write
your install-script in such a way as to make sure that
you don't depend on any header-files that might be a
source of incompatibility: but a good programmer can
make sure that isn't an issue.

This system I'm telling you about that I developed and
that I use every day at work allows you to work with
all three of these schemes: and no matter which of these
three schemes you use, the non-geek user doesn't have
to know if anything is compiled at install-time.
--

>  
>
> 4. Clean up the application menu and start having icons placed there 
> automatically for new installs. If a user doesn't pay attention where 
> they installed something it could take them forever to find it. Make 
> the menu drag and drop adjustable so it can be easily reorganized.
>
Is there a command-line tool to add things to the menu?
If not, there needs to be one. The reason for needing a
command-line tool that can do this is so that I can have
the install-script invoke that command-line tool without
having to bother the user.
--

>  
>
> 5. Make a gui for all system configuration files. Everything. Give 
> them all buttons and text boxes. I know the geeks love doing it all by 
> hand but that just doesn't cut it when you are calculating the TCO and 
> including customer support for suits and low level data entry people.
>
As I mentioned earlier, that's on the to-do list for the
program I'm telling you about. Unfortunately, I don't have
the know-how to implement this feature myself, but I would
be happy if someone else were to jump on-board who *does*
have this know-how.

Yes, geeks *do* love doing it all by hand, but allowing
people to do it by hand and allowing them to do it with
a user-friendly GUI are not mutually-exclusive concepts.
I stronly believe that *both* options need to be supported.
--

>  
>
> 6. The display resolution needs to be able to be reset from a control 
> panel and it needs to have a simple failsafe mode and a test mode. It 
> should absolutely never be necessary for a standard user to have to 
> type some cryptic command line in and navigate a bunch of ridiculously 
> obtuse questions in order to change the display resolution and depth 
> to their liking. And then if they choose the wrong setting they can't 
> get to their gui. That's ridiculous. I couldn't even count the hours 
> I've spent configuring X on machines. Its a HUGE WASTE OF TIME.
>
Is there a way that the system can auto-detect the brand-name
of the monitor attached to it? If it can, then all we'd need
is a database to generate the configuration settings from the
monitor-name, without the non-geek user even having to know
what happened.
--

>  
>
> 7. Simple driver management interface. Ever had to remove a driver? 
> Replace it? Go back cause the new one didn't work? Theres no way linux 
> will make headway in the desktop world if drivers are in tarballs and 
> require a compile to test and swap. Better generic drivers are needed 
> too that will work with most anything if you don't have a specific 
> driver for a piece of hardware.
>
>  
>
> 8.There should be a setting to hide the system directories from the 
> users vision in the file explorer windows. It would be even better if 
> all the major system directories and mount points could be put in one 
> "linux" folder in the root. Not like it will ever happen but it would 
> be one of the best things for end users.
>
Yes, that feature needs to be implemented.

But geeks should always have the option of turning that feature
off if they want to.

>  
>
> 9. Some kind of keystroke that actually works to suspend all non 
> essential processes and call up a list where the user can kill the 
> runaway proces by right clicking.
>
>  
>
> 10. Better documentation. Some of this stuff is just plain geekspeak. 
> Sure I can understand it if I try, but I have end users who get 
> confused when I tell them to right click or use crtl-c, crtl-v
>

Amen to that.

And to do it, we'd need an easier-to-work-with documentation format.
If I'm correct, the Linux Documentation Project expects you to work
with SGML, an endeavor with which I've had zero success.

Unfortunately, I don't know of any good documentation format. Man
pages are not the answer for non-geeks, and SGML is too much of a
hairball to work with.
--

>  
>
>  
>
> OK, thats it for me for now. L8r.
>
>  
>
> *Chris Taylor, Systems Engineer*
>
> MCSE/MCSA, CCNA, A+, Websense WCSE
>
>  
>

Cheers,
Adam