Insync 1.0 was introduced, which, by itself, is a good thing, particularly because Google chose to pass on writing a Drive client for Linux but provided one for Microsoft Windows and Apple OSX last Spring of 2012.
That's to be expected I guess. After all, they represent two very big markets with essentially one codebase for each operating system--fairly simple in view of long-term maintenance. I think that's a safe assumption.
But today we have Linux complete with all of the wonderful open source and choice at our fingertips. So much variety. That is trumpeted as a good thing. I would tend to agree, to a point.
Here's where I see a problem that hasn't gone away and keeps on growing. Take a look at this page:
 |
| Insync Loves Linux web page
Note how many Distros are on the page, each with its own permutations of GUIs, each with its own File Manager, each with its own system file structure, each with its own package management system.
Continue to scroll and you get a complex mish-mosh of directions depending on which Distro is involved and if none applies, you can get a tar.gz download and untar and hope for the best.
Honestly, I would be a little intimidated as a new user of Linux were I to see that.
It's a big roadside sign flashing and warning. Begs for your attention. What is the message here?
Standardization!
It's the lack of standardization which is the crux of the issue.
Will the continued diversification, forking, spins, work to our collective advantage? It's a fair question and from a development standpoint it creates layers and layers of complexity for each new variation.
I submit, it's not going to stop and the cost of implementation for Linux systems deployment will rise correspondingly unless something is done about it.
I wrote about Linux Standard Base and feel there isn't enough being done to address LSB-compliance.
What would it take to join together to achieve LSB compliance for one file structure standard, one universal package management standard. If that were accomplished, we'd see the number of installers reduced substantially.
Standards need not be a control issue. Standards help reduce costs. On the front page of the Linux Standard Base reads the following:
The Linux Standard Base was created to lower the overall costs of supporting the Linux platform. By reducing the differences between individual Linux distributions, the LSB greatly reduces the costs involved with porting applications to different distributions, as well as lowers the cost and effort involved in after-market support of those applications.
That seems to be a worthy goal. We really need to do something about this before it gets out of hand.
What can you do to help? Ask your Distro support channel if they are LSB-certified. If they are not, voice your opinion loud and clear: Petition them to become compliant and have them make it a top priority feature enhancement requirement.
One file system structure, one package manager.
How do you feel about this? Give us your feedback.
--Dietrich
|
Excellent article... great food for thought.
ReplyDeleteI am a big supporter of consistency *within* a distro but there is also something to be said for at least some types of consistency from one distro to another. At the same time, as you say, this should not (and really could not) be forced. It is excellent that people can and do work with new and different ways. If you do not have that you risk stagnation.
Once challenge of having such standards is making it easy for developers to be able to write software that works just as well with different DEs, not just *working* on a system but fitting in with the whole look and feel of the system (using the same common terms and hot keys and save and print dialogs, etc.). Not an easy thing to do - but important to help get more developers to come to the open source table and to make distros easier to use for both novice and advanced users.
Dietrich, I work for a small software company and it would be great to just target the LSB for our Linux versions. I was happy to see that Qt is part of the standard, but the library versions are so old that we have to ship with our own versions, so it becomes a somewhat pointless exercise.
ReplyDeleteI'm all for standardizing file layout and packaging. My guess is that those who are adamantly against the basic standards you suggest don't have to support paying customers. As it is we ship both RPMs (conforming to LSB) and tarballs (for everyone else).
If there is anything we should have learned from the Windows world it's that making everything the same leaves systems wide open to massive levels of very rapid infiltration requiring stupid amounts of money to be spent on securing the monoculture.
ReplyDeleteDiversification breaks things up a bit. It's not only a security advantage in it's self. But it opens up opportunities in the market. Where one developer will focus on RHEL. Another can focus on providing similar services for Debian. If Red Hat goes bust tomorrow, Canonical are waiting in the wings.
Encouraging a monoculture stifles innovation and leaves us vulnerable. Linux has evolved rapidly because developers are free to go their own path. Who cares if Google didn't build a Linux client for Google drive? I use Dropbox and Ubuntu One.
You miss the point.
ReplyDeleteThe Mess is about 1) FHS 2) package managers
of which there are variations
Those can be addressed and unified without impacting choice whatsoever.
And improving the core user experience as well as saving cost.
Security wouldn't change and given seccomp-bpf and SELinux sandboxing I don't see a downside to the above changes.
Karl,
ReplyDeleteI would love if you'd consider being a 'Guest Writer'
You can add alot to the LSB and share your own experiences.
If you want to write, reach me at:
dietrich at linuxadvocates dot com
This. Package managers are the biggest problem in my opinion.
ReplyDeleteHow about say, a committee is formed for all the different distributions that decides on the name for all new packages (which can be dependencies) that are to enter their repositories? That would take a lot of the hassle out of that. Then they can hopefully work towards a single format, though surprisingly, that is less critical.
Your post is just another one of these posts complaining about to much diversity. The usually pop every 2-3 months.
ReplyDeletePeople complaining about diversity, actually hate choice, and are probably happy eating only one type of bread and cereals.
Choice is good. I don't really see any problem to have many jeans or shirt in a strore, would you? You dont need to buy all of them. You just choose the best one for you.
This is basically how "WE" human beings were created. Through adaptation of species. Many of them are gone by now, and this crazy adaptation created many species who didn't last long, or some crazy stuff like the Platypus, but I don't we should complain we have "too many species".
People want to try new stuff and test things. If they for example want to bring it to the masses the could try to put it in Debian or any other big major distro, but this is not for everyone, because it takes more bureaucracy then just coding (at first).
So people create new breeds and derivatives, and if the survive long enough (due to technical merits, or great marketing) they will eventually become part of the "standard".
To sum, choice is good and choice is natural. Have choice means the ecosystem is driven forward by diversity and competition.
You missed my point.
ReplyDeleteTwo things need addressing sorely:
1) FHS Filesystem standard compliance
2) One Unified Package Installer
Those are programming implementation details that can be encapsulated behind a gui--the user won't see or care so long as they can say I can install this package on any Distro--quite a claim and technically achievable.
It strengthens the entire ecosystem and those two issues have nothing to do with choice or diversity, nor will choice or diversity be limited in any way.
No, you missed my point.
ReplyDeleteOne package manager is not necessarily the best package manager.
From "economical" point of view, it might save resources, but it will make it harder for new implementations and ideas to become reality.
The same for FHS. Maybe, there is a better organization waiting to be discovered.
I did not say at any point that the other native package managers should go away--having a unified installer is a tremendous cost savings advantage. If you don't see that, I am sorry. We'll leave it there.
ReplyDeletePackage manager standardization is never going to happen. Portage, APT, RMP, pacman... They all have reason to exist and they all adress very specific needs and desires. Making all distributions settle on one solution means effectively removing choice fromt the user. I want my portage and no one is going to take it away.
ReplyDeletePlus having one package format would not solve the "problem" of current distro releases not shipping with the exact same version of libraries and stuff. Nor would it solve the "problem" of different init systems being in use. Or should all that be "standardized" as well?
Those managers needed go away. Saying one can obtain software and easily install it (from Add/Remove Programs)to 'any' Distro is a powerful claim. And having an intermediate POSIX layer to arbitrate implementation site specific needs can be a layer of abstraction which hides the implementation details from the user who still sees and uses their GUI to perform the install. Make sense?
ReplyDeleteOn your two points, I couldn't agree MORE! Over the last couple of years I've noticed a huge difference here in Ontario Canada with people never hearing about Linux, to now knowing about it and some even using it.
ReplyDeleteI consider myself a huge supporter of "Linux", and promote it as often as I can. However, when people complain about things, it is usually the things that Linux doesn't do well... one being "I can't run ". Just like all of us Linux users, we like what we like and like what we're used to. So if a distro doesn't support a program, then we've lost a potential user. (Insert 1000 negative Linux users proclaiming, "We don't need them then!").
One of the biggest problems with Linux is there are too many Moses-type, bare-footed, camel-haired-coat-wearing types that condemn all those that want some standards... but why? You still have the full freedom to roll your own Linux and pack it full of your own camel-haired way of doing things!
However... some things just don't need personal opinion. Like the file structure... like who cares where bin files go and user files go? Set the standard and free millions from having to do things 300 different ways because you personally need your own structure. It would take one single release + 2 months and no one would care that it was a standard file structure anymore. Just pick one!
The other one is the way software is installed. RPM vs DEB is so unimportant to MOST Linux users. If the LSB said DEB was better... I would use DEB. I could care less... as long as it worked! I would also rather have one HUGE LSB driven repo, so that if it has been deemed OK by the LSB, I know it is (to the best of their knowledge) virus free and just works on my personally preferred distro. (Fedora + Cinnamon for anyone keeping score).
Some things we need to have a choice on, others I couldn't give a flying... care.
So with these two points, I totally agree with you Dietrich. Linux needs more standards on things that keep us from being little islands on our own and with our little flags stuck in the ground. We're stronger when we fight together.
FREEEEEEDOM!
That last point was a nice touch. Remember Linus saying that "this isn't a dick sucking contest!".
ReplyDeleteFrom a high-level and purely theoretial perspective it makes perfect sense. The reality however is a totally different matter. Personally I don't think it's a good idea to add yet another layer of "abstraction" to "hide" the underlying system from the user. And this approach would definitely not work for source-based distros, such as Gentoo, where a user might have compiled out some features in the dependencies of the binary package to be installed through this abstraction layer.
ReplyDelete