People disagree, some people think that no operating system has any need for distributions, with all their difference and their central repositories that aren’t as central. But one of the thing that impress most the users who switch is, in many cases (at least that I could look at myself) the presence of distributions and the ability to install almost any software by simply looking it up in the package manager.
This said, when people think that overcomplex solutions are a perfect way to solve the issues that “vendors” have with distributing their software, you’re probably missing the point quite a bit. Instead of proposing changes in all the possible layers of the operating system stack, you should try to speak with with the distributors and see what you can do to make your software behave in such a way that they can lift the “send the software to the user” problem from you.
It’s a tremendously important point I’m making here: when you develop your software coming from a Windows background to work on Linux, youŕe probably making a huge amount of mistakes; the most common one is to assume that the directory to work on is the directory the program is in, or that the current working directory is the home of the user. Both differ between Windows and Linux. Fixing these minor issues is usually trivial, if you have access to the code, and if you’re willing to bend a bit around to accommodate the requests. In the case that icculus brought up, the proper solution is, generally, splitting the data from the engine, so that you can reuse the data between different architectures, and have a different engine for each architecture; or have a single huge download with all the architectures available, if they are, say, 10% over the size of the data.
The main point here is still that you have first to remember that distributions exist and that users like to rely on them (most of the time) and second to understand that neither the Windows way nor the OS X way applies to Linux. This doesn’t make Linux right and the other wrong, or vice-versa; they are three different worlds, and each one has its own good and bad side.
The biggest mistake in misunderstanding Linux for just another Windows version is providing a setup program, even worse a graphical setup program. If your software has no drivers to install, nothing to register itself into (there is no registry on Linux, after all), you most likely should not give that as the only option. First of all such a program would rarely tell you what’s going to do, and you’d also be going to run that with root privileges to install the stuff, so why should you trust proprietary software with root on your system? Of course if you’re just a “Joe User” you won’t care, you have no clue about that, but any decently skilled user would know that it’s never a good idea to trust any software you cannot control with root privileges on your box.
The second misconception is that some people seem to think that it’s a task for upstream of a project – be it a proprietary software vendor or a free software project – to provide binaries, installer and packages. This is the main reason why that silly FatELF idea is still tickling on some people. Well, let me say it once and for all it’s the distributions’ task to provide packages to the users!
Of course the problem is that distributions rarely can provide all the possible software in the world as package, may it be because their policy is to only allow Free Software (like Debian and Fedora) or for other reasons. In any case the solution is not to say “The distributions are the problem” but rather to wonder “Why are they not packaging my software?”. Of course when the problem is policy related to the license there is little to do, so you’re forced to rely on third party repositories (like RPM Fusion ) that don’t have such problems with policies. In general, a very little leeway for the distributions can go a great deal into making your software available to users.
All kind of projects who want to reach for users should listen to the distributors: that means that if a distributor complain about the way you (don’t) release software, for instance because you only use a “live” repository for the users to use, or about the way you make use of bundled libraries, you should most likely discuss with them a way to handle the situation; failing to do that is going to drive the distributor away (and then you’d probably be complaining that you’ll have to provide binaries for that distribution yourself). Unfortunately I’m quite sure that especially icculus have problems with stuff like that, given I’ve reported more than one Gentoo policy violation for ebuilds that come from icculus.
For proprietary software, this often goes not as much into the way of changing the development of the software but rather to change some distribution details: allow the developer to redistribute your software (so don’t use strange click-through download systems, don’t require the user to go a long way to find what it has to download); give a “raw tarball” option that the distribution can use as source for their packaging, be it binary packages, or source-based packages like Gentoo’s.
Move the packaging task to the packagers, they know it better.
And if you’re developing proprietary commercial software, you might want to approach some developers, and eventually give out some free licenses for them to play with so that they can package the software, and eventually give you feedback in what they would like for you to change. Most of the time, packagers are pretty pragmatic and will not be scared off by “helping proprietary software”; for instance in my overlay you can find some packaging for the Visual Paradigm Suite for which I bought a license a few weeks ago (I needed a working UML software for a job); it’s nowhere near Gentoo-ready, but I’ve not given up on it; since the Visual Paradigm customer support is also quite ready to answer to problems and suggestions, I’ve been sending them my feedback, both as user and as packager. Hopefully I might get to the point where the package is fine with Gentoo policies and I can add it to the main tree normally.
A similar situation happens with the EntropyKey software packaging since I was interested I got two of those and packaged it up; if upstream was interested in packaging this beyond their own support (I think they already have a Debian packager as part of the staff anyway), they could have created a developer program for distributors, and I’m pretty sure almost all distributors would have supported the ekeyd software in no time.
Yes, I am seeing all this situation from a packager point of view, but that’s because I definitely like this approach and instead of resent us for “not providing the stuff you want” or attacking distributions because “you have to make dozens of different packages”, try working with them. Like I said before, Ryan should stop keep inside his own little world where he can do whatever he wants and then expect people to bend at his needs, he should listen to the needs of distributors (which aren’t really so impossible!) and so should anybody who want to enter the Linux ecosystem as it is now.
And it’s definitely not only proprietary software that still doesn’t get this, Mozilla has had a hard time to get to work with distributors, OpenOffice still has such a hard time, Avidemux is a perfect example of how a package gets to ignore all the possible distribution requests (by still shipping a modified FFmpeg for instance).
Most of the time, the reasons why developers don’t want to make accommodations for distributions, are stuff along the lines of “I don’t see what difference does it make”… which is also the very reason why they have such a hard time to get their packaging together.
Regarding the deviation from the FHS you omitted http://nixos.org/nixos/inde…I can’t say anything further about both current Gobolinux and NixOS because i don’t run them, nonetheless i’m following their concepts, which i find imortant from the point of view of complexity management. For me it sometimes seems we are heading towards a “digital tower of babylon” which is soon about to be crushing itself under its own weight. Anyways, just wanted to remind you of that.
Great post. People don’t realize that there are a lot of users interests that don’t coincide with a software project/vendors interests, and those user interests that don’t coincide are often happily trampled upon by them. For example, if your system gets screwed up or becomes insecure and its not obvious that its a vendor that did it, they mostly DON’T CARE (for example, see windows software). Enter distributions. An organized group of people working SPECIFICALLY for their users interests. What an amazing idea! And what they have achieved really is amazing. People definitely don’t appreciate what distros bring to the table, but when I think about the future of software in general, I pray that distributions can grow and gain more influence as a priority even before free software. For example, tivo may use free software & linux, but it’s certainly ignoring user’s interests.
What I’d like to see to make it easier for developers to add Gentoo support for their program is a simple *.ebuild handler – for example integrated via a .desktop file.Then users could download ebuilds, click them, and have the ebuild handler put them into an automatic handler-overlay and install them (in KDe they could even just click them and say “open with ebuild handler”).That would provide one-click install for all programs whose dependencies are in in the tree, and if users would want a specific program in the tree, they ćould just file a request and include the developer-created ebuild.Because of that I think Gentoo that has a huge potential to make installing any program convenient for users, because creating an ebuild (and keeping it up to date) is simple and fast compared with creating debs or rpms.About the security problem: Currently users download the ebuild, put it in the local overlay and then execute it anyway. But maybe a policy to require confirmation for nontrivial ebuilds would be useful.
I’m not really sure I agree with this. Distribution repos are a tradeoff – you get better QA and a more consistent user experience, in exchange for higher developer load and a higher barrier to entry.Look at Gentoo, for instance. You have literally hundreds of developers working to keep software in the repository up-to-date and integrated. Meanwhile, there are tens of thousands of packages that will never make it into the main tree, due to lack of developer interest, lack of widespread user interest, or other factors.Or, look at it from the perspective of a third-party developer. In a perfect world, their software will make it into the main repos for every distro and everything will be awesome. More realistically, though, it won’t, and they either have to provide generic install methods outside of the distro package managers, or they’ll have to include more involved installation methods (“add this overlay and then install”, translated to every single half-baked linux distro out there).I think that Linux as a whole can be pretty hostile to third-party software development, and the overreliance on distro package managers is just a part of that.