Seth Vidal's thoughts on the future of Fedora

[Jman]

I was reading the Fedora People blog collection (http://fedora.dulug.duke.edu/people/) and I came across Seth Vidal's (http://www.advogato.org/person/skvidal/) thoughts on the future of the Fedora community (http://blog.sethdot.org/index.cgi/172). (Seth is a developer of the yum package updater tool.)

He covered a couple key points: two way communication between Red Hat employees and the Fedora community and better package management and mirroring. He also wants to see an easy backup tool.

I'm with him on all of these points. Communication and less complicated package management are key to success in the Fedora community.

[Shadow Skill]

I agree with him as well although I don't quite understand everything he is talking about. I hope they get around to making rpm intelligent enough to recognize when things required by the rpm package have already been installed via tarball, perhaps a type of system wide indexing system which can be set up to run at a given time or called explicitly by the user. [so that the system resources are not wasted by the indexer ala windows.]

[foolish]

I agree with him as well although I don't quite understand everything he is talking about. I hope they get around to making rpm intelligent enough to recognize when things required by the rpm package have already been installed via tarball, perhaps a type of system wide indexing system which can be set up to run at a given time or called explicitly by the user. [so that the system resources are not wasted by the indexer ala windows.]

This won't happen, nor is it what we need. We need everything everyone needs available as a package through yum. We also need to spread the word about src.rpms as the only good way to build something from source in a rpm based system. If you need to change some options, get a src.rpm (as stated above, in this utopia of an operating system, everything is available as rpm, and as such, src.rpm as well.) and rebuild it using the options you want. Maybe this can be automated with something similar to yum (yum-src?)

[Wiplala7]

As mentioned in Seth Vidals thoughts

For a Graphical Back-up system,someone might think of BOBS

http://bobs.sourceforge.net/

[Ug]

Red Hat employees to even speak to us once in a blue moon would be nice.

[radu5er]

Red Hat employees to even speak to us once in a blue moon would be nice.


I completely agree but I thought (and please correct me if I'm wrong) that the whole idea behind fedora was to sort of use it as a platform for ironing out the problems with RHEL. If true, then it's not much of a surprise that Red Hat employees are not too concerned with the issues in the fedora project(s). They will just reap the rewards of the hard work of the community and our benefit is a great operating system at virtually no cost.

[jcstille]

Well they want to be more involved, and I think have to be. Otherwise the project will fail. Everyone sees that. So I think RedHat is ironing out exactly how this fits into their business model and creating a strategy. Or so we can only hope.

[Jman]

How I understand it Fedora is not meant to be the test of Red Hat Enterprise Linux, but an independent project led by Red Hat. RHEL is based off of Fedora, but with added value like support. It is somewhat like the relationship between the Wine Windows compatability layer and the CrossOver Office commercial product. A company sponsors the open source project but sells a seperate product with added value.

Communication the other way is also necessary. How do Fedora users get their input all the way to the Fedora committees that decide things? That's unclear now.

What I want to see is a fully unified package manager. Something like apt's synaptic with the categories of system-config-packages.

[Finalzone]

Speaking about Red Hat employees, I am impressed by their explanation about Fedora system. One of them explain how udev works. I was impressed by udev as it instantly detects all partitions including vfat. Unfortunately, that feature is disabled due to a bug so user have to manually mount vfat/ntfs partition. Seen that potential, I am now convinced that my decision to choose Fedora as linux distro was a good one.

[Shadow Skill]

This won't happen, nor is it what we need. We need everything everyone needs available as a package through yum. We also need to spread the word about src.rpms as the only good way to build something from source in a rpm based system. If you need to change some options, get a src.rpm (as stated above, in this utopia of an operating system, everything is available as rpm, and as such, src.rpm as well.) and rebuild it using the options you want. Maybe this can be automated with something similar to yum (yum-src?)When I have suggested similliar you have resisted yet slap the title of rpm on it and it becomes utopia or rather what we need....We all need to face the fact that source tarballs will probably always exist [I don't mind this at all, it is the reliance on the CLI that is the problem here not the tarballs.] as a facet of Linux. we need to have some way of ensuring that regardless of the method chosen to install software any and all rpm's will be able to locate dependencies THAT is utopia; the major programs mplayer, firefox, mozilla, the core type applications such as window managers should definetly be rpms but not every developer is going to have the time or the proper distrobution in some cases to build an rpm for our use. The structure of Linux itself at this point does not allow for rpm or any other package management type to become the sole packagemanagement type. [If Linux does become more centralized along the lines of the OS X community my point will become moot, but I doubt it will ever happen; there is too much resistance from the community.] We need a realistic way to handle dephell at this point and the current state of rpm and possibly other package management types is that it only answers part of the issue.

I am awaiting the glorious time when the great seven headed dragon known as Dephell will be slain and we can finally begin really putting [hopefully our beloved Fedora Core] Linux into the mainstream.

[foolish]

Dependency hell was solved by debian linux years ago. How? By having a good system for installing packages, and by having almost everything available as a package. This is the way we want to go. Building from source is for developers. Users don't know what source code is, they don't want to build anything. Try explaining ./configure make & make install to your mother and you'll understand why building from source has to go.

[Shadow Skill]

We know it has to go but it won't that would require far too much unity on the part of the Linux community which just isn't going to happen, the CLI elite will never allow that to happen, lets not forget how those people don't posses common sense either. You can't tell me that Dephell has been solved when I am staring at such an issue at this moment and have to hunt down a kernel-module-devel package. Let's also not fall into the trap that using source code is only for developers the actual commands to install source tarballs are no more difficult than those we use to install rpm's manually. Sure it will take time to learn but it shouldn't be overly difficult to explain that to my parents for example. [I just need to get around to forcibly migrating them to Linux.] Let's also not forget that if we are going to pull of what you want (I agree with it I just don't see it as practical at this point.) we really ought to ensure that rpm is absolutely distrobution transparent.

[Jman]

Perhaps empty dummy rpm packages can be inserted into the rpm database when a source package is installed. But that would create about as much work as actually building the silly rpm.

Autopackage (http://autopackage.org/) is supposed to be disto neutral.

[crackers]

Sure it will take time to learn but it shouldn't be overly difficult to explain that to my parents for example. [I just need to get around to forcibly migrating them to Linux.]
"Forcibly" - dude, if you think you have issues now... Note there is no smiley here. That is a, frankly, short-sighted and incredibly rude and arrogant approach. It will not be taken kindly, nor will it make your parents any better disposed towards Linux.

we really ought to ensure that rpm is absolutely distrobution transparent.
That ain't gonna happen in some time, if at all. The reasons that a lot of packages don't make it to RPM stages:

1) It's too new (RPMs in the repositories and on the CDs go through a testing process)
2) There's a more established, mature program that does the same thing that has been through the packaging and testing process
3) Distributions and repositories respond to "market pressure" - the more "popular" a given package is, the more likely it will continue to be available.

Just because you don't like the way program X does it's widgets doesn't mean that it should be included - because of the latter two items above, you're probably in the minority.

[Ned]

OK, here's my thoughts:

Well they want to be more involved, and I think have to be. Otherwise the project will fail. Everyone sees that. So I think RedHat is ironing out exactly how this fits into their business model and creating a strategy. Or so we can only hope.

I don't think Fedora will fail, simply because of the competition. Look at the big three - Fedora, Mandrake and Suse. Most home users/enthusiasts want a freely available Linux for download, so that rules out Suse for a lot of users. I've not personally tried Mandrake and besides that the alternatives start getting more specialised and less mainstream. There will always be good user support of a freely available mainstream product with a good community to support it.

Package management - we all know what the problems are and what's required to make the situation better. Two other things I'd really like to see is a proper Fedora Extras repository containing all the stuff they won't include for legal reasons like Acrobat, MPlayer, all the multimedia plugins etc in rpm format that are easy to install and work. Oh, and RPMs for 3D graphics drivers that work.

But I must admit I do feel a bit too much like a beta tester for Red Hat. I think FC1 was the most stable bug free distro I've ever used. Six months ago I was really looking forward to the release of core 2. This time around, I wont be in quite so much of a hurry to install core 3.

Ned

[Shadow Skill]

Short-sighted I don't think, so I don't feel like worrying about my parent's two machines.....I also don't have the energy to battle networking across the two OS's. I am also not in the business of expousing the virtues of Linux to my parents, I am in the bussines of making my life as easy as possible. I am also interested in seeing how such a migration might work out, and they happen to be my only available test subjects... :D My brother is almost as knowledgeable as me so he wouldn't make a good test subject.. [He could get the hang of the system without too much trouble.]

[Prometheus]

We had a thread like this a while back, and Foolish brought up something i think could and should be done... create one mega program for installing software. Launch the program, click on the tab you want (for example, drivers tab or games tab or multimedia tab) select the software you want, click the "install" button, and voila! The mega program installs the program and resolves dependencies.

Utopian? Probably. Too far fetched to be atainable? I think not. The one thing, however, that is missing that would make this a possibility is just the organization and legal aspects. At this point, there are various repositories, which are good in some cases, but just annoying in others. Also, like Ned said, it would be great to have a repository with software that for legal issues isnt by default included (and has working GFX drivers).

To my mind, this doesnt seem that far off, nor that incredibly difficult to do. It just needs a jump start in the correct direction....