A while back I replaced Mint 4 on my main production desktop system (A Dell 745) with OpenSUSE 11. Since then I have been loading up every update that OpenSUSE has released on a nearly daily basis. The good news is that in almost every way, OpenSUSE 11 is a terrific release, and light years ahead of where it was when I first started messing around with SUSE back in the release 5 days.
openSUSE 11.1 Beta3 is a bit later than expected (it should go out later today). Of course, this raised couple of questions why. So let me explain how a build of a Beta release works in general from release manager perspective and what are the reasons for the slip.
Although OpenSUSE doesn't provide quite the same level of polish and simplicity as Ubuntu, it does offer some compelling advantages. OpenSUSE's unbeatable Mono integration is a big win for many software developers, and the distribution also has great support for desktop search integration via the Beagle indexing system. The OpenSUSE KDE environment is among the best, which is why we have typically used OpenSUSE as our reference platform for KDE testing. The 11.1 release is looking really sharp and continues to play to those strengths.
Opened up dolphin, man I think to myself, this thing is snappppppy. I am quite impressed with the performance. I do a few other things that would put you guys to sleep, and log back into my KDE3 session to write this up.
So how would I rate my overall experience? a 7 / 10. A much higher 2 / 10 I would have given 4.0.4.
This week we caught up one of the many people responsible for the success of the openSUSE project maintaining mailing lists, IRC channels, and openSUSE project meetings, as also doing some packaging in the well-known Packman repository. Today you have the opportunity to meet the current openSUSE Board Candidate Henne Vogelsang!
In this week:
* Power Outage of most openSUSE servers * Retiring from the openSUSE Board * Status openSUSE distribution * Pascal Bleser: Packman: removing openSUSE 10.0 and 10.1 packages * Bernhard Walle: Automatic reboot with kexec
Comments
Yfrwlf
2008-10-25 21:17:15
One of those is software accessibility, and the "review" by Steve Carl where he really mainly just has a problem with Evolution 2.22 is a great example of that. You shouldn't have to switch "distros" just to install a different version of a program. Linux has become a walled garden to some degree because normal users don't know how to compile nor should they have to know. Once some standardization comes about for Linux packaging one way or another, with the aid of whatever standards groups who want to help with it, and it's adopted into the existing popular package managers, then Linux software will truly be free and so will its users.
As a long time Linux user, I still never stop being appalled and shocked at the lack of solutions in the most important area of "software freedom": accessibility. If Linux wants to see real mundane user adoption it needs to tackle this issue, and it CAN be done, and bring everyone much more choice and freedom in the process.
Zac
2008-10-26 01:44:48
Zac
2008-10-26 01:47:10
Yfrwlf: I agree. I hope something can be done in this area before Windows 7 comes along.
Roy Schestowitz
2008-10-26 01:52:43
There is no Novell hating and I never hated Novell. I just strongly disagree with them and encourage people not to feed them financially by buying their products.
As for these posts, we have done this for a very long time. SUSE people complained that we only cover negative stuff and therefore we're too biased. Well, we cover everything now (Novell-related news), but there's no capacity for doing everything as standalone posts.
Eruaran
2008-10-26 02:51:55
This is reason enough for me to strike OpenSUSE off my list of distro's to try.
saulgoode
2008-10-26 12:59:53
At best, you will attain a "group" of distros across which a subset of the different versions of a program function. This is a situation we basically already have; and I don't see any reason to expect it to change. The distros which adopt a fixed standard will not be able to support newer versions of programs unless the upstream projects restrict themselves to only exploiting functionality available in the fixed standard.
An upstream project might maintain two development paths -- one of them limited to the standard while the other is freer to evolve -- but even if they do, you are still left with versions that will not work with the standard and will not be able to run on the distros have chosen to support the standard. If a project were to limit itself to only the standardized functionality, it would soon be forked by developers who wish to exploit new features available in version X+1 of library Y.
It is the nature of the beast.
Roy Schestowitz
2008-10-26 14:14:42
Yfrwlf
2008-10-26 21:33:19
With software, anything is possible, and if someone comes out with a great packaging system and a lot of programs start using it, I expect package managers to make themselves compatible with that standard. Right now there's DEB and RPM, and they are crappy standards only for the reason that they both are not being used in all or most of the existing package managers.
No, a good standard is one that can be easily adopted and is easy to use, just like ODF or HTML, and that can be implemented and made compatible with several programs. This is a project that can be completed, will be completed, and is being worked on now, look up Burgdorf Packaging API sometime.
Of course not all Linux software bundles have to come with a package manager that is compatible with a certain package format, I know that, you can do anything you want, you could make a distro that has a broken kernel and doesn't even boot, obviously. I'm talking about more modularity being needed so that what is *popular* will get adopted. The popular programs should be easy to install no matter what your default software bundle is, and it's VERY possible to make that happen from a technical viewpoint, so, fxxx the haters, Linux software accessibility and freedom for the win.
Yfrwlf
2008-10-26 21:53:32
As another example, it's like video codecs. Video codecs have different features, different efficiencies, some are faster, some are smaller, some are easier to adopt. All-in-all though, the summation of all those things gives you a rough idea of the overall pressure that developers might feel to adopt a specific codec in their video player program. So, OGG might be difficult to adopt, but because it has the benefits of being totally free and not encumbered by royalties or permissions or anything in any way, there's a big push for it, so the developers of a player like VLC or Totem or MPlayer may adopt it regardless if it's implementation difficulty.
Now, compare that to "application" packages and package managers, because it works in exactly the same way. It is completely technically possible to come up with a package format that contains all the required information so that the software can be installed in whatever way any particular package manager may want to install it. All you need is enough metadata there so that it can be successfully dealt with. Then, all you do is have the package managers that are the most common or whatnot adopt the standard i.e. be compatible with it, so the users of those managers can use the new friggin' format. You can have more formats come about. Standardization /= taking away choice. Standardization does not equal forcing users to use software X, Y, and Z. Standardization means a point of communication that allows programs to interoperate, and there's *nothing* wrong with that, it gives users MORE choice. Do you think ODF is taking away your freedom? Are you forced to use it? No, there are several document formats you can choose to use, but ODF is one of the more common ones because it's been widely adopted for various technical and political reasons and such, so it's a good choice for if you want freedom.
That's all that's needed, is for the RPM managers to make themselves compatible with DEBs, and for DEB managers to make themselves compatible with RPMs, and if that can't be done then update the god damn standard so it can or come out with at least one new format that both managers CAN use, so that Linux users can finally have easy access to software, and so developers can release one binary package and be done with it instead of worrying about supporting a billion "distros", and so Linux can be a single, targetable platform. It's NOT impossible, but the answer does NOT mean force and taking away freedom is required, it's nothing that cannot be overcome by technical prowess.
OpenOffice did not get to where it is today because it forced users to use it. I'm talking about more choice being needed and given to Linux through the creation of better communication tools.
Yfrwlf
2008-10-26 22:16:58
Software accessibility, quite simply, is a feature. It's a feature that users want. The "distros" that adopt such a feature will be more popular. Or, since a "distro" = package manager basically, whatever package manager makes itself compatible with some good package standards efforts or whatnot, and embraces that push for accessibility, that's the package manager I will use, because I do find it a great feature and I know others who do. For some reason normal computer users don't really care about compiling software. I dunno why, they must be crazy!
Oh and to Roy: I didn't say it was hate without a reason, but OK, call it a dislike then. Regardless of whatever you call it, I don't like their business practices either.
saulgoode
2008-10-26 22:45:41
It is not possible to freeze an API and still be able enhance it. It is self contradictory. It can't be done. No way. No how.
I expect some package managers will do just that -- but others will be around packaging the latest GIMP, which depends on the latest GTK, which depends on the latest Cairo, which depends on the latest X11. And X11 developers will continue to enhance X11, and Cairo developers will employ those enhancements to improve Cairo, and GTK developers will avail themselves of those improvements to make GTK more functional, and GIMP developers will make use of that increased functionality to enhance GIMP.
It is not about what package manager is used, it is about what libraries and dependencies are available. Feel free to decree that version X.Y is the officially sanctioned Z library of the town of Burgdorf if you want. There are certainly benefits to be accrued from such standardization and there will certainly be some who will wish to avail themselves of those benefits (particularly ISVs not interested in developing Free Software).
Create your standard and make it available. If it is a better approach, it will be adopted. However, you can not dictate that everyone follow your standard and there will certainly be those who would rather exploit the continually evolving improvements available in the latest versions.
And for what it's worth, I don't think things "suck" at all -- unless of course you are a proprietary ISV not interested in developing Free Software, in which case: too bad for you (I am not responsible for the failures of your chosen business model).
Roy Schestowitz
2008-10-26 23:01:30
The DEB-RPM problem is partially resolved by Alien. Repos also serve as a solution to this old dilemma. Debian 5.0 will come as one Blu-Ray Disc with all the software. Heaps of it.
Yfrwlf
2008-10-27 19:11:02
saulgoode: We seem to be on different pages as what we mean by "standardization". Yes, an API can be extended with every new release, it's called being forwards compatible I do believe is the term. The software itself can be improved while remaining function with the given API calls, that's not harmful at all unless there's a bug in it. You want to add a new feature? You add it and add the call for it. The API is just the common *language* between programs, so you don't need to change it much.
If and when there is ever a point at which you want to completely change that language for some reason, you simply call it 2.0 or whatever you wanna call it, and, who cares? That's why there's such a thing as *dependencies*. If a program has to have the features of 2.0 because it uses them, then that's fine, they can install it, and even if 2.0 was not backwards compatible with 1.0, if some programs had to have 1.0 to work because 2.0 no longer supported certain 1.0 things for whatever reason, then the answer is simple, both need to be installed at the same time. In most cases though the newer version of stuff will support older versions too though, so you just need to do an upgrade, and that's no problem. If a program ever wants to use some new feature of a library, that's perfectly fine, mark your program as being dependent on it and they can upgrade, and it will all be automatic because it's a *package* and not a standalone binary. You can get updates directly from the developers, too, if you want, instead of some distro's repository which should just be mirroring the developer's releases any way.
Any way, API changes don't matter and this is a stupid topic, because even if you do require that program Z requires library Y, and every single release of library Y is a completely new system with a new API so you end up having several different versions of this library installed on your computer, that's OK, and that's the fault of the library maintainers. It should still *be possible* though. Then, once new versions of the programs that are using the rigid libraries come out, you can upgrade, and one of those library versions may then no longer be needed.
It's all very possible, without using force but freedom, to make things better with package management in Linux. Integrate Alien into RPM and DEB managers for all I care, but make the Linux software universe modular so users can have easy access.
And yes, things do suck when a normal user can't install some Linux program because they don't know what the hell to do with source code and they've never used a terminal before. The sooner more devs get their heads out of their asses and see that and feel sorry for them and want to do something about it, the better, and if you yourself are living in denial of this problem, you should try talking to normal non-geek computer users sometime about their so-called "third-party software" installation experiences. Oh wait, you probably don't care any way.
Any solution to this mess is better than nothing and will be seen as a feature, but it comes down to either creating at least one new standard or adopting the existing RPM or DEB ones into at least the most popular package managers. That's it.
...and don't use the crap about proprietary ISVs on me, being able to release one package that will function on all distros is a benefit for ALL developers, both closed source and open source, and it has nothing to do with the problem, but of course it will help them too and I will be glad for both. Linux being used for some proprietary programs? Good, Linux adoption will continue to grow faster and that means more Linux programs in general both closed and open. Proprietary games? Awesome. Adoption will grow even faster, and again it'll mean even more Linux programs because it will be even more targeted. It's the snowball effect, and it benefits from *everything* it sticks to. Will that mean open source games and other programs will die off? If that's what you think, you're insane. OSS titles will continue to come about, and will all get better and better. For instance, as the open source (and uncontrolled) tools for creating games get better, there will be more and more community-created games around and thus even more open source games around. But any way this topic has nothing to do with closed source vs. open source, it has to do with installing Linux software regardless of the attached licenses.
Yfrwlf
2008-10-27 20:53:52
Even if it weren't though, you *can* update one or the other formats to make them so they can be adopted, or you could make an entirely new format.
So, what's there to discuss? It's a feature that needs to be implemented, period. Sheesh, since when did asking for a better OS and more features become a sin.
Roy Schestowitz
2008-10-27 20:56:14
Yfrwlf
2008-10-28 22:52:35
God this problem is so crazy though, I have two friends who are new with Linux and trying to move to it and both have run into major glitches because of this exact problem and it's really frustrating for new users. One of them screwed his X.org up because he tried installing the Nvidia drivers from their website and just like with installing any driver outside the repository, it's going to break after you do a kernel update, because kernel modules aren't *truly modular* yet as in they can't be transferred between kernel versions like they should be if they just used some kind of god damn standard API for certain things.
Any way, the other one had problems because he was on 64-bit Linux and didn't have the 32-bit libraries installed so he could run a 32-bit program. Because the program wasn't a *package* and was just a straight binary, the only thing it could do was guess at what packages he might need to install for 32-bit compatibility, which is a lot better than most programs would normally do. Where as if it was a package, it would have known what dependencies he needed to install, and could have directly helped him or did it for him itself. Now, he's just switching back to 32-bit because of it.
So, having at least one packaging standard that was adopted by all the existing managers would mean an end to these problems, and Linux users being truly free to install whatever they want. A new version of Gnome came out? Great, I'll just download the package and upgrade, or better yet add the URL and upgrade. I only want one of the programs, not the whole thing? That's fine, I'll just install it then and the required libraries. Oh, the new libraries aren't compatible with the programs that were using the older libraries? Well, that sucks, and the library maintainers should really think about stabilizing their API more for forwards-compatibility so they can still add new features but won't require a new version for every different program that uses it, but that's OK because I can have BOTH libraries installed side by side!
Brilliant!
....is the way things should be, so I wish the LSB and other projects luck at bridging the gap between "distros" and making all Linux software be Linux software and giving Linux users much more freedom to run the software they choose to.