You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Keeping it Simple

You know you're in trouble when you have an operating system which is at the pinnacle of technology and championed by a very vocal group; which has the support of thousands of developers from around the world; which is supported by a body which aims to "protect and standardise". Welcome to the would of Linux.

If someone stopped me on the street and asked me what the biggest problem was with Linux, I would instantly say that the fragmentation in place is muzzling progress. Look at the package management systems: you have RPM and .deb, a whole host of other, smaller systems and them wildcards such as Slackware and Gentoo. Look at the desktops: KDE and GNOME are by far the best supported, although xfce and LXDE are both viable alternatives, with many, many others again seeking honours. Even seemingly trivial matters such as sudo and su hold Linux back. So much for standardisation, then.

When the Linux Foundation started to gain strength I was immensely relieved. Finally, issues such as package management would be solved. One executable file would work on all Linux distros, all-but removing compatibility headaches for commercial publishers. Has it done anything? My a*se it has. The Linux Foundation seems unconcerned by the troubles in the Linux world. The one organisation with the power to break the deadlock between the likes of RPM and .deb seems to be mired.

Well now is the time for action. If the Linux Foundation is reading this then please answer this question: why can't you sort out the small but significant spats which dominate our community? Why are you so prepared to sit back and watch while desktop Linux sinks without trace? I would LOVE to hear your reply, as ever, the comments are open!

Comments

Being that Linux is only a kernel, there is no real goal from the Kernel end to organize the Software the runs in unison with it. The Linux Kernel it self is already unified, solid, and well supported as a standard.

But even the Linux Foundation is causing fragmentation. The Free Software Foundation was founded first in 1985 (vs 2007 for the LF) and has put out 'recommendations' on what to use. Among these is not only the root file system structure but the use of RPMs as the package manager... which, by the way, is fully capable of supporting all linux operating systems with one package. However, the rpm install scripts are generally only setup for rpm in it self. This about it... an RPM could be told to extract everything to a temp directory, or maybe even /opt (where is should be if it's generic precompiled binaries like blender or firefox) then it could re package the files in the native package manager, then reinstall it self using the native package manager. It would just have to check for the existence of the version file information in /etc.

Don't say that gnu/linux OSs don't have standards either. Through everything out there and all the projects, there is only one xorg windowing system and two major, and often dual supported, gui kits. (QT/GTK) with a few fragments like imlib from the Enlightenment libraries.

EDIT:
In fact, the only thing that LSB from the LF would do is make a slew of LSB based OSs. This is no different than what we already have with Red Hat, Fedora, Ubuntu, Debian, Slackware, etc. based operating systems.

Why is their set standard of software packages, software versions, and the like any better than the standards of each individual operating system...

Infact! Other than the initV scripts, Slackware is probably the most 'linux' compatible because it follows FSF recommendations as well as use vanilla, un modified, versions of as many packages as possible. It doesn't toss its own unsupported patches ontop of one program to make it compatible with another, it uses the real versions of each program that plays nice with all the others... Granted, Slackware's package management is its own, it does have RPM capability if one chooses to use it. This is because Slackware does not have any ancillary package repository. The install CDs contain the only and complete officially recognize repository and it's recommended to always do a FULL install. That is Slackware.

If one were to follow the LSB standards, that would be LSB. It wouldn't be a unique Operating System. It would be LSB.

Would you say that it would help if The Linux Foundation (and the LSB) and the FSF made the same recommendations? If so, that would create a rather influential set of standards. You also mentioned the Kernel and X.org, and surely by extension you must ask why we cannot carry forth these examples. The kernel and X.org are good, unified and standardised, why can't many equally important parts of the Linux OS be the same? Perhaps if we could resolve the issue of Qt and GTK+ then it would make life easier as wildcards like Enlightenment are easy to ignore.

You also mentioned Slackware, and while I appreciate what you're saying, it is surely a little naive to consider Slackware a key player in the Linux world for all but the most dedicated users. Your point still stands, though, and you must surely ask again why others cannot follow that example, although my knowledge in how you actually create such things is fairly poor.

However! Everything that makes them considered "gnu/linux" is already standard. It's just not the software version numbers.

Just like most of the things holding windows together makes them windows.

The reason we need both QT and GTK+ is because it creates diversity and new ideas that may get struck down in one GUI but take off in another. The KDE plasma desktop being one of them. It is actually quite brilliant but needs the kinks worked out.

If you want standards in the way of which software to program with, then I would use GTK+ for everything that isn't specifically designed as part of KDE and stay far FAR away from gnome libs.

-----

One area where standards would help would be recommending version groups for specific things so that a 3rd party closed source program can have a goal to look forward to.

Example Blender requires glibc 2.36 and python 2.6.
Most newer versions of gnu/linux OSes support this but older versions do not.

This is akin to saying ProgramName runs on XP but not 98.

So recommending LSB 5 has QT version, 4 GTK version 3, and xorg version 7.1, with imlib2 version 2.6 would be just fine. Then a software maker could say I want to make a QT program that supports LSB5 with imlib2 extensions to make handling pictures easier.

But recommending GTK over QT... or recommending Pulse over Jack... or recommending Python over Perl or Ruby is just wrong. That is the wrong way to go.

I don't want a flame war here, so please allow me to make my final word on the matter. It is obvious that different members of the Linux community want different things, and that's what makes open source software great. There is no commercial vendor hell bent on making us upgrade. No commercial vendor using illicit tactics to make us use their products. We can all be narrow minded bigots at times, and I realise with sober reflection that some of the things I said were perhaps toeing the line a little too much. While I stand by what I said, I appreciate that I am probably in the minority here, and it was not my intention to either cause offence or undermine anyone else's opinions. That's their business, not mine. I want to apologise, and I hope that this little spat merely contributes to the rich and shared knowledge and opinion which makes up the community the best tool for what we all want: the continued growth and success or Linux and Open Source.