Search This Blog

What Free Software needs

When I was young, I remember wanting SUSE 9.2 Professional. It seemed like a good stable system with many good reviews. Afterwards (luckily) the distribution switched to GPL and I managed to acquire a copy of 9.3. It was very good for its time, its acheivements vastly outstepping anything I had previously seen. With instant search, good photo management, and all the rest, it seemed to be a good stepping stone onto which further development could be put upon.

A while later, I find that "cool" features seem to be getting less and less common. With the advent of Compiz a few years ago, coolness in the desktop rose a little, but with less common other features, and small incremental updates in most distributions, computing was getting a little more boring, with little to wow about. We now need a good jump up, or proprietary software will catch up. KDE 4 recently has been a downfall, mainly because people disliked it from being so very different to the very stable and mature 3.5 series, which I was in fact excited about at the time. When the "broken" Microsoft Vista followed after KDE 4's (premature) release, people managed to give Vista bad hype for being so out of step with current needs that it would not run software that ran on previous releases flawlessly. Between now and then, KDE 4 and Vista have largely sorted out their concerns. Ever since Vista SP1 and KDE 4.2, I think a lot more people are happy with either release. But many people still dislike this new "dark" theme over the previous light theme, and as such prefer to stick to the "dead" XP or the less-supported KDE 3.5.

Other problems we in the Free Software community face are:

Lack of standardisation. Yes, as much as I hate to say it, standard ways of doing things are waning. Especially in the Linux community, 500 different distributions are not a good way of doing things. Factoring out the "useless" distributions, based on whether they have been done before, how useful a distribution is, whether the same effect could be copied painlessly in another distribution, I think maybe 50 might remain.

Lack of standard package formats. As much as I still hate to say it, all Linux distros need one defining package format. Right now it is considered too difficult to develop for Linux, as there are so many formats to develop for. DEB, RPM, RUN, Autopackage, TAR.GZ, TGZ, and others make it difficult to develop for. I think we need a standardised package format and standard repositories that all distros can pull from. Having different ones means that it is currently difficult and long-winded to document how to install software on all current distributions. Here is what I think we need:

One format. One format, one download link for Linux, one way of packaging. Easy, simple.

One repository. One website serving download links for every conceivable package, in an installable static format (including every library it requires) or dynamic (for short downloads).

Every application. There are far too many repositories. There are in excess of 50 for Ubuntu and openSUSE. Why can't they just all be in the same place? Of course, to keep freedom-lovers happy, split it into free and non-free but essentially it's easier to get what you want now.

Every proprietary game or application maker can now package their game or application into ONE single format, upload it to ONE server (if necessary) or ONE CD/DVD/USB, and allow use or play to EVERY free software user.

Standard Libraries. GNOME and KDE are in pretty much fair competition. I cannot dispute or argue against it. Choice is paramount, but applications that don't work are unacceptable. If there were a library that could be used to create desktop applications that would run fairly on each, and not look foreign on one or the other, then it should be developed upon by everyone trying to provide a fair experience. People don't always have the libraries that are needed by some obscure piece of software, so they should be readily available, or the application should use something more common.

Backward/Forward Compatibility.Proprietary module or "driver" creation is impossible in Linux. If a hardware manufacturer wishes to hide the functionality of their driver, they cannot release binary-only drivers in Linux currently. I know that manufacturers should be encouraged to develop freely, but if there is no chance of this, there is no chance of that hardware working on Linux. The license makes it difficult but I believe that if a manufacturer provides one of those "Driver CDs" in that standard package format above with Module Versioning support on in the kernel, drivers do not have to wear out.

The kernel seems to not like modules from a past or future kernel, mainly because it is not at all stable, but also because Module Versioning does not work by default in most distros by default. Looking at Windows, applications and drivers from a number of years ago will work in today's release, and (in general) releases before the release of the application or driver. We need this back-forward compatibility for proprietary software vendors (who can't be convinced to switch to free) not to have to either release their code or keep compiling their code for each kernel or new release.

A hopeful fixI'm in the process of creating a browser-based desktop environment that will hopefully overcome all that, and allow for major cool features as well as ultra compatibility and ease of use for new users. It isn't Linux, or anything to do with current free software but it can lie on top of Linux/Solaris/BSD/Windows/Mac/whatever if the user so wishes.Xenon

Comments

The package system problem come only with propriary software, with FOSS, the package are the problem of package maintainer of the different distributions. The one format is not a real problem for devellopers. If they want to make a package for distribution it is their problems, else it is the package maintener's problem.One repository for all distribution is not technically possible, because distribution have different package update system and motivation, many just take stable version (like Debian Stable) and other are bleeding-edge and rolling-release (like ArchLinux) and this is really good, I don't imagine using Debian on my personnal computer and ArchLinux on company server. I also think on different compilation options.

The lack of standard librairies is a problem, but not a big problem, we can easily have 2 ou 3 different librairies without problems.

@xenom Distros do different things but maybe if we had stable, testing, etc repos for enabling?

@P. Static Oh no, mine is doing way more than fixing these problems. I'd love current distros to overcome this and standardise with each other. Otherwise, maybe a "1-click install" for new repos and packages is in order, which integrates with their package manager, whatever it may be.

Popular posts from this blog

I haven't made a blog in a long while, so I'd thought I'd share this, which I recently discovered how to do.

If you find the idea of proxies a bit restrictive. because after all, they have to be set up in the applications in question, and may not work for some applications, help is here. And all you need is an SSH server you can connect to. Sadly, this method requires root, but it's worth having for the system-wide Internet connection you'll get from it.

Authenticating as root
First, make sure you're root on the client machine (sudo -s or su -, depending on your distro), and that you can ssh as root to your target server. This is of course causes security implications, so it may be a good idea to generate a key pair for root-to-root access and block off passworded access for root, so that no one can bruteforce your root password.

Did you know that Android devices expose a modem on the USB interface, even when "Tethering" is turned off? It appears like this in dmesg:

[22338.529851] cdc_acm 1-3:1.1: ttyACM0: USB ACM device

You can connect to this as a raw serial console like: screen /dev/ttyACM0 or: minicom -D /dev/ttyACM0

This will accept GSM modem commands prefixed with AT, and give information about the phone, and presumably allow a dialup-like interface.
Many of the examples on M2MSupport.net will work with the phone, depending on which manufacturer and capability set, presumably. With my Samsung Galaxy XCover 4, I got the GSM capability set.
Try playing around with this, but don't get charged by your provider too much for making calls you never end! Make sure you hang up properly as per the protocol.
For more on standard modem commands, see the Hayes command set article on Wikipedia.
That's all for now!