It's time to bite the bullet.
There will be no more releases of Fedora Core or Fedora Extras.
Wait! Where are you going? Come back!
I'm serious. We've talked all along about how there should be no differences in how packages are treated whether they are in Core, or they are in Extras; no differences depending on who maintains the package. The best solution to this?
Eliminate the distinction between Core and Extras entirely.
Starting with Fedora 7, there is no more Core, and no more Extras; there is only Fedora. One single repository, built in the community on open source tools, assembled into whatever spins the Fedora community desires.
Are we there yet right now? No. There's a lot of work to be done, and we're looking for help. What's left of the Core Steering Committee is going to work with the Fedora Board and FESCO to figure out just how this new combined repository is going to be governed and managed.
In the meantime, just because we're not going to have a release of Core or Extras doesn't mean we're not going to have a release.
Hence, Fedora 7. Name TBD, but probably not 'Bride of Zod'.
http://fedoraproject.org/wiki/Releases/7
The current schedule is:
23 January 2007 | F7 Test1 development freeze 30 January 2007 | F7 Test1 Release
20 February 2007 | F7 FEATURE Freeze | F7 string freeze | F7 Test2 development freeze 27 February 2007 | F7 Test2 release
19 March 2007 | F7 translation freeze | F7 Test3 development freeze
26 March 2007 | F7 Test3 release
... Continual freeze. Only critical bugs fixed ... 5 April 2007 | Final devel freeze.
26 April 2007 | F7 General Availability
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
- Modify the build system to support this new paradigm - Merge Core and Extras in source control - Use the new pungi tool to spin all releases - A Fedora Desktop spin - A Fedora Server spin - A Fedora KDE spin - Make LiveCDs as a part of the distribution release process - Ability to customize non-packaging distrubution parameters - Switch to libata drivers for PATA support - Speedup of bootup and shutdown - Make wireless rock-solid - Add wireless firmware for all the chipsets we can - CodecBuddy - Fixing the proliferation of dictionary packages - Support encrypted filesystems - Fast user switching in the desktop - Fix the firewire stack - Switch to a tickless kernel by default - Fix unnecessary wakeups across the distribution - Add KVM virtualization support to our tools - Investigate (but probably don't switch to) new init technologies - Add the nouveau drivers for nVidia cards - Speed up Yum and RPM - Add support for RandR 1.2 - Switch to syslog-ng - Make the update system useable by all
More information on each of these features is available on the wiki, including responsible people and plans. If you'd like to chip in on these features, please, do!
If you've got new features you'd like to add, and you are willing to do the work, or have the ability to get others to do the work for you, we can add them too. Note that Test2 is the feature freeze.
Here's to making Fedora 7 the best release yet!
Bill
Good evening,
On Thu, 04 Jan 2007, Bill Nottingham wrote:
There will be no more releases of Fedora Core or Fedora Extras.
Sounds nice, even I'm curious whether this can be realized until April. And What will be the release tagging of the new "Fedora 7"? Won't there be no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with rpmvercmp. We could take this as reason to rename Fedora again ;-)
Wait! Where are you going? Come back!
Nope, why to drive Fedora's highway to hell? Just kidding. For Fedora 7 we absolutely should fix the bugs #132925, #152435, #192854, #220265, #193475, #206697, #212780 as they're longer open but unfortunately silent moved from one Fedora release to another and most of them are tagged EasyFix, too.
- Add wireless firmware for all the chipsets we can
It doesn't match really, but can we please also get rid of bug #212890 for Fedora 7, as this problem is related.
- Investigate (but probably don't switch to) new init technologies
- Switch to syslog-ng
Aren't these two not the same and don't they conflict each other? Or did I understand something wrong?
- Speed up Yum and RPM
Does this mean, we get the new magic RPM until April with the new community as proposed by Max some time ago? Or do we really want ship the old and nearly antiquaric and heavily patched RPM 4.4.2 for another Fedora release? Hopefully not.
So far, so good. Anyway you all hopefully slipped very well into 2007.
Greetings, Robert
On Thu, 2007-01-04 at 21:56 +0100, Robert Scheck wrote:
- Investigate (but probably don't switch to) new init technologies
- Switch to syslog-ng
Aren't these two not the same and don't they conflict each other? Or did I understand something wrong?
No. Init is init. syslog-ng is syslog. One serves as the init process for the box, the other the logger.
josh
Robert Scheck wrote:
Sounds nice, even I'm curious whether this can be realized until April. And What will be the release tagging of the new "Fedora 7"? Won't there be no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with rpmvercmp. We could take this as reason to rename Fedora again ;-)
The %dist tag could be expanded to something like ".fedora7" instead (which is greater than ".fc6" according to rpmvercmp.
- Investigate (but probably don't switch to) new init technologies
- Switch to syslog-ng
Aren't these two not the same and don't they conflict each other? Or did I understand something wrong?
syslog-ng is (may become) the new system logging daemon, to replace syslogd as-is. The new init technologies referred to are ideas like InitNG or similar that work with or replace the older SysVinit stuff to help increase the boot time and efficiency by doing things such as preloading, asynchronous startups where possible, potential D-Bus integration, etc. They are not the same thing. :]
So far, so good. Anyway you all hopefully slipped very well into 2007.
Agreed. Go go go Fedora! WOO! :D
On Thu, Jan 04, 2007 at 01:15:17PM -0800, Peter Gordon wrote:
The %dist tag could be expanded to something like ".fedora7" instead (which is greater than ".fc6" according to rpmvercmp.
I don't think we need every filename and package nevr to be 5 characters longer....
Peter Gordon wrote:
Robert Scheck wrote:
Sounds nice, even I'm curious whether this can be realized until April. And What will be the release tagging of the new "Fedora 7"? Won't there be no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with rpmvercmp. We could take this as reason to rename Fedora again ;-)
The %dist tag could be expanded to something like ".fedora7" instead (which is greater than ".fc6" according to rpmvercmp.
.fc7 could refer to "Fedora Collection 7".
Then .fcX would be more meaningful than .fc6 currently in Extras packages too.
Warren Togami wtogami@redhat.com
Warren Togami wtogami@redhat.com writes:
.fc7 could refer to "Fedora Collection 7".
+1 ... "f7" sounds way too much like the sort of tornado you don't want to encounter.
regards, tom lane
Le Ven 5 janvier 2007 03:41, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
What happened to the firefox3/xulruner plans ?
Utterly dependent on upstream. I suppose it's worth checking on.
This should be clarified ASAP. There are several problems¹ with the current firefox2 packaging in devel, and I know people refrained from commenting on it because it was announced as a transitionnal firefox3 placeholder.
We need to know what version of the main distro browser needs to be beaten into shape.
¹ UI localization, pango ligature bug...
Le vendredi 05 janvier 2007 à 14:05 -0500, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
We need to know what version of the main distro browser needs to be beaten into shape.
Judging by the published schedules, both XULRuner and FF3 aren't going to make it for F7.
Ok, time to do some bugzilla-ing I guess
Once upon a time, Robert Scheck fedora-devel-list.listman@linuxnetz.de said:
Sounds nice, even I'm curious whether this can be realized until April. And What will be the release tagging of the new "Fedora 7"? Won't there be no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with rpmvercmp. We could take this as reason to rename Fedora again ;-)
There was the thought at one point that there may be other Fedora OSes than Linux (the FTP directory structure is fedora/linux/{core,extras}), so the next release could be called "Fedora Linux 7" and use "fl7" for short.
Robert Scheck scripst:
one Fedora release to another and most of them are tagged EasyFix, too.
To make it slightly more concise. Take a look at http://preview.tinyurl.com/vj9j6 -- I am afraid 49 unclosed EasyFixes is still 49 too many.
Matěj
On Friday 05 January 2007 08:00, Matej Cepl wrote:
To make it slightly more concise. Take a look at http://preview.tinyurl.com/vj9j6 -- I am afraid 49 unclosed EasyFixes is still 49 too many.
Why are you including RHN and RHEL bugs in this? What do these have to do with Fedora?
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
30 January 2007 | F7 Test1 Release
Just in time for FUDCon!
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
It's time to bite the bullet.
There will be no more releases of Fedora Core or Fedora Extras.
Wait! Where are you going? Come back!
...
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
So "Fedora Desktop" means "Fedora Gnome desktop" ?
- Make LiveCDs as a part of the distribution release process
Cool ! Is this installable like "Ubuntu livecd" ?
- Add the nouveau drivers for nVidia cards
"nouveau" ? :-)
- Speed up Yum and RPM
Yeah, nice
Thank you,
On Thu, 2007-01-04 at 22:08 +0100, Vnpenguin wrote:
So "Fedora Desktop" means "Fedora Gnome desktop" ?
Correct (we're a GNOME centric distribution).
- Make LiveCDs as a part of the distribution release process
Cool ! Is this installable like "Ubuntu livecd" ?
That's the plan.
David
On Thu, Jan 04, 2007 at 04:10:26PM -0500, David Zeuthen wrote:
- Make LiveCDs as a part of the distribution release process
Cool ! Is this installable like "Ubuntu livecd" ?
Installable? As in the unpacked tree on the CD will be copied to the hard disk, keeping the RPM database updated correctly? Sounds neat--it may be faster to install that way rather than installing RPMs the normal way. The trick would be getting upgrades to work that way too :-)
On Thu, 2007-01-04 at 18:10 -0500, Chuck Anderson wrote:
Installable? As in the unpacked tree on the CD will be copied to the hard disk, keeping the RPM database updated correctly? Sounds neat--it may be faster to install that way rather than installing RPMs the normal way. The trick would be getting upgrades to work that way too :-)
Yes, it's much much much faster; we simply do "dd if=os.img of=/dev/sda2" [1] and once that is done we "e2resizefs /dev/sda2" and finally we configure the system. If you run the live CD from RAM then the install time takes 3-4 minutes (on a 2GHz system with 1GB RAM). If not running the live CD from RAM then it's around 7-8 minutes.
Some time next week I'll post an RPM (to fedora-livecd-list) that you can install onto the FC6 live CD (remember it got a rw rootfs) so testing can commence. The installer is text based right now but writing a small GTK+ app for this is relatively easy.
David
[1] : where os.img stems from the live cd and is the ext3 fs.. and /dev/sda2 is the target partition
On 1/5/07, David Zeuthen david@fubar.dk wrote:
Yes, it's much much much faster; we simply do "dd if=os.img of=/dev/sda2" [1] and once that is done we "e2resizefs /dev/sda2" and finally we configure the system. If you run the live CD from RAM then the install time takes 3-4 minutes (on a 2GHz system with 1GB RAM). If not running the live CD from RAM then it's around 7-8 minutes.
Some time next week I'll post an RPM (to fedora-livecd-list) that you can install onto the FC6 live CD (remember it got a rw rootfs) so testing can commence. The installer is text based right now but writing a small GTK+ app for this is relatively easy.
David
[1] : where os.img stems from the live cd and is the ext3 fs.. and /dev/sda2 is the target partition
Thank you, David! I'm waiting impatiently for your package :)
Cheers,
Chuck Anderson (cra@WPI.EDU) said:
Installable? As in the unpacked tree on the CD will be copied to the hard disk, keeping the RPM database updated correctly?
Yes, that's the plan.
Sounds neat--it may be faster to install that way rather than installing RPMs the normal way. The trick would be getting upgrades to work that way too :-)
Hahahahaha... no.
Bill
On Thursday 04 January 2007 16:08, Vnpenguin wrote:
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
So "Fedora Desktop" means "Fedora Gnome desktop" ?
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely used "community contributed" spin of Fedora. That's why (IMHO) its named specifically with "KDE" whereas the official spin is just "Desktop". If you don't know what "KDE" or "GNOME" is, you wouldn't know to choose it. Desktop is a good generic name that is understandable. However if you already know and prefer KDE, you know to get the KDE spin.
On 1/4/07, Jesse Keating jkeating@redhat.com wrote:
On Thursday 04 January 2007 16:08, Vnpenguin wrote:
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
So "Fedora Desktop" means "Fedora Gnome desktop" ?
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely used "community contributed" spin of Fedora. That's why (IMHO) its named specifically with "KDE" whereas the official spin is just "Desktop". If you don't know what "KDE" or "GNOME" is, you wouldn't know to choose it. Desktop is a good generic name that is understandable. However if you already know and prefer KDE, you know to get the KDE spin.
Thank you, I use Gnome (and GTK apps) since RH 5.0 and I don't want to change it :)
Cheers,
On Thu, Jan 04, 2007 at 04:13:50PM -0500, Jesse Keating wrote:
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora
Are these for media only?
In other words, will there be Fedora Desktop/Server ISOs and corresponding separate network installers? Or will there be separate ISOs, but just one set of network install loaders and images, able to install either (or any other spin, for that matter)?
None of the above is obvious from a rapid glance at the wiki.
On Thursday 04 January 2007 16:20, Rudi Chiarito wrote:
Are these for media only?
In other words, will there be Fedora Desktop/Server ISOs and corresponding separate network installers? Or will there be separate ISOs, but just one set of network install loaders and images, able to install either (or any other spin, for that matter)?
None of the above is obvious from a rapid glance at the wiki.
We're still fleshing out the details. One idea is that the customized spins will be iso only, the exploaded tree will have everything in it. Any customized spin will have the ability to enable the full repo during the install and gain access to all the software there, likewise minimal boot or rescue isos could be used to install from the large repo as well.
The custom spin isos would include the images and such to be able to do network installs, and the iso itself could be used over the network (nfs).
On 1/4/07, Jesse Keating jkeating@redhat.com wrote:
We're still fleshing out the details. One idea is that the customized spins will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
-- Jesse Keating Release Engineer: Fedora
Regards, Fabio
On Thu, Jan 04, 2007 at 04:56:43PM -0500, Fabio Comolli wrote:
We're still fleshing out the details. One idea is that the customized spins will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
Okay.
But probably the official Fedora mirrors don't want to carry it.
Matthew Miller (mattdm@mattdm.org) said:
On Thu, Jan 04, 2007 at 04:56:43PM -0500, Fabio Comolli wrote:
We're still fleshing out the details. One idea is that the customized spins will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
Okay.
But probably the official Fedora mirrors don't want to carry it.
It's entirely possible such a thing would be Bittorrent-only.
Bill
On Thursday 04 January 2007 16:56, Fabio Comolli wrote:
So what about an 8GB DVD image with everything in it?
Feel free to burn it, I'm not about to ask that the mirrors carry around an extra 8G per arch iso that just duplicates all the packages already on the file system, and would be used by a very very small percentage of the userbase.
On 1/4/07, Jesse Keating jkeating@redhat.com wrote:
On Thursday 04 January 2007 16:56, Fabio Comolli wrote:
So what about an 8GB DVD image with everything in it?
Feel free to burn it, I'm not about to ask that the mirrors carry around an extra 8G per arch iso that just duplicates all the packages already on the file system, and would be used by a very very small percentage of the userbase.
I wasn't thinking of an "extra" 8GB: I was thinking of small ISOs for people who use network boot and only an 8GB ISO for the distribution.
In this way you won't have to carry an ISO for "Fedora Desktop", another on for "Fedora Server", "Fedora KDE" and so on.
Maybe in 8GB you can put both the i386 and x86-64 images, like Solaris10 does for example.
However, it's just my 2¢ :-)
Fabio
-- Jesse Keating Release Engineer: Fedora
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thursday 04 January 2007 17:20, Fabio Comolli wrote:
I wasn't thinking of an "extra" 8GB: I was thinking of small ISOs for people who use network boot and only an 8GB ISO for the distribution.
In this way you won't have to carry an ISO for "Fedora Desktop", another on for "Fedora Server", "Fedora KDE" and so on.
Maybe in 8GB you can put both the i386 and x86-64 images, like Solaris10 does for example.
However, it's just my 2¢ :-)
The targetted spins were for iso download, so you could carry it with you or not have to hit the network for every package. Otherwise what would be the point, you'd just select that group from the installer.
On Thu, Jan 04, 2007 at 05:05:13PM -0500, Jesse Keating wrote:
On Thursday 04 January 2007 16:56, Fabio Comolli wrote:
So what about an 8GB DVD image with everything in it?
Feel free to burn it, I'm not about to ask that the mirrors carry around an extra 8G per arch iso that just duplicates all the packages already on the file system, and would be used by a very very small percentage of the userbase.
Well, we could use jigdo and just distribute template files for those who wish to assemble the full 8G iso.
Or a 4g dvd image with server and desktop combined (a sort of equivilant to core now)
Peter
On 1/4/07, Fabio Comolli fabio.comolli@gmail.com wrote:
On 1/4/07, Jesse Keating jkeating@redhat.com wrote:
We're still fleshing out the details. One idea is that the customized
spins
will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
-- Jesse Keating Release Engineer: Fedora
Regards, Fabio
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Em Qui, 2007-01-04 às 16:56 -0500, Fabio Comolli escreveu:
So what about an 8GB DVD image with everything in it?
SUSE uses standard 4GB DVD with an extra repository on-line, but if you buy their boxed version you can choose between 2 4G DVD set or 1 8GB DVD. Mandriva also have a multi 4GB DVD release (IIRC, 2 DVD), but not an 8GB DVD.
You just need to remember that in some countries (like Brazil, for instance) it's really difficult (almost impossible) to find 8GB medias (and if you find, they are *very* expensive). So if the distro vendor doesn't provide it, you would be excluding a lot of users.
On 1/4/07, Mauricio Teixeira (netmask) netmask@webset.net wrote:
Em Qui, 2007-01-04 às 16:56 -0500, Fabio Comolli escreveu: You just need to remember that in some countries (like Brazil, for instance) it's really difficult (almost impossible) to find 8GB medias (and if you find, they are *very* expensive). So if the distro vendor doesn't provide it, you would be excluding a lot of users.
Honestly I think proper documentation or a script on how to build a DVD would be more than sufficient.
-Mike
Em Qui, 2007-01-04 às 16:48 -0500, Jesse Keating escreveu:
We're still fleshing out the details. One idea is that the customized spins will be iso only, the exploaded tree will have everything in it. Any
If that's the case, why not just having well designed patterns/groups/selections/whatever so that the user can choose between either one during install?
For that matter it would be needed to have a well defined 'base system' and build the 'install types' on it, but I personally don't see the need for a spin.
Just MHO.
Jesse Keating wrote:
We're still fleshing out the details. One idea is that the customized spins will be iso only, the exploaded tree will have everything in it. Any customized spin will have the ability to enable the full repo during the install and gain access to all the software there, likewise minimal boot or rescue isos could be used to install from the large repo as well.
Why not enable the entire repo by default in any install? Isn't that most logical?
Warren Togami wtogami@redhat.com
On Saturday 06 January 2007 02:43, Warren Togami wrote:
Why not enable the entire repo by default in any install? Isn't that most logical?
Because that assumes that every install has network capabilities, and that ever package in the entire repo comps would be marked as optional so that by default nothing would get downloaded. Those are pretty heavy requirements.
I'm pretty sure my idea of Destop/Workstation/Server is going to be substantially different from other people's, probably every time I build a box it'll change. So I hope it's just ISOs and the installed is generic and allows for package groups to be selected. The network installer right now is very flexible which is it's strength.
In other words, will there be Fedora Desktop/Server ISOs and corresponding separate network installers? Or will there be separate ISOs, but just one set of network install loaders and images, able to install either (or any other spin, for that matter)?
None of the above is obvious from a rapid glance at the wiki.
-- Rudi
Jesse Keating wrote:
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely used "community contributed" spin of Fedora. That's why (IMHO) its named specifically with "KDE" whereas the official spin is just "Desktop". If you don't know what "KDE" or "GNOME" is, you wouldn't know to choose it. Desktop is a good generic name that is understandable. However if you already know and prefer KDE, you know to get the KDE spin.
It would be consistent to have something like
Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
Rahul
On Thursday 04 January 2007 16:22, Rahul Sundaram wrote:
It would be consistent to have something like
Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
That's too many chars for a Volume ID, so it has to be a bit more terse. Perhaps the isos could be named that, but I don't want () in iso names.
We are discriminatory by nature. We choose what we want in our package collections, we choose what we want on our isos. Its no mystery that Fedora is a Gnome centric distribution, and it should be no surprise that the Fedora Desktop spin is Gnome based. What community folks choose to name their spins is of not much concern, so long as it makes sense for that spin and doesn't trample any trademarks. Should we go down the route of Fedora Desktop (GNOME/Firefox/evince/OpenOffice.org/gaim/compiz/emacs edition)?
Jesse Keating wrote:
On Thursday 04 January 2007 16:22, Rahul Sundaram wrote:
It would be consistent to have something like
Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
That's too many chars for a Volume ID, so it has to be a bit more terse. Perhaps the isos could be named that, but I don't want () in iso names.
The volume id can be different from the full name. Feel free to abbreviate it in the volume id and drop the braces in the ISO filename. I am just
We are discriminatory by nature. We choose what we want in our package collections, we choose what we want on our isos.
We dont need to be though. We can put every package in a DVD and make it available in a different directory for mirrors to sync if they want to or just make it a torrent only release. We have a sizable segment of users who need packages to be in the media due to unavailability of broadband connections and network access. It is not much of a burden for us to produce a DVD release with everything in it. Please do consider it.
Its no mystery that Fedora
is a Gnome centric distribution, and it should be no surprise that the Fedora Desktop spin is Gnome based.
After opening up development we have really no need to do so since the resources available to us has massively increased (more packagers, pungi, pilgrim etc). The whole point of us doing different spins to move off from this idea of being centric on some things.
What community folks choose to name their spins
is of not much concern, so long as it makes sense for that spin and doesn't trample any trademarks.
Good branding is very much a key concern. We are making major changes here and have a chance to change past impressions. Let's get it right this time.
Should we go down the route of Fedora Desktop
(GNOME/Firefox/evince/OpenOffice.org/gaim/compiz/emacs edition)?
No but a desktop environment is not at the same level as rest of the components here as clearly demonstrated by us planning to do two different spins based on just that. If you are going to call one of the spins Fedora KDE, it is no more confusing to call the other one Fedora GNOME. Seriously.
Rahul
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Its no mystery that Fedora is a Gnome centric distribution, and it JK> should be no surprise that the Fedora Desktop spin is Gnome based.
Umm, isn't the Fedora supposed to become the community's distribution, and so isn't it up to the community to decide whether Fedora is "anything"-centric?
I could care less about naming either way, but declaring up-front that regardless of what the community does or wants, Fedora is still going to favor any specific technology seems counterproductive in this new spirit of complete community involvement.
- J<
On Thursday 04 January 2007 17:19, Jason L Tibbitts III wrote:
I could care less about naming either way, but declaring up-front that regardless of what the community does or wants, Fedora is still going to favor any specific technology seems counterproductive in this new spirit of complete community involvement.
You're right, I think those writing software for Fedora and doing integration work for Fedora are the ones who will decide what centric Fedora is, and to this point, that's all been gnome/gtk, python, etc... Do you see that changing drastically anytime soon?
On Thursday 04 January 2007 16:23, Jesse Keating wrote:
On Thursday 04 January 2007 17:19, Jason L Tibbitts III wrote:
I could care less about naming either way, but declaring up-front that regardless of what the community does or wants, Fedora is still going to favor any specific technology seems counterproductive in this new spirit of complete community involvement.
You're right, I think those writing software for Fedora and doing integration work for Fedora are the ones who will decide what centric Fedora is, and to this point, that's all been gnome/gtk, python, etc... Do you see that changing drastically anytime soon?
Time to port everything to PyQT ;) i dont see it changing but i do see other things taking off.
On Thu, 2007-01-04 at 17:23 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 17:19, Jason L Tibbitts III wrote:
I could care less about naming either way, but declaring up-front that regardless of what the community does or wants, Fedora is still going to favor any specific technology seems counterproductive in this new spirit of complete community involvement.
You're right, I think those writing software for Fedora and doing integration work for Fedora are the ones who will decide what centric Fedora is, and to this point, that's all been gnome/gtk, python, etc... Do you see that changing drastically anytime soon?
We don't know. We haven't worked out anything yet. For example, merging the Core cabal and FESCo. To declare anything before more groundwork is completed is fairly pointless.
josh
Josh Boyer (jwboyer@jdub.homelinux.org) said:
You're right, I think those writing software for Fedora and doing integration work for Fedora are the ones who will decide what centric Fedora is, and to this point, that's all been gnome/gtk, python, etc... Do you see that changing drastically anytime soon?
We don't know. We haven't worked out anything yet. For example, merging the Core cabal and FESCo. To declare anything before more groundwork is completed is fairly pointless.
There is a large subset of the Fedora community that has already stepped up and is willing to do the work for a GNOME desktop spin. Ergo, it's getting done. I don't see how stating that is a problem.
Bill
On Thu, 2007-01-04 at 21:46 -0500, Bill Nottingham wrote:
Josh Boyer (jwboyer@jdub.homelinux.org) said:
You're right, I think those writing software for Fedora and doing integration work for Fedora are the ones who will decide what centric Fedora is, and to this point, that's all been gnome/gtk, python, etc... Do you see that changing drastically anytime soon?
We don't know. We haven't worked out anything yet. For example, merging the Core cabal and FESCo. To declare anything before more groundwork is completed is fairly pointless.
There is a large subset of the Fedora community that has already stepped up and is willing to do the work for a GNOME desktop spin. Ergo, it's getting done. I don't see how stating that is a problem.
Neither do I. This isn't about GNOME or KDE or WindowMaker or whatever.
My comment was more about "those writing software for Fedora and doing integration work for Fedora are the ones who will decide what centric Fedora is.." I believe I took that a bit out of context and rather than spiraling into a very long flame-war and embarrassing myself, I'll just end it now.
josh
On Thu, 2007-01-04 at 16:19 -0600, Jason L Tibbitts III wrote:
Umm, isn't the Fedora supposed to become the community's distribution, and so isn't it up to the community to decide whether Fedora is "anything"-centric?
Sorry for being direct, but it's a little bit delusional to think that just because Core + Extras is getting merged that it's now all community controlled. In other words, I expect Red Hat employees to still be the significant contributor for a long long time (would *love* to be proved wrong!) and at Red Hat we have, at least, 25 times as many people working on the GNOME than the KDE.
There's a reason most successful open source projects have benevolent dictators and it's not all a democracy. Thanks.
David
"DZ" == David Zeuthen david@fubar.dk writes:
DZ> Sorry for being direct, but it's a little bit delusional to think DZ> that just because Core + Extras is getting merged that it's now DZ> all community controlled.
Well, thanks for deflating the hype. So, according to you, the hype about the grand merge with the community is indeed just hype.
Look, either it's going to happen or people need to stop hyping it as if it is going to happen. Since both positions are coming out of Red Hat at the moment and those of us involved in community governance (i.e. us in FESCo) are still somewhat in the dark, it will be really nice to see the truth of the situation.
DZ> In other words, I expect Red Hat employees to still be the DZ> significant contributor for a long long time (would *love* to be DZ> proved wrong!) and at Red Hat we have, at least, 25 times as many DZ> people working on the GNOME than the KDE.
So? My comments weren't about gnome versus kde. I have no reason to expect other than that portions of the project which receive the greater number of developers from wherever in the community will make the most progress. My comments are about whether Red Hat plans to be just a part of the community, and your comments seem to answer than in the negative. Which is directly contradictory to what other folks from Red Hat have been saying.
DZ> There's a reason most successful open source projects have DZ> benevolent dictators and it's not all a democracy. Thanks.
This statement also contradicts statements from others at Red Hat. It would be really nice to know just what is actually going to happen.
- J<
On Thu, 2007-01-04 at 17:50 -0600, Jason L Tibbitts III wrote:
"DZ" == David Zeuthen david@fubar.dk writes:
DZ> Sorry for being direct, but it's a little bit delusional to think DZ> that just because Core + Extras is getting merged that it's now DZ> all community controlled.
Well, thanks for deflating the hype. So, according to you, the hype about the grand merge with the community is indeed just hype.
Don't be a drama queen, of course it's not hype. I'm just saying, for example, that many of the core desktop packages that I personally maintain will still be under my control and there will still be a desktop team at Red Hat where we decide on features for the next release and coordinate the maintenance of said packages.
And now with Core being opened up.. to me it means that everyone can apply patches but for my packages it still needs ACK / coordination from me. How is this different from Extras today and why on earth should it be different? Do you think the merge means that anyone can apply any patch to any package? That's really naive.
We have an open mailing list too for contributors, sadly it doesn't receive a lot of useful traffic. Maybe it's because we do our work upstream as we all should. For the record, we also have close relationship to many desktop community members for example Richard Hughes which is an active Fedora user.
(and in the paragraph above 'we' means people working on desktop packages and that's not restricted to RH employees though today it's mostly only RH employees. To tell you the truth not a lot of Fedora contributors have shown interest in the desktop apart from ranting about it.)
DZ> In other words, I expect Red Hat employees to still be the DZ> significant contributor for a long long time (would *love* to be DZ> proved wrong!) and at Red Hat we have, at least, 25 times as many DZ> people working on the GNOME than the KDE.
So? My comments weren't about gnome versus kde. I have no reason to expect other than that portions of the project which receive the greater number of developers from wherever in the community will make the most progress. My comments are about whether Red Hat plans to be just a part of the community, and your comments seem to answer than in the negative. Which is directly contradictory to what other folks from Red Hat have been saying.
DZ> There's a reason most successful open source projects have DZ> benevolent dictators and it's not all a democracy. Thanks.
This statement also contradicts statements from others at Red Hat. It would be really nice to know just what is actually going to happen.
You are implying I'm speaking for Red Hat which I'm clearly not. Don't do that. Thanks.
David
On 04 Jan 2007 17:50:50 -0600, Jason L Tibbitts III tibbs@math.uh.edu wrote:
DZ> There's a reason most successful open source projects have DZ> benevolent dictators and it's not all a democracy. Thanks.
This statement also contradicts statements from others at Red Hat. It would be really nice to know just what is actually going to happen.
I haven't seen anything, anywhere, to suggest this is going to be a democracy.
The merger is going to be more like opening federally owned land for homesteading. Basically everyone is going to rush out and stake some claims for fertile pieces of unclaimed packaging space. From those individual homesteaders packaging communities will be built, some fated to thrive, and some fated to be ghost towns in a couple of years. Did you know that homesteading was still going on in Alaska till the 1980's?
The brave new merged world, is going to be more collaborative, and certainly more supportive of community efforts which are not directly inline with Red Hat directed initiatives. But don't get the wrong idea, there will still be conflicts of interest, and at the end of the day groups of package owners working in teams will be setting the directions for that subgroup of packages and driving development forward in conjunction of the rest of the packaging space. For Gnome, the driver seat in the Fedora space is clearly filled by RedHat engineers so don't expect that to change. The merger makes it possible for new people to drive new initiatives in tangent with current ones. Just don't expect to claim jump existing homesteads, and forcibly change the direction.
But for other things, that RedHat doesn't have resources invested in, the merger will definitely matter. For example we all want to see the people who are interested in keeping KDE on Fedora sane have a chance to work on it without undue frustrations. Its no big secret that RedHat is not making an investment of engineering time into KDE, so continuing to have it chained up inside a RedHat internal buildsystem where none of the interested community members can get access to it blocks that. The merger of the infrastructure absolutely is forward progress towards fixing some of the problems with KDE in Fedora.
The real question is who is going to end up becoming the benevolent dictators of the KDE space and is there enough community manpower to keep KDE afloat. The merger provides the access, but there will absolutely have to be strong doers to drive the work, instead of just talkers. I certainly expect Rex to be involved because he has some momentum here with his community built packages for KDE. And I also expect people leading Fedora Unity to have a hand in the release engineering aspects of pooping out a KDE-centric installer image since they have already done livecd spins for KDE. Whomever the drivers of KDE packaging and installable media end up being inside the Fedora community, they will absolutely end up making decisions which piss off some KDE users. Conflicts of interest are inevitable, even for packaging drivers not sitting inside the RedHat fenceline.
-jef"The merger doesn't so much as change anything with regard to control of existing things. The merger provides access so the fedora project can better support new community initiatives with fedora project infrastructure."spaleta
Jason L Tibbitts III wrote:
So? My comments weren't about gnome versus kde. I have no reason to expect other than that portions of the project which receive the greater number of developers from wherever in the community will make the most progress. My comments are about whether Red Hat plans to be just a part of the community, and your comments seem to answer than in the negative. Which is directly contradictory to what other folks from Red Hat have been saying.
More broadly... Fedora is not a democracy.
Fedora is a meritocracy.
Those who have done good work and the respect of their peers gain greater credibility in the project. These people who have earned trust from others exist at varying levels within the organization help to make decisions.
Red Hat employees just happen to have many inputs into the Fedora Project as part of their regular jobs.
One issue however that I see with this, is historic lack of inter-communication between the RH Desktop team and the community. The recent explosion on fedora-art-list is a salient example of this kind of conflict. A perceived corporate "outsider" who had not attempted to participate in the community prior, appeared suddenly with a heavy-handed power play, attempting to subvert the already in-progress community process. I did not appreciate David's attitude in that instance, and I think David has blown his response in this thread out of proportion.
Really, please folks, just calm down.
Fedora Desktop and Fedora KDE spins. Is that really so bad?
Warren Togami wtogami@redhat.com
Warren Togami wrote:
Fedora Desktop and Fedora KDE spins. Is that really so bad?
Yes it is. This kind of biased branding would lead to the perception GNOME is always going to be favored regardless of whether there is a active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is going to ensure that we have a very well integrated GNOME desktop on Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et all) releases gives more space for other active contributors to do the hard work they can and try to compete fiercely to provide the best possible experience within Fedora. Dont strike down that opportunity.
I am not biased against GNOME or anything. I use it all the time. Doesnt mean we shouldnt strive to accommodate other preferences more.
Rahul
Rahul Sundaram schrieb:
Warren Togami wrote:
Fedora Desktop and Fedora KDE spins. Is that really so bad?
Yes it is. This kind of biased branding would lead to the perception GNOME is always going to be favored regardless of whether there is a active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is going to ensure that we have a very well integrated GNOME desktop on Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et all) releases gives more space for other active contributors to do the hard work they can and try to compete fiercely to provide the best possible experience within Fedora. Dont strike down that opportunity.
Fully agreed!
Cu thl (gnome user)
Le samedi 06 janvier 2007 à 09:59 +0100, Thorsten Leemhuis a écrit :
Rahul Sundaram schrieb:
Warren Togami wrote:
Fedora Desktop and Fedora KDE spins. Is that really so bad?
Yes it is. This kind of biased branding would lead to the perception GNOME is always going to be favored regardless of whether there is a active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is going to ensure that we have a very well integrated GNOME desktop on Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et all) releases gives more space for other active contributors to do the hard work they can and try to compete fiercely to provide the best possible experience within Fedora. Dont strike down that opportunity.
Fully agreed!
So do I !
Cu thl (gnome user)
ThomasCanniot (gnome user)
On Saturday 06 January 2007 03:34, Rahul Sundaram wrote:
Yes it is. This kind of biased branding would lead to the perception GNOME is always going to be favored regardless of whether there is a active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is going to ensure that we have a very well integrated GNOME desktop on Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et all) releases gives more space for other active contributors to do the hard work they can and try to compete fiercely to provide the best possible experience within Fedora. Dont strike down that opportunity.
I am not biased against GNOME or anything. I use it all the time. Doesnt mean we shouldnt strive to accommodate other preferences more.
No, it really doesn't. Calling it Fedora Desktop means that this is the best desktop we're putting forward. This is where the vast majority of integration work happens, where upstream participation is geared toward, where the majority of QA goes, etc, etc...
In some magical world where a few years down the road this changes and we put it all into KDE for a while and KDE gets to the same level as GNOME for us, we make the switch in our Fedora Desktop spin, as now KDE is where all the above happens. End users continue to want a well oiled integrated desktop, and thus choose the Fedora Desktop spin. We want to name based on functionality, not on what particular software is used. Take a look at your menu system for example, Calculator, Dictionary, Terminal, Web Browser, etc... End users need not care what actual app their using, and if they did care, Help -> About. We need to get easily translatable names for the things we do, so that it isn't a mystery what a spin is for, it is very clear.
Jesse Keating wrote:
No, it really doesn't. Calling it Fedora Desktop means that this is the best desktop we're putting forward. This is where the vast majority of integration work happens, where upstream participation is geared toward, where the majority of QA goes, etc, etc...
In some magical world where a few years down the road this changes and we put it all into KDE for a while and KDE gets to the same level as GNOME for us, we make the switch in our Fedora Desktop spin, as now KDE is where all the above happens.
Are we aiming for a equivalent footing or not? If we are then the branding should be a reflection of that. The problem with selecting a release name based on a alleged current shortage of community resources is that the perception would make it a permanent thing. Like calling Fedora a beta would make it a excuse for bad bugs in the release. You dont get much of a second chance to change perception some time in the future yet again. Heck, we are *still* getting badly burned by poor messaging in the past. Have we not learned anything from that?
End users continue to want a well oiled integrated desktop,
and thus choose the Fedora Desktop spin. We want to name based on functionality, not on what particular software is used.
So why is one of the spins called Fedora KDE? How is it *not* a Fedora Desktop? What about when someone wants to do a Fedora Desktop spin based on another of those alternative desktop environments, windows managers?
Take a look at your
menu system for example, Calculator, Dictionary, Terminal, Web Browser, etc... End users need not care what actual app their using, and if they did care, Help -> About.
That's true for GNOME currently. Not for the KDE menu in Fedora. Do take a look.
We need to get easily translatable names for the things
we do, so that it isn't a mystery what a spin is for, it is very clear.
Sure. I have been a translator before. Have release names such as Fedora GNOME Desktop and Fedora KDE Desktop is very well translatable. No, I am not talking about volume ids and iso filenames here.
Rahul
On Saturday 06 January 2007 07:52, Rahul Sundaram wrote:
Are we aiming for a equivalent footing or not? If we are then the branding should be a reflection of that. The problem with selecting a release name based on a alleged current shortage of community resources is that the perception would make it a permanent thing. Like calling Fedora a beta would make it a excuse for bad bugs in the release. You dont get much of a second chance to change perception some time in the future yet again. Heck, we are *still* getting badly burned by poor messaging in the past. Have we not learned anything from that?
You and I just disagree that this is bad messaging. Whether we're aiming for equal footing or not, it just isn't there right now. And to be honest, putting a lot of effort into making them equal is not going to happen from the Red Hat resources. We've picked our desktop, what we want to put our efforts behind for our RHEL product line. For our product, multiple desktops just fractures our userbase, doubles our support needs, weakens the product overall as it takes away resources better spent on total integration. For that reason, the vast majority of Red Hat contribution to the Fedora Community is going to be around the gnome desktop. I don't likely see this changing in the foreseeable future. Will there come a time that the non Red Hat contribution to the Fedora Community around KDE will outsurpass and outshine the Red Hat contribution to the Fedora community around Gnome? I don't think so, any time soon.
End users continue to want a well oiled integrated desktop,
and thus choose the Fedora Desktop spin. We want to name based on functionality, not on what particular software is used.
So why is one of the spins called Fedora KDE?
Because it is a targetted spin for a particular peice of software, much like an eclipse spin or XFCE spin or asterisk spin.
How is it *not* a Fedora Desktop?
At this point it is not THE Fedora desktop. Its not what we want to flaunt, have reviews written about, be judged upon, etc. It is a startup, and needs a lot of work/time to get to the polish / integration level we have with gnome, our premier desktop.
What about when someone wants to do a Fedora Desktop spin based on another of those alternative desktop environments, windows managers?
ee above.
Take a look at your
menu system for example, Calculator, Dictionary, Terminal, Web Browser, etc... End users need not care what actual app their using, and if they did care, Help -> About.
That's true for GNOME currently. Not for the KDE menu in Fedora. Do take a look.
You say this as if it's a good thing, I see this as another fact that KDE isn't really designed for the mass userbase. How in gods green earth is somebody supposed to look at a KDE menu and know that Konqueror is for browsing the web? That "Kate" is for writing text files?
Jesse Keating wrote:
You and I just disagree that this is bad messaging. Whether we're aiming for equal footing or not, it just isn't there right now. And to be honest, putting a lot of effort into making them equal is not going to happen from the Red Hat resources.
That may be true but I am not expecting Red Hat to do all the work in Fedora. We dont have a community if that was true. Luckily there is a enthusiastic and active community around KDE in Fedora.
http://fedoraproject.org/wiki/Extras/SIGs/KDE
We've picked our desktop, what we want to put our
efforts behind for our RHEL product line. For our product, multiple desktops just fractures our userbase, doubles our support needs, weakens the product overall as it takes away resources better spent on total integration.
RHEL includes both GNOME and KDE. Red Hat is going to have to support them both. It might not make sense of engineering to do the additional work. Yes, it does escalate support costs but we already have made that choice due to customer demands. The same case for including three different MTA's - sendmail, postfix and exim or anything in which we provide more than one implementation of similar technologies.
For
that reason, the vast majority of Red Hat contribution to the Fedora Community is going to be around the gnome desktop. I don't likely see this changing in the foreseeable future.
Yes. I am already aware of that.
Will there come a time that the non Red
Hat contribution to the Fedora Community around KDE will outsurpass and outshine the Red Hat contribution to the Fedora community around Gnome? I don't think so, any time soon.
Maybe but what we are doing now is not going to encourage them.
Because it is a targetted spin for a particular peice of software, much like an eclipse spin or XFCE spin or asterisk spin.
Yes, thats true for both a server and GNOME spin. Every different spin is targeted towards a particular set of users.
How is it *not* a Fedora Desktop?
At this point it is not THE Fedora desktop. Its not what we want to flaunt, have reviews written about, be judged upon, etc. It is a startup, and needs a lot of work/time to get to the polish / integration level we have with gnome, our premier desktop.
Just because you call the spin, Fedora KDE doesnt mean people arent going to flaunt, review or judge it.
You say this as if it's a good thing, I see this as another fact that KDE isn't really designed for the mass userbase. How in gods green earth is somebody supposed to look at a KDE menu and know that Konqueror is for browsing the web? That "Kate" is for writing text files?
So why havent we fixed up the menu to be meaningful? Yeah right, because we didnt have enough resources or we just have not cared. This is exactly the sort of things opening it up to the community and doing a targeted spin is supposed to fix.
Rahul
On Saturday 06 January 2007 08:31, Rahul Sundaram wrote:
So why havent we fixed up the menu to be meaningful? Yeah right, because we didnt have enough resources or we just have not cared. This is exactly the sort of things opening it up to the community and doing a targeted spin is supposed to fix.
Or it could possibly be that upstream doesn't WANT the menu to be "fixed". Perhaps they don't agree with our views. In Fedora we try to stay with upstream, and make our changes there, or make sure our changes get there. What we don't want to get to again is calling something KDE but changing it drastically from what the upstream KDE looks/feels like. That doesn't win you any users, all it does is piss off the people who want the real KDE.
I'm tired of this argument already. I'll call the spin whatever the board decides they want it references as. It shows up at installer boot time, sometimes during the install, and whatever materials reference the iso set. Not that huge of a deal, you have my opinion on the matter.
Rahul Sundaram wrote:
Jesse Keating wrote:
You say this as if it's a good thing, I see this as another fact that KDE isn't really designed for the mass userbase. How in gods green earth is somebody supposed to look at a KDE menu and know that Konqueror is for browsing the web? That "Kate" is for writing text files?
So why havent we fixed up the menu to be meaningful?
KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as Konqueror Web Browswer IMO, the fact that other apps (and gnome) in Fedora does this differently by abusing Name= vs. GenericName= in .desktip files is bad/wrong/silly/bug. As long as I have any input on it, * KDE will not go down that road, ever. * Packaging Guidelines should be updated highlight/avoid such abuse
-- Rex
Rex Dieter wrote:
KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as Konqueror Web Browswer
Yes. I am aware of that which makes Jesse Keating's argument about Fedora following upstream a weak one.
IMO, the fact that other apps (and gnome) in Fedora does this differently by abusing Name= vs. GenericName= in .desktip files is bad/wrong/silly/bug. As long as I have any input on it,
- KDE will not go down that road, ever.
- Packaging Guidelines should be updated highlight/avoid such abuse
I dont particular care where the bug is. Inconsistency in approach between desktop environments is probably a bug which should get fixed anyhow. I think you have mentioned earlier on a few occasions that you were planning to get the guidelines altered to avoid this problem. That should help.
Rahul
On Saturday 06 January 2007 12:13, Rahul Sundaram wrote:
I dont particular care where the bug is. Inconsistency in approach between desktop environments is probably a bug which should get fixed anyhow. I think you have mentioned earlier on a few occasions that you were planning to get the guidelines altered to avoid this problem. That should help.
You're still thinking in Fedora we want to alter the upstream to make it look like Gnome, or vice versa. When in reality, they should look like upstream. We put a lot of effort into getting the upstream gnome to work the way we think it should, whereas KDE we don't have that kind of presence. We shouldn't be stomping on their software in our distribution, it should stick to upstream. That's WHY there is choice, as the KDE upstream doesn't necessarily agree with the GNOME upstream on how things should be done.
Jesse Keating wrote:
You're still thinking in Fedora we want to alter the upstream to make it look like Gnome, or vice versa. When in reality, they should look like upstream.
Since we are talking about the menu, let me note that KDE does provide multiple choices and one of them is a good fit to make it match what you want from it. Picking a good defaults (which doesnt require intrusive patches) that integrates well within Fedora is our job. We cant punt that upstream.
We put a lot of effort into getting the upstream gnome to work the way we think it should, whereas KDE we don't have that kind of presence. We shouldn't be stomping on their software in our distribution, it should stick to upstream. That's WHY there is choice, as the KDE upstream doesn't necessarily agree with the GNOME upstream on how things should be done.
Agreed. It does happen on many occasions.
Rahul
On Sat, 2007-01-06 at 08:12 -0600, Rex Dieter wrote:
Rahul Sundaram wrote:
Jesse Keating wrote:
You say this as if it's a good thing, I see this as another fact that KDE isn't really designed for the mass userbase. How in gods green earth is somebody supposed to look at a KDE menu and know that Konqueror is for browsing the web? That "Kate" is for writing text files?
So why havent we fixed up the menu to be meaningful?
KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as Konqueror Web Browswer IMO, the fact that other apps (and gnome) in Fedora does this differently by abusing Name= vs. GenericName= in .desktip files is bad/wrong/silly/bug. As long as I have any input on it,
- KDE will not go down that road, ever.
- Packaging Guidelines should be updated highlight/avoid such abuse
Rex, not every design decision made by the desktop team can be reverted via the packaging guidelines. Committees work best if they don't try to grab too much power.
Matthias Clasen wrote:
On Sat, 2007-01-06 at 08:12 -0600, Rex Dieter wrote:
Rahul Sundaram wrote:
Jesse Keating wrote:
You say this as if it's a good thing, I see this as another fact that KDE isn't really designed for the mass userbase. How in gods green earth is somebody supposed to look at a KDE menu and know that Konqueror is for browsing the web? That "Kate" is for writing text files?
So why havent we fixed up the menu to be meaningful?
KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as Konqueror Web Browswer IMO, the fact that other apps (and gnome) in Fedora does this differently by abusing Name= vs. GenericName= in .desktip files is bad/wrong/silly/bug. As long as I have any input on it,
- KDE will not go down that road, ever.
- Packaging Guidelines should be updated highlight/avoid such abuse
Rex, not every design decision made by the desktop team can be reverted via the packaging guidelines. Committees work best if they don't try to grab too much power.
I just *knew* someone would take my rant the wrong way. (:
fdo .desktop standards allow for what the desktop team was aiming for (simplified menus, afaict), but, it's the implementation of said goal that was, imho, ill-conceived. I'm merely hoping to make that clear, and by codifying/clarifying the Packaging Guidelines on the topic to avoid such folly in the future.
-- Rex
-- Rex
On 1/6/07, Jesse Keating jkeating@redhat.com wrote:
Because it is a targetted spin for a particular peice of software, much like an eclipse spin or XFCE spin or asterisk spin.
Or to but it another way. Is the door open for a pure gnome spin using community power in the future? Where we have the default browser be gnome's default browser.. and use the gnome specific office applications instead of open office? I know this isn't practical, but I think it should be pointed out that what the best-of-breed 'Desktop' looks like right now is not strictly gnome, it does deviate in significant ways at the application layer to take advantage of best-of-breed applications. Because of this it does make sense to avoid calling it Fedora Gnome, because it is not a faithful integration of the gnome application set as invisioned by upstream. I don't think the pool of gnome purists is particularly large so I doubt we will see a push for a spin of a vanilla gnome, ever.. but there is room for it in the spin-space. And besides, 4 years from now the Fedora Desktop will be using the Sugar interface with the dolphin-accessibility extensions so this how debate is really short-sighted.
-jef"As a card carrying member of Gnome Purists Anonymous, the best-of-breed approach to RedHat's view of how to build a desktop sickens me. Having firefox as the default browser is a perversion of the sanctity of the gnome ui."spaleta
On Sat, 2007-01-06 at 12:04 -0900, Jeff Spaleta wrote:
On 1/6/07, Jesse Keating jkeating@redhat.com wrote:
Because it is a targetted spin for a particular peice of software, much like an eclipse spin or XFCE spin or asterisk spin.
Or to but it another way. Is the door open for a pure gnome spin using community power in the future? Where we have the default browser be gnome's default browser.. and use the gnome specific office applications instead of open office?
I think the Fedora project should be open to this kind of thing; I think we want to make it extremely easy to do "spins" including having some kind of hosting space provided by the Fedora Project for "blessed" spins.
Anyone should be able to easily start up a "spin" (even large corporations for internal deployments but I'm thinking more of Fedora Special Interest Group (SIG) like XFCE, E17, Music, Games, Eclipse etc.) and once it has proved itself perhaps it can be officially hosted by the Fedora Project.
What all this means is probably too early to discuss (I'm thinking out loud!) but after F7 is out it would be good to see some guidelines on how all this is going to work out. We want to ensure, for one thing, that it doesn't grow out of bounds, e.g. we have 100 little used spins; I think rather we want < 10 high quality and maintained spins.
The governance structure of who controls a spin needs to be thought about too including guidelines when for resolving conflicts when a package is needed by more than one spin and there is divergence on how the package should be packaged up.
With guidelines and thinking of all this... we can start building tools to easily enable people to do spins. It will take a lot of time to write all this down though. It's not too early to start I think.
Btw, as a bad analogy, I see
Fedora Package Collection ~= Debian Fedora Desktop ~= Ubuntu Fedora KDE ~= Kubuntu
e.g. "spins" are derived Fedora distributions in their very own sense. I think that's somewhat worth pointing out as it helps put things in perspective. But let's start with Desktop, Server and KDE as the three first spins! God knows, we have enough on our plate for F7.
(Btw, I'd welcome a purist GNOME spin - note that our Fedora 6 live CD uses GNOME office!)
David
On Sat, 2007-01-06 at 16:26 -0500, David Zeuthen wrote:
(Btw, I'd welcome a purist GNOME spin - note that our Fedora 6 live CD uses GNOME office!)
+1
/B
On 1/6/07, David Zeuthen david@fubar.dk wrote:
(Btw, I'd welcome a purist GNOME spin - note that our Fedora 6 live CD uses GNOME office!)
With some changes of your scripts, I could make a LiveCD with Xfce desktop too :)
FYI,
Cheers,
On 1/6/07, David Zeuthen david@fubar.dk wrote:
I think the Fedora project should be open to this kind of thing; I think we want to make it extremely easy to do "spins" including having some kind of hosting space provided by the Fedora Project for "blessed" spins.
I am just trying to recast the discussion, to show that the issue over spin branding isn't really a strict Desktop spin == Gnome spin versus KDE spin. The reality is Desktop spin == FrankeinFood spin.
Anyone should be able to easily start up a "spin" (even large corporations for internal deployments but I'm thinking more of Fedora Special Interest Group (SIG) like XFCE, E17, Music, Games, Eclipse etc.) and once it has proved itself perhaps it can be officially hosted by the Fedora Project.
We may get 'easily' from a toolset point of view. But I personally have significant concerns that community SIGS will be able to meet my reasonable expectations with regard to quality integration work. I will say that the work the FedoraUnity people have been doing with their livecds and re-spins assuages some of my deeper fears and should be looked to as a model on how people in the fedora community can self-organize to get things done.
The governance structure of who controls a spin needs to be thought about too including guidelines when for resolving conflicts when a package is needed by more than one spin and there is divergence on how the package should be packaged up.
Conflicts will always happen, people will have to be willing to work within a defined conflict resolution process and abide by the decisions. I expect the biggest pain associated with the merger, across a number of fronts, will be integrating the in-house culture surrounding how plans for Core are made, with the external culture that has been developing for the last 2 or 3 years. I hope there is a chance for internal and external leads to meet up at FudCon, over some pizza and beer and some high-spirited wii-sports competitions, and get to know each other beyond what they see in mailinglist conflicts.
-jef"patiently waiting for FUDCon Fairbanks"spaleta
Jeff Spaleta wrote:
On 1/6/07, Jesse Keating jkeating@redhat.com wrote:
Because it is a targetted spin for a particular peice of software, much like an eclipse spin or XFCE spin or asterisk spin.
Or to put it another way. Is the door open for a pure gnome spin using community power in the future? Where we have the default browser be gnome's default browser.. and use the gnome specific office applications instead of open office? I know this isn't practical, but I think it should be pointed out that what the best-of-breed 'Desktop' looks like right now is not strictly gnome, it does deviate in significant ways at the application layer to take advantage of best-of-breed applications. Because of this it does make sense to avoid calling it Fedora Gnome
As usual Jeff, you make *way* too much sense for most people (ok, maybe just me) to comprehend sometimes. (:
-- Rex
On Jan 6, 2007, at 3:06 AM, Warren Togami wrote:
More broadly... Fedora is not a democracy.
Fedora is a meritocracy.
Yes, and it's worth expanding on this. For example, a democracy is one where people with, say, too much time on their hands are able to build a community of peers (because most people like to be followed) and get elected into office based on e.g. the amount of mails the write and how well they crush their opposition. In a meritocracy we don't do this, we still let the most competent person (or persons) make decisions. Of course in some cases it's difficult for outsiders (who cannot judge, for a given subject matter, who is competent and who is not) to understand why some decisions are made and some are not. The day Fedora becomes a democracy is the day I'll contributing to Fedora.
One issue however that I see with this, is historic lack of inter- communication between the RH Desktop team and the community.
Not sure what you had in mind (examples?) but it's not exactly true (which is an understatement) though of course relations between RH employees and non-RH employees wanting to help out too can be improved. We always tell people to help out upstream; the only patches we carry are for defaults really. It's just like the kernel, we tell Fedora people to hack on kernel.org kernels.
David
David Zeuthen wrote:
Not sure what you had in mind (examples?) but it's not exactly true (which is an understatement) though of course relations between RH employees and non-RH employees wanting to help out too can be improved. We always tell people to help out upstream; the only patches we carry are for defaults really. It's just like the kernel, we tell Fedora people to hack on kernel.org kernels.
Fedora-desktop list is not getting much traffic. All of the desktop team plans usually happen in a internal list and is completely opaque till it hits the development tree. One of the problems with that is it wrongly appears that there is no desktop development work going on within Fedora.
Very few folks participate here or in any fedora list but that isnt a problem isolated to one specific team. Please consider having regular open irc development discussions, post meeting minutes updates, as many of the sub project like extras,ambassadors, infrastructure etc have been doing.
Also the only plan for the GNOME desktop spin (not talking about KDE spin as Rex Dieter is the owner) listed is the detailed spec about fast user switching. Other than the new icon theme, do we have additional things to look at? Telepathy? PulseAudio? There has been several other things discussed in earlier releases and now such as evaluating init replacements, codec buddy, GDM early login, stateless linux. home user backup etc which the team might want to keep track of.
Rahul
On Jan 6, 2007, at 12:06 PM, Rahul Sundaram wrote:
David Zeuthen wrote:
Not sure what you had in mind (examples?) but it's not exactly true (which is an understatement) though of course relations between RH employees and non-RH employees wanting to help out too can be improved. We always tell people to help out upstream; the only patches we carry are for defaults really. It's just like the kernel, we tell Fedora people to hack on kernel.org kernels.
Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for misguided features. Sadly.
All of the desktop team plans usually happen in a internal list and is completely opaque till it hits the development tree.
Not entirely true; Rahul, you have access to that list and not a lot of _Fedora_ planning is going on so stop spreading misinformation. It's mainly used for RHEL stuff. It's true that we have some mails sometimes discussing early features for Fedora and, sure, in some instances we still need to move the last 5% to the external list. Wrt to IRC we also have many discussions externally on #fedora-desktop. You also need to realize that we have hallway conversations, that's unavoidable but sometimes high-bandwidth communications are needed.
For example, I did post the f-u-s proposal; it didn't receive much feedback at all. My take is that the Fedora community largely isn't very interested in the desktop (I would loved to be proved wrong, don't take this in a non-constructive way); in that way we're succesful, for example an avid Fedora user is Richard Hughes and I deal a lot with him on upstream lists discussing features in hal and g-p-m.
One of the problems with that is it wrongly appears that there is no desktop development work going on within Fedora.
The desktop team is understaffed, we spend a lot of time in bugzilla and doing packaging rather than development. I think you don't realize this and this is bad as you should know such things being an RH employee. And this is bad.
PulseAudio?
As Matthias said earlier, Monty is still finalizing that plan for external consumption; it's just at very early stages of design and at this point bringing it up on a Fedora list is just not productive; of course people should feel free to ping him on IRC (nickname xiphmont) on #fedora-desktop. No one have really, so I guess that there is little interest? Please come forward.
There has been several other things discussed in earlier releases and now such as evaluating init replacements, codec buddy, GDM early login, stateless linux. home user backup etc which the team might want to keep track of.
This is all something the desktop team cares about but we have not have time to do anything about it. You're making it sound like we're working on this in secret chambers. It is not so. Please stop the FUD about the RH desktop team being secretive, especially when you, as a RH employee, should know better as you have access to read our internal list. Also, we all hangout on #fedora-desktop on GimpNet so it's not like we're difficult to reach. Please join that channel and starting _talking_ to us instead of treating us like we want to do things secret. Thanks.
David
Rahul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
David Zeuthen wrote:
Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for misguided features. Sadly.
Calling it fedora-desktop-devel list might have avoided that problem to some extent.
Not entirely true; Rahul, you have access to that list and not a lot of _Fedora_ planning is going on so stop spreading misinformation. It's mainly used for RHEL stuff. It's true that we have some mails sometimes discussing early features for Fedora and, sure, in some instances we still need to move the last 5% to the external list. Wrt to IRC we also have many discussions externally on #fedora-desktop.
I dont really have access to all of the internal lists. I could update the external wiki pages with the information in some of the lists that I do have access to but that would risk putting out confidential stuff. Who knows about these fedora-desktop irc discussions apart from the desktop team itself? Would you consider moving it from Gimpnet to Freenode along with the rest of the channels? When any considerable discussions happen on irc, it needs to be posted on the Fedora wiki page (preferably with meeting mins) for folks to look back. If noone within the team has time for this, send me the logs and I will do it.
You also need to
realize that we have hallway conversations, that's unavoidable but sometimes high-bandwidth communications are needed.
I think we still need to find a way to make the essential parts of those conversations more public. Fedora Project Board has regular meetings on phone but we do post meetings mins on the wiki and we have real time updates on #fedora-board irc channel these days.
For example, I did post the f-u-s proposal; it didn't receive much feedback at all. My take is that the Fedora community largely isn't very interested in the desktop (I would loved to be proved wrong, don't take this in a non-constructive way); in that way we're succesful, for example an avid Fedora user is Richard Hughes and I deal a lot with him on upstream lists discussing features in hal and g-p-m.
I think that's because not many people know about fedora-desktop list. Would you think merging it with fedora-devel list would be a good thing?
The desktop team is understaffed, we spend a lot of time in bugzilla and doing packaging rather than development. I think you don't realize this and this is bad as you should know such things being an RH employee. And this is bad.
Ahem. I think you are forgetting our earlier irc conversations. You cant reasonably expect me to keep track of all the development work happening more than I do so now. I bet I know more about it than maybe less than half a dozen people in India. Telling me that I am somehow spreading FUD might shut me up but is not going to help solve the problem that some of the development is not as transparent as it could be.
Rahul
On Sat, 2007-01-06 at 23:17 +0530, Rahul Sundaram wrote:
David Zeuthen wrote:
Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for misguided features. Sadly.
Calling it fedora-desktop-devel list might have avoided that problem to some extent.
Maybe. I just don't think people who need support etc. bother (See: this list).
Not entirely true; Rahul, you have access to that list and not a lot of _Fedora_ planning is going on so stop spreading misinformation. It's mainly used for RHEL stuff. It's true that we have some mails sometimes discussing early features for Fedora and, sure, in some instances we still need to move the last 5% to the external list. Wrt to IRC we also have many discussions externally on #fedora-desktop.
I dont really have access to all of the internal lists. I could update the external wiki pages with the information in some of the lists that I do have access to but that would risk putting out confidential stuff.
My point was that little or no interesting Fedora conversations are going on at that list. You are able to verify this my looking at the internal Red Hat mailman archives for said list. But you didn't, you assumed - and posted that to a Fedora community list - that we're talking about a lot of secretive stuff. Which is wrong. That's what so bad.
(And of course you should never post information from one internal list to another, you're missing the point if that's what you think I'm asking you to do.)
Who knows about these fedora-desktop irc discussions apart from the desktop team itself? Would you consider moving it from Gimpnet to Freenode along with the rest of the channels? When any considerable discussions happen on irc, it needs to be posted on the Fedora wiki page (preferably with meeting mins) for folks to look back. If noone within the team has time for this, send me the logs and I will do it.
Not sure it's worthwhile moving it; I for one want it to stay on GimpNet such as to stay close to upstream IRC channels. Posting minutes is a lot of work; if people use IRC for such activitites (and we don't I think) it's better to discuss on a mailing list.
My point was that if someone wants to make Fedora a better desktop, start by jumping on IRC and interactive with us! I'd be thrilled to see Fedora users come out and say "hey, I want to write this or that app".
For example, I did post the f-u-s proposal; it didn't receive much feedback at all. My take is that the Fedora community largely isn't very interested in the desktop (I would loved to be proved wrong, don't take this in a non-constructive way); in that way we're succesful, for example an avid Fedora user is Richard Hughes and I deal a lot with him on upstream lists discussing features in hal and g-p-m.
I think that's because not many people know about fedora-desktop list. Would you think merging it with fedora-devel list would be a good thing?
No way, it needs to be developers solely interested in the _development_ of the desktop, not this forum we have on this list which is more packaging-entry. It's way too noisy to get any desktop development done on this list I think.
Again, people should get involved in upstream GNOME and upstream fd.o development. People just _don't_ seem to get this - just look at the NM sub-thread of this thread. This surely belongs on networkmanager-list@gnome.org and _people_ still don't get it. Well, maybe I'm ranting but the thread here did show good ideas - why not take it to the upstream list where we have more NM wizards that Dan Williams?
The desktop team is understaffed, we spend a lot of time in bugzilla and doing packaging rather than development. I think you don't realize this and this is bad as you should know such things being an RH employee. And this is bad.
Ahem. I think you are forgetting our earlier irc conversations. You cant reasonably expect me to keep track of all the development work happening more than I do so now. I bet I know more about it than maybe less than half a dozen people in India. Telling me that I am somehow spreading FUD might shut me up but is not going to help solve the problem that some of the development is not as transparent as it could be.
Well, just get the facts before posting because spreading misinformation (which I'm accusing you of) is bad.
There's not a lot of desktop development going in _Fedora_ and it's not because the RH Desktop team is being secretive about it. It's because we either do Bugzilla / Packaging work (which I personally hate as I think my time is much better spent on writing code) or have the conversations / do development upstream like we should.
On a constructive note, how can we raise awareness in the Fedora community that development needs to happen upstream if possible? How can we easily direct people to gnome.org mailing lists and IRC channels?
(Of course, for some things Fedora _is_ the upstream, see e.g. the livecd development work. That's open and going well.)
David
David Zeuthen wrote:
My point was that if someone wants to make Fedora a better desktop, start by jumping on IRC and interactive with us! I'd be thrilled to see Fedora users come out and say "hey, I want to write this or that app".
People usually realise the existence of irc channels because of the frequent updates from them. For example, Fedora Extras Steering Committee has a public schedule and post summaries from all the meetings they have on a weekly basis.
http://fedoraproject.org/wiki/Extras
No way, it needs to be developers solely interested in the _development_ of the desktop, not this forum we have on this list which is more packaging-entry. It's way too noisy to get any desktop development done on this list I think.
Well, the moment you start posting anything substantial, more people are going to subscribe and start posting. We can't help. On the other hand even if some of it is noise (I deserve the blame in some cases), it does show interest. You might able to turn that interest into contributions - testing, triaging, development work etc. Fedora-art list is a good example here.
Again, people should get involved in upstream GNOME and upstream fd.o development. People just _don't_ seem to get this - just look at the NM sub-thread of this thread. This surely belongs on networkmanager-list@gnome.org and _people_ still don't get it. Well, maybe I'm ranting but the thread here did show good ideas - why not take it to the upstream list where we have more NM wizards that Dan Williams?
Users would see that as part of Fedora development rather than wanting to post to all the different upstream mailing lists. I can talk about NM here but I am not inclined to subscribe to another mailing list just to post a few points.
On a constructive note, how can we raise awareness in the Fedora community that development needs to happen upstream if possible?
Having a easily accessible documented policy like http://fedoraproject.org/wiki/Extras/Policy would help here.
How can
we easily direct people to gnome.org mailing lists and IRC channels?
Might have a sub page in http://fedoraproject.org/wiki/Communicate to point to the upstream projects that we actively work on and care about.
(Of course, for some things Fedora _is_ the upstream, see e.g. the livecd development work. That's open and going well.)
Yes. It does. Much appreciated. Thank you.
Rahul
On Sat, 2007-01-06 at 23:49 +0530, Rahul Sundaram wrote:
David Zeuthen wrote:
My point was that if someone wants to make Fedora a better desktop, start by jumping on IRC and interactive with us! I'd be thrilled to see Fedora users come out and say "hey, I want to write this or that app".
People usually realise the existence of irc channels because of the frequent updates from them. For example, Fedora Extras Steering Committee has a public schedule and post summaries from all the meetings they have on a weekly basis.
It's comparing apple's and orange's. Extras has very concrete needs to be that organized because if the repo is not consistent it breaks for everybody. Desktop _development_ as opposed to packaging is just different.
Again, people should get involved in upstream GNOME and upstream fd.o development. People just _don't_ seem to get this - just look at the NM sub-thread of this thread. This surely belongs on networkmanager-list@gnome.org and _people_ still don't get it. Well, maybe I'm ranting but the thread here did show good ideas - why not take it to the upstream list where we have more NM wizards that Dan Williams?
Users would see that as part of Fedora development rather than wanting to post to all the different upstream mailing lists. I can talk about NM here but I am not inclined to subscribe to another mailing list just to post a few points.
Well, sorry but software development is just damn hard and it requires that you actually engage with the community at hand rather than just post hand-wavy comments. If you cannot engage yourself enough to subscribe to an upstream list to provide feedback then so be it. Yes, this is harsh but I'm really tired of this attitude.
Suggest to just post your points in Bugzilla at least so it's tracked; I've seen way too many people decrease the S/N ratio on e.g. this list with misguided feature requests and rants about upstream software components.
It's definitely not useful, it's scaring away core Fedora contributors (TBH I've thought of unsubscribing from this list several times), it creates tons of flame wars and it's _not_ something we should encourage. Please, everyone, in the future please _do_ direct people to appropriate upstream lists / Bugzilla. If people are too lazy or busy to do that then so be it, it's a loss I can live with.
Btw, I'd rather just fix the technical problem of not having to subscribe to a list to post comments. E.g. if you are subscribed to one @redhat.com list you should be able to post to all. Heck, perhaps that even gives you posting privileges to the appropriate fd.o and gnome lists too. And the lists shouldn't cut out Cc's either like we do today. Our lists are not set up to be friendly in that regard... but that can change.
All this talk about Fedora community is good. But I think people are missing out that there's a world beyond Fedora (upstream) that you _need_ to interact with if you want to make a difference. It also scales a helluva better.
(sorry if I'm being an ass about things but sometimes it's better to say what you think.)
David
Le samedi 06 janvier 2007 à 13:42 -0500, David Zeuthen a écrit :
It's comparing apple's and orange's. Extras has very concrete needs to be that organized because if the repo is not consistent it breaks for everybody.
Because the desktop does not need to be consistent?
All this talk about Fedora community is good. But I think people are missing out that there's a world beyond Fedora (upstream) that you _need_ to interact with if you want to make a difference. It also scales a helluva better.
I think you are missing out that
1. people can not interact directly with all the upstreams Fedora builds on (do you? not just the parts you're working on but all the other bits you use). Even a dozen upstream MLs is sufficient to saturate any inbox.
2. rahul is one of the few people that tries to be active on the various Fedora channels and put everything together, if you find him clueless why I can't begin to imagine what your opinion of a basic community contributor is
3. you complain the desktop team is misunderstood but as far as I know its only frontend is http://fedora.redhat.com/About/Projects/desktop/ (almost no info, retired wiki, no reference to the famous irc channel everyone should know of)
4. you feel you spend too much time on packaging work yet you totally ignore all the non-redhat people packaging desktop bits in current Extras. They're not going to help you if you persist being in stealth mode.
I've been seriously asked in the past if the Fedora Desktop Team actually existed. That sums up the current situation pretty well.
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
- people can not interact directly with all the upstreams Fedora
builds on (do you? not just the parts you're working on but all the other bit you use).
It's not that bad really; desktop-devel-list@gnome.org , xdg-list@freedesktop.org and so forth. Just reading people's blogs are often enough.
Even a dozen upstream MLs is sufficient to saturate any inbox.
Well, software development is hard and specialized, sorry. It's just _not_ _useful_ that people use fedora-devel-list instead of getting involved in upstream projects. See my other mail for details.
- rahul is one of the few people that tries to be active on the various
Fedora channels and put everything together, if you find him clueless why I can't begin to imagine what your opinion of a basic community contributor is
I didn't say that; I said he was spreading misinformation that the desktop team does things in secret. Rahul does a lot of useful stuff but when I see things like that I need to respond.
- you complain the desktop team is misunderstood but as far as I know
its only frontend is http://fedora.redhat.com/About/Projects/desktop/ (almost no info, retired wiki, no reference to the famous irc channel everyone should know of)
That should probably be fixed, sure. There used to be a nice page on fedora.redhat.com with this including pointers to upstream lists. Why the Community Relations (Warren? Rahul?) people involved in Fedora haven't fixed that I don't know; perhaps they expected the software developers in the RH desktop team to do that? Perhaps there's some misunderstanding about responsibilities that needs to be sorted out. I'll ask my manager to sort this out.
I'm not saying we're perfect, just that most members of the RH desktop team is focused on upstream work because.. that's where the decisions are made. That's just reality. And one Fedora mantra is to do things upstream. (It's interesting that the kernel people don't take the same flame as us for this attitude)
- you feel you spend too much time on packaging work yet you totally
ignore all the non-redhat people packaging desktop bits in current Extras. They're not going to help you if you persist being in stealth mode.
True. This discussion is way to heated so I can see I wasn't being constructive there; apologies to those that felt hurt. Sorry.
David
Le samedi 06 janvier 2007 à 14:38 -0500, David Zeuthen a écrit :
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
- people can not interact directly with all the upstreams Fedora
builds on (do you? not just the parts you're working on but all the other bit you use).
It's not that bad really; desktop-devel-list@gnome.org , xdg-list@freedesktop.org and so forth. Just reading people's blogs are often enough.
Create a Fedora Desktop Team planet then. Right now there is no identified Fedora Desktop Team web presence (like there was for the rh labs in a long-forgotten era)
I'm not saying we're perfect, just that most members of the RH desktop team is focused on upstream work because.. that's where the decisions are made. That's just reality. And one Fedora mantra is to do things upstream. (It's interesting that the kernel people don't take the same flame as us for this attitude)
That's because davej has done an awesome job communicating on both ends (upstream *and* fedora-side). He's not an upstream developer that happens to be paid by Red Hat, he always pays attention to both agendas.
Likewise ajax seems to have no problem being the Fedora guy upstream and the xorg guy on Fedora channels (following in mharris steps)
True. This discussion is way to heated so I can see I wasn't being constructive there; apologies to those that felt hurt. Sorry.
You're taking the heat for all the Fedora Desktop Team members we don't ever see Fedora-side, don't take it personal.
Regards,
On Sat, 2007-01-06 at 21:35 +0100, Nicolas Mailhot wrote:
Le samedi 06 janvier 2007 à 14:38 -0500, David Zeuthen a écrit :
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
- people can not interact directly with all the upstreams Fedora
builds on (do you? not just the parts you're working on but all the other bit you use).
It's not that bad really; desktop-devel-list@gnome.org , xdg-list@freedesktop.org and so forth. Just reading people's blogs are often enough.
Create a Fedora Desktop Team planet then. Right now there is no identified Fedora Desktop Team web presence (like there was for the rh labs in a long-forgotten era)
That's not a bad idea at all though most of the people are on Fedora People and Planet Gnome. Not all is good at blogging regularly, I'll certainly admit to not being as communicative as I could be.
Perhaps just someone from the team (like jrb since he's managing the team) should post a weekly status report about who in the team have been up what to every week - we have this internally (as do most companies) but it includes boring RHEL crap as well. Anyway, this person would then be responsible for collecting status reports from non-RH people too - that might help foster community involvement a lot. Accountability helps or somethings. I'll poke some people about that (See: I've added jrb to the Cc.)
(I also like how you changed to "Fedora Desktop Team" rather than the "RH Desktop Team" I was using previously.)
You're taking the heat for all the Fedora Desktop Team members we don't ever see Fedora-side, don't take it personal.
Oh, I don't (I have burn-proof pants) but I do appreciate that comment, thanks.
Despite all the flames... getting all the kinks worked out on how the Brave Merged World is going to look like might actually be beneficial for the project as a whole. At the end of the day we all want the project to be successful. And we're getting there.
David
David Zeuthen wrote:
That should probably be fixed, sure. There used to be a nice page on fedora.redhat.com with this including pointers to upstream lists. Why the Community Relations (Warren? Rahul?) people involved in Fedora haven't fixed that I don't know; perhaps they expected the software developers in the RH desktop team to do that? Perhaps there's some misunderstanding about responsibilities that needs to be sorted out. I'll ask my manager to sort this out
fedora.redhat.com is a deprecated website and there is loads of outdated information in there. If you can just get all the content needed on fedoraproject.org/wiki, I am happy with that. We would need some more basic information on who the team is. some contact information like #fedora-desktop on gimpnet which I honestly only vaguely knew ever existed and any plans and schedules of importance. That should cover the basic needs.
Rahul
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
Le samedi 06 janvier 2007 à 13:42 -0500, David Zeuthen a écrit :
It's comparing apple's and orange's. Extras has very concrete needs to be that organized because if the repo is not consistent it breaks for everybody.
Because the desktop does not need to be consistent?
Btw, it mostly is, and, for the record, there are huge collaboration zones called gnome.org, freedesktop.org and kde.org that does this for us. And several RH employees are actively participating in those fora. And I think we're mostly doing a good job. Likewise for the kernel, there is a dude called Linus Torvalds that does the same kind of stuff for our operating system kernel.
Upstream. Now with more vitamin C.
David
On Sat, 2007-01-06 at 23:17 +0530, Rahul Sundaram wrote:
I think that's because not many people know about fedora-desktop list. Would you think merging it with fedora-devel list would be a good thing?
It will be a bad thing. fedora-devel already has a lot of spam for us poor desktop-oriented guys.
Rename fedora-desktop to fedora-desktop-devel, fine, but the only way to fix the problem you have may be making people to communicate more on the list. And the way it currently goes, most of the discussion is going on in upstream lists, the bugzillas (freedesktop, gnome, and redhat), and IRC. May look bad from your side, but as the involvement in desktop seems to need to be quite long-term, this may be necessary to some degree. Desktop development is not a very rushy business...
An important spot that may be fixable is the packaging problem. If the desktop team is doing more packaging and eating less cake, let us (the extra horde?) help them in packaging and let them do the coding (lot of that may happen gradually after the union). We can't help them with RHEL of course, but we don't expect to.
Personally speaking, as an untouchable (with regard to RH) Iranian, I find it rather fine the way things are working with the Fedora Desktop team currently. I can easily contribute, things match the upstream closely, people can be found on #fedora-desktop, etc.
Roozbeh
On Sat, 2007-01-06 at 21:59 +0330, Roozbeh Pournader wrote:
I find it rather fine the way things are working with the Fedora Desktop team currently. I can easily contribute, things match the upstream closely, people can be found on #fedora-desktop, etc.
Me too. The fedora and redhat guys are great in this respect, I really don't know what all the fuss is about.
Richard.
David Zeuthen wrote:
On Jan 6, 2007, at 12:06 PM, Rahul Sundaram wrote:
David Zeuthen wrote:
Not sure what you had in mind (examples?) but it's not exactly true (which is an understatement) though of course relations between RH employees and non-RH employees wanting to help out too can be improved. We always tell people to help out upstream; the only patches we carry are for defaults really. It's just like the kernel, we tell Fedora people to hack on kernel.org kernels.
Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for misguided features. Sadly.
This is due to a lack of leadership. I've been asking Havoc and then Jrb for *YEARS* for someone in RH desktop to provide adequate and responsible community outreach and leadership on fedora-desktop-list.
Without direction, the list remained utterly useless.
One of the problems with that is it wrongly appears that there is no desktop development work going on within Fedora.
The desktop team is understaffed, we spend a lot of time in bugzilla and doing packaging rather than development. I think you don't realize this and this is bad as you should know such things being an RH employee. And this is bad.
This is a weak excuse, for lack of trying.
Recall when Red Hat had no perl maintainer for more than a year? Red Hat reached out to the community, created a Fedora perl team with a responsive perl caretaker providing effective outreach to that community. The resulting combination of thin Red Hat resource with effective collaboration with a few leading Fedora developers magnified many times fold the amount of work done.
on this in secret chambers. It is not so. Please stop the FUD about the RH desktop team being secretive, especially when you, as a RH employee, should know better as you have access to read our internal list. Also,
The attitude of the desktop team has always been one of an exclusive club, making little attempts to engage the Fedora community. While the work was done in the open (upstream at GNOME), decisions and discussions happened only internally.
This has been a problem of attitude. Your recent attempt to subvert the community driven Fedora 7 art creation process with heavy-handed "This is my job" authority is just yet another example of this.
Warren Togami wtogami@redhat.com
On Sat, 2007-01-06 at 13:50 -0500, Warren Togami wrote:
on this in secret chambers. It is not so. Please stop the FUD about the RH desktop team being secretive, especially when you, as a RH employee, should know better as you have access to read our internal list. Also,
The attitude of the desktop team has always been one of an exclusive club, making little attempts to engage the Fedora community. While the work was done in the open (upstream at GNOME), decisions and discussions happened only internally.
Oh my. It's come to posting conspiracy theories? Warren, this is out of line. You, and a few other people, are so extremely obsessed with creating / building a community around Fedora that you fail to take into account
a) what the world looks like (we do / want to do the work upstream); and
b) what is actually out there in the community (not a whole lot of useful input today desktop-wise).
It's fine to get more community involvement. It does DO NOT happen overnight and sacrificing quality is not an option. It happens gradually. Please wake up.
This has been a problem of attitude. Your recent attempt to subvert the community driven Fedora 7 art creation process with heavy-handed "This is my job" authority is just yet another example of this.
It is my job to maintain the artwork packages and, yes, I'm deeply troubled by the attitude on that list. That list is a place where the guy with the biggest stereo wins (e.g. democracy, not what we do). That's not a way to get the best result so of course I'm concerned. It's my god damn job to be concerned about that.
If you want to discuss further take your fucking conspiracy theories off list and mail me directly.
David
David Zeuthen wrote:
This has been a problem of attitude. Your recent attempt to subvert the community driven Fedora 7 art creation process with heavy-handed "This is my job" authority is just yet another example of this.
It is my job to maintain the artwork packages and, yes, I'm deeply troubled by the attitude on that list. That list is a place where the guy with the biggest stereo wins (e.g. democracy, not what we do).
fedora-art-list is not a democracy, but rather a meritocracy. The vast majority of the work there has been done by volunteers, with Máirín Duffy doing most of the community outreach and communication. Not everyone there has equal decision making power. Those who have done work and gained respect from others gain greater authority. From merit, some clear community leaders have emerged like Nicu Buculei.
Is this not how a Fedora Project should be run?
https://www.redhat.com/archives/fedora-art-list/2006-December/msg00178.html The Fedora Project Board decided, the community process is to be followed and the result of that will be used in Fedora 7 pending the Board's approval.
This is NOT YOUR DECISION. This is the Board's decision.
That's not a way to get the best result so of course I'm concerned. It's my god damn job to be concerned about that.
If you want to discuss further take your fucking conspiracy theories off list and mail me directly.
I will discuss this in public, because the Fedora Project should be transparent and open.
Warren Togami wtogami@redhat.com
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
fedora-art-list is not a democracy, but rather a meritocracy.
It is not. It's run by very loud people who are not afraid to resort to personal attacks and forming fractions and alliances.
The vast majority of the work there has been done by volunteers, with Máirín Duffy doing most of the community outreach and communication. Not everyone there has equal decision making power. Those who have done work and gained respect from others gain greater authority. From merit, some clear community leaders have emerged like Nicu Buculei.
"Communication" is not the only deciding factor. I think the work on that list is not up to Fedora release quality. As the maintainer of the artwork packages plus dealing with graphics people both in this and past jobs I can make that statement. I doubt that you can.
(This is harsh, but sorry, Warren pushed me to say such things.)
This is NOT YOUR DECISION. This is the Board's decision.
I know, but I am free to disagree with the board. I think they are trading quality for building "community". They are in this case, I think, hurting the quality of Fedora by turning the art selection process into a democracy. It's a shame and it makes believe less in the board.
I will discuss this in public, because the Fedora Project should be transparent and open.
You are just naive (and you should know better) that this is a good forum to discuss such matters in. Most of the issues in this case are personal so it's even bad form to bring it up here. You should be really ashamed of yourself Warren. I'm positive no constructive discussion can follow so I'm replying to any of your replies. Thanks.
David
David Zeuthen wrote:
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
fedora-art-list is not a democracy, but rather a meritocracy.
It is not. It's run by very loud people who are not afraid to resort to personal attacks and forming fractions and alliances.
One of us is trying to build a community with a meritocracy governance model. The other is using heavy-handed tactics in protectionism, appealing to the fallacy of authority 'this is my job'. Only one of these paths is what is best for the community.
Please consider the possibility, that what you are doing is selfish and wrong.
The vast majority of the work there has been done by volunteers, with Máirín Duffy doing most of the community outreach and communication. Not everyone there has equal decision making power. Those who have done work and gained respect from others gain greater authority. From merit, some clear community leaders have emerged like Nicu Buculei.
"Communication" is not the only deciding factor. I think the work on that list is not up to Fedora release quality. As the maintainer of the artwork packages plus dealing with graphics people both in this and past jobs I can make that statement. I doubt that you can.
(This is harsh, but sorry, Warren pushed me to say such things.)
This is NOT YOUR DECISION. This is the Board's decision.
I know, but I am free to disagree with the board. I think they are trading quality for building "community". They are in this case, I think, hurting the quality of Fedora by turning the art selection process into a democracy.
I have made it pretty clear that this is NOT a democracy. You seem to think that anything where the decision is out of your hands is a democracy. You are free to have that as a personal opinion.
It's a shame and it makes believe less in the board.
You don't need to believe in the Board. The project will move forward with or without your belief.
Warren Togami wtogami@redhat.com
On Sat, 2007-01-06 at 15:02 -0500, David Zeuthen wrote:
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
fedora-art-list is not a democracy, but rather a meritocracy.
It is not. It's run by very loud people who are not afraid to resort to personal attacks and forming fractions and alliances.
This is exactly what I've noticed as well. Not what I expected to see, but that's ok, been there done that, they can bring it.
The vast majority of the work there has been done by volunteers, with Máirín Duffy doing most of the community outreach and communication. Not everyone there has equal decision making power. Those who have done work and gained respect from others gain greater authority. From merit, some clear community leaders have emerged like Nicu Buculei.
"Communication" is not the only deciding factor. I think the work on that list is not up to Fedora release quality. As the maintainer of the artwork packages plus dealing with graphics people both in this and past jobs I can make that statement. I doubt that you can.
(This is harsh, but sorry, Warren pushed me to say such things.)
I don't think it's harsh, I just think it's the truth.
This is NOT YOUR DECISION. This is the Board's decision.
I know, but I am free to disagree with the board. I think they are trading quality for building "community". They are in this case, I think, hurting the quality of Fedora by turning the art selection process into a democracy. It's a shame and it makes believe less in the board.
I see alot of things that don't ring true; for instance, in this discussion there has been absolutely no mention of technical merit with regard to your contributions. To the contrary, there has only been discussion of authority and overriding decisions. To me this smacks of elitism; "We agree with you as long as you say what we like. Otherwise we don't want to hear what you say."
I will discuss this in public, because the Fedora Project should be transparent and open.
You are just naive (and you should know better) that this is a good forum to discuss such matters in. Most of the issues in this case are personal so it's even bad form to bring it up here. You should be really ashamed of yourself Warren. I'm positive no constructive discussion can follow so I'm replying to any of your replies. Thanks.
David
But you know what? This is exactly the forum to discuss in, because from here we get a good idea of what Warren is all about. Personal or no, one guy locked in a room with 50 assailants is not going to promote progress.
This is the arena of ideas. Let the users help sort this out. Trust them to help you because, it is, after all, for their benefit that all these things take place.
You are not the first one to have problems of this nature with the, eh, "meritocracy".
LX
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
I will discuss this in public, because the Fedora Project should be transparent and open.
Hmmmm. Well alrighty.
David Zeuthen wrote:
This has been a problem of attitude. Your recent attempt to subvert the community driven Fedora 7 art creation process with heavy-handed "This is my job" authority is just yet another example of this.
It is my job to maintain the artwork packages and, yes, I'm deeply troubled by the attitude on that list. That list is a place where the guy with the biggest stereo wins (e.g. democracy, not what we do).
fedora-art-list is not a democracy, but rather a meritocracy. The vast majority of the work there has been done by volunteers, with Máirín Duffy doing most of the community outreach and communication. Not everyone there has equal decision making power. Those who have done work and gained respect from others gain greater authority. From merit, some clear community leaders have emerged like Nicu Buculei.
The big question is, who decides who has the "merit". I see potential ideological problems here even if someone works their ass off, but then isn't necessarily considered to be, for example, 'a good socialist'. Or a good "Stallmanist". Or is that Stalinist? Sorry, I get those two confused.
In such cases, a harder worker could potentially be punished for not "towing the party line". The general excuse could be, "well, we have guys with greater merit. This is a meritocracy."
Maybe it is a meritocracy. But it should be technical merit, not anything else. One guy with a better idea should triumph over 10 guys with stupid ideas.
Is this not how a Fedora Project should be run?
https://www.redhat.com/archives/fedora-art-list/2006-December/msg00178.html The Fedora Project Board decided, the community process is to be followed and the result of that will be used in Fedora 7 pending the Board's approval.
This is NOT YOUR DECISION. This is the Board's decision.
Which will work as long as the Board a) acknowledges the existence of users b) takes it's cues from the users first and c) prioritizes technical merit over ideology.
It is also useful to examine the success of your competition. As other open source gods have already suggested here.
That's not a way to get the best result so of course I'm concerned. It's my god damn job to be concerned about that.
If you want to discuss further take your fucking conspiracy theories off list and mail me directly.
Warren Togami wtogami@redhat.com
LX
Lyvim Xaphir wrote:
The big question is, who decides who has the "merit". I see potential
"Merit" is earned through hard work. "Hard work" should speak for itself.
Sometimes disagreements happen, then the tough decision must go up the leadership chain to a deciding body. In Fedora we have multiple levels like:
FESCO (to be renamed) - technical/packaging governance issues FAB - issues recommendations, does not decide FPB - ultimate decider if lower levels cannot agree
ideological problems here even if someone works their ass off, but then isn't necessarily considered to be, for example, 'a good socialist'. Or a good "Stallmanist". Or is that Stalinist? Sorry, I get those two confused.
Calling names is intellectually lazy. Please describe with specificity how the desire to create a community where people earn respect through their hard work is Stalin-like?
I don't see the connection between Stalin and Stallman either.
https://www.redhat.com/archives/fedora-art-list/2006-December/msg00178.html The Fedora Project Board decided, the community process is to be followed and the result of that will be used in Fedora 7 pending the Board's approval.
This is NOT YOUR DECISION. This is the Board's decision.
Which will work as long as the Board a) acknowledges the existence of users b) takes it's cues from the users first and c) prioritizes technical merit over ideology.
What ideology are you referring to?
If you have criticisms of the Board not doing what is best for the users, then please speak in specifics instead of intellectually lazy generalizations.
Warren Togami wtogami@redhat.com
On Saturday 06 January 2007 16:05, Warren Togami wrote:
"Merit" is earned through hard work. "Hard work" should speak for itself.
Lets not forget that it is hard _CORRECT_ work. You do all the hard work you want, but if the product of that work is not as good as something else, guess what, we're going to go with the something else. This isn't about quantity of work done (or emails sent, or volume of speakers), it's about quality of produced products.
On Sat, 2007-01-06 at 13:50 -0500, Warren Togami wrote:
The attitude of the desktop team has always been one of an exclusive club, making little attempts to engage the Fedora community. While the work was done in the open (upstream at GNOME), decisions and discussions happened only internally.
I don't think this is the case at all, and that's from an "upstream GNOME maintainer, who uses Fedora" point of view. I also don't think this is the sort of stuff we should be discussing on list, as it's not productive in any way.
Richard.
On Sat, 2007-01-06 at 22:36 +0530, Rahul Sundaram wrote:
Also the only plan for the GNOME desktop spin (not talking about KDE spin as Rex Dieter is the owner) listed is the detailed spec about fast user switching. Other than the new icon theme, do we have additional things to look at? Telepathy? PulseAudio? There has been several other things discussed in earlier releases and now such as evaluating init replacements, codec buddy, GDM early login, stateless linux. home user backup etc which the team might want to keep track of.
Most of the Telepathy framework is already in Extras. I think the only missing piece right now is the IRC connection manager. Of course, there aren't many clients right now that make use of it in Extras (Cohoba being the only one I can think of).
/B
Warren Togami wrote:
Warren Togami wrote:
Fedora Desktop and Fedora KDE spins. Is that really so bad?
How big would a "Desktop" spin that contains both GNOME and KDE be?
depends on the packages
Too big?
I doubt it, It should be smaller as the former "Core" spin, because server packages are not in it.
Warren Togami wtogami@redhat.com
On 04 Jan 2007 16:19:11 -0600, Jason L Tibbitts III tibbs@math.uh.edu wrote:
Umm, isn't the Fedora supposed to become the community's distribution, and so isn't it up to the community to decide whether Fedora is "anything"-centric?
The community has spoken... Fedora 7 will be dolphin-centric.
-jef
On Thu, Jan 04, 2007 at 02:28:40PM -0900, Jeff Spaleta wrote:
The community has spoken... Fedora 7 will be dolphin-centric.
I thought it was seal-centric?
http://fedoraproject.org/wiki/Releases/FeatureFixWakeups?highlight=%28Catego...
Jason L Tibbitts III (tibbs@math.uh.edu) said:
JK> Its no mystery that Fedora is a Gnome centric distribution, and it JK> should be no surprise that the Fedora Desktop spin is Gnome based.
Umm, isn't the Fedora supposed to become the community's distribution, and so isn't it up to the community to decide whether Fedora is "anything"-centric?
I could care less about naming either way, but declaring up-front that regardless of what the community does or wants, Fedora is still going to favor any specific technology seems counterproductive in this new spirit of complete community involvement.
Well, it may be presumptive to speak for 'Fedora-the-project', however, there seems to be an underlying assumption in this mail, that there is:
Red Hat | Community
If that's not intended to be there, I'm sorry - that's just the impression I got.
Rather, I believe there is a large Fedora community that includes many people from Red Hat. In this community, right now, there is a large developer community that is interested in working on GNOME - it's not being deceptive to say that at the moment, it's larger than the community currently working on KDE, XFCE, E, or whatever. That GNOME community has stated that they want a desktop spin of Fedora that includes GNOME, and has stepped up to do it. So it's on the feature list.
I'm not going to lie to you - Red Hat has significant interests that are going to drive the resources we assign to Fedora, as Fedora is the upstream of RHEL; the fact that Red Hat has these interests and allocates resources this way isn't going to change. What we're trying to change is make it easy for Fedora to be used for *even more than RHEL*, whether it be Yellow Dog, or OLPC, or whatever.
Not to talk about 'the other guys', but much in the way that there is Ubuntu and Kubuntu.
Bill
On 1/4/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jesse Keating wrote:
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely used "community contributed" spin of Fedora. That's why (IMHO) its named specifically with "KDE" whereas the official spin is just "Desktop". If you don't know what "KDE" or "GNOME" is, you wouldn't know to choose it. Desktop is a good generic name that is understandable. However if you already know and prefer KDE, you know to get the KDE spin.
It would be consistent to have something like
Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
I don't think it is descriminatory at all.
Actually, what would be consistent would be for the Gnome community to name something "This does Foo" that has functionality Foo and the KDE community to name something "KBar" that has the functionality Bar (and I have a whole bunch of KStuff in my Gnome menu to prove it). Jesse's original suggestion is more inline with that since KFedora is a bit unweildy.
KDE folk seem to like their brand stuck on every piece of software made for that desktop. Gnome folk tend not to go that route and name their apps random obscure words and put localized descriptions in the menus. To each their own.
/Mike
On Friday 05 January 2007 4:28 am, Michael Wiktowy wrote:
I don't think it is descriminatory at all.
I do. Please take what follows in a light mood, at least I did.
Actually, what would be consistent would be for the Gnome community to name something "This does Foo" that has functionality Foo and the KDE community to name something "KBar" that has the functionality Bar (and I have a whole bunch of KStuff in my Gnome menu to prove it). Jesse's original suggestion is more inline with that since KFedora is a bit unweildy.
I would call that more an historical accident that a planned strategy. Please don't forget as well gedit, gaim, gphoto...
OTHO I use gwenview - Simple image viewer for KDE.
KDE folk seem to like their brand stuck on every piece of software made for that desktop. Gnome folk tend not to go that route and name their apps random obscure words and put localized descriptions in the menus. To each their own.
The plan (and practice) for KDE 4 is not to add a k preffix in a gratuitous way. FWIW the only new project that I remember now that starts with k, for KDE 4, is KDE 4 itself. :-)
Certainly the existing projects will retain their names, it would be foolish to do it otherwise, but please don't put intention where it is not.
/Mike
On 1/5/07, José Matos jamatos@fc.up.pt wrote:
On Friday 05 January 2007 4:28 am, Michael Wiktowy wrote:
I don't think it is descriminatory at all.
I do. Please take what follows in a light mood, at least I did.
Ya ... my intent was not to stir up flame wars but to poke a little fun at both communities and point out this this is a non-issue since each community can name things how they like to. In the end, it is up to the content creators to name the content.
Actually, what would be consistent would be for the Gnome community to name something "This does Foo" that has functionality Foo and the KDE community to name something "KBar" that has the functionality Bar (and I have a whole bunch of KStuff in my Gnome menu to prove it). Jesse's original suggestion is more inline with that since KFedora is a bit unweildy.
I would call that more an historical accident that a planned strategy. Please don't forget as well gedit, gaim, gphoto...
OTHO I use gwenview - Simple image viewer for KDE.
I was aware of those apps (except for gwenview) but I took a look in my application menu before sending my original message and didn't see any reference to them since they were hidden behind names like Text Editor, Instant Messenger and Photo Viewer whereas all the KDE apps kind of stood out.
KDE folk seem to like their brand stuck on every piece of software made for that desktop. Gnome folk tend not to go that route and name their apps random obscure words and put localized descriptions in the menus. To each their own.
The plan (and practice) for KDE 4 is not to add a k preffix in a gratuitous way. FWIW the only new project that I remember now that starts with k, for KDE 4, is KDE 4 itself. :-)
Certainly the existing projects will retain their names, it would be foolish to do it otherwise, but please don't put intention where it is not.
Fair enough. Like I said, I have plenty of KApps in my Gnome menu and like them so I was basing my thoughts on observation from the outside of both camps. I am glad that there are efforts to make both desktop apps work together and not drive them apart. In the end, having things Just Work (TM) is what is best for the end user.
/Mike
On Friday 05 January 2007 3:14 pm, Michael Wiktowy wrote:
Fair enough. Like I said, I have plenty of KApps in my Gnome menu and like them so I was basing my thoughts on observation from the outside of both camps. I am glad that there are efforts to make both desktop apps work together and not drive them apart. In the end, having things Just Work (TM) is what is best for the end user.
I agree and I applaud the effort make by the different teams under freedesktops.org umbrella. It is not easy but we are the winners in the end. :-)
/Mike
On 04.01.2007 22:22, Rahul Sundaram wrote:
Jesse Keating wrote:
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely used "community contributed" spin of Fedora. That's why (IMHO) its named specifically with "KDE" whereas the official spin is just "Desktop". If you don't know what "KDE" or "GNOME" is, you wouldn't know to choose it. Desktop is a good generic name that is understandable. However if you already know and prefer KDE, you know to get the KDE spin.
It would be consistent to have something like Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition) It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
+1 from me to this as a long term Gnome user that's not much interested in KDE; but I know others are.
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
CU thl
On Fri, 2007-01-05 at 07:55 +0100, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately, the Board has to own this issue.
Jeremy
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board. FESCo is really responsible for making sure the full repo is there, and the Distribution cabal (hopefully there will be more than just me) is responsible for taking content from that repository and creating installable iso sets from it.
On Fri, 2007-01-05 at 09:44 -0500, Jesse Keating wrote:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board. FESCo is really responsible for making sure the full repo is there, and the Distribution cabal (hopefully there will be more than just me) is responsible for taking content from that repository and creating installable iso sets from it.
I think it's a little more complicated than that. Or maybe not. If there are two committees, one for the repo and one for the release, they need to work really closely together. The release cabal needs a stable set of packages to build the releases from and the repo cabal would need to enforce that. E.g. feature freeze, string freeze, etc.
Personally, I'd rather see the current FESCo and Core cabal merged into a single entity that shares both responsibilities. The Packaging Committee would certainly still exist to come up with the packaging guidelines, so that wouldn't change. And you immediately get community involvement in the content of the release isos, which is what I think Jessie meant by "hopefully there will be more than just me". Just my $0.02.
josh
On Friday 05 January 2007 10:01, Josh Boyer wrote:
Personally, I'd rather see the current FESCo and Core cabal merged into a single entity that shares both responsibilities. The Packaging Committee would certainly still exist to come up with the packaging guidelines, so that wouldn't change. And you immediately get community involvement in the content of the release isos, which is what I think Jessie meant by "hopefully there will be more than just me". Just my $0.02.
Keep in mind that it's just adding more people to a committee who may not care about other things such as sponsorship stuff, policy related to packages, various other stuff that FESCO current has to vote on. Its adding more people, making quorum harder to reach, especially when they might not have any interest/knowledge of whats being voted on.
Personally I don't like a "commitee" for each little task that needs done. I'm much more a fan of "hey these are the people doing the work, make sure they talk to eachother, and report progress somewhere". So to that end, I'm going to continue doing work, and reporting progress to places like the Fedora Board, mailing lists, blogs, whatever.
On Fri, 2007-01-05 at 10:09 -0500, Jesse Keating wrote:
On Friday 05 January 2007 10:01, Josh Boyer wrote:
Personally, I'd rather see the current FESCo and Core cabal merged into a single entity that shares both responsibilities. The Packaging Committee would certainly still exist to come up with the packaging guidelines, so that wouldn't change. And you immediately get community involvement in the content of the release isos, which is what I think Jessie meant by "hopefully there will be more than just me". Just my $0.02.
Keep in mind that it's just adding more people to a committee who may not care about other things such as sponsorship stuff, policy related to packages, various other stuff that FESCO current has to vote on. Its adding more people, making quorum harder to reach, especially when they might not have any interest/knowledge of whats being voted on.
I said their responsibilities should be merged. I didn't say they should necessarily be merged in in their current states.
Personally I don't like a "commitee" for each little task that needs done.
Enforcement of policies and release engineering aren't little tasks. You know that.
I'm much more a fan of "hey these are the people doing the work, make sure they talk to eachother, and report progress somewhere". So to that end, I'm going to continue doing work, and reporting progress to places like the Fedora Board, mailing lists, blogs, whatever.
Sure. Great. Yet unless you plan on being the benevolent dictator of the iso releases, you will need to know what you're working towards. Which includes package selections, etc. Do you plan on deciding the content all by yourself? I doubt it.
josh
On Fri, 2007-01-05 at 09:27 -0600, Josh Boyer wrote:
On Fri, 2007-01-05 at 10:09 -0500, Jesse Keating wrote:
On Friday 05 January 2007 10:01, Josh Boyer wrote:
Personally, I'd rather see the current FESCo and Core cabal merged into a single entity that shares both responsibilities. The Packaging Committee would certainly still exist to come up with the packaging guidelines, so that wouldn't change. And you immediately get community involvement in the content of the release isos, which is what I think Jessie meant by "hopefully there will be more than just me". Just my $0.02.
Keep in mind that it's just adding more people to a committee who may not care about other things such as sponsorship stuff, policy related to packages, various other stuff that FESCO current has to vote on. Its adding more people, making quorum harder to reach, especially when they might not have any interest/knowledge of whats being voted on.
I said their responsibilities should be merged. I didn't say they should necessarily be merged in in their current states.
Actually, re-reading my own email I really did say "the current FESCo and Core cabal..". I meant the responsibilities though, not necessarily the actual committees themselves. Sorry for the confusion.
josh
Jesse Keating schrieb:
On Friday 05 January 2007 10:01, Josh Boyer wrote:
Personally, I'd rather see the current FESCo and Core cabal merged into a single entity that shares both responsibilities. The Packaging Committee would certainly still exist to come up with the packaging guidelines, so that wouldn't change. And you immediately get community involvement in the content of the release isos, which is what I think Jessie meant by "hopefully there will be more than just me". Just my $0.02.
Keep in mind that it's just adding more people to a committee who may not care about other things such as sponsorship stuff, policy related to packages, various other stuff that FESCO current has to vote on. Its adding more people, making quorum harder to reach, especially when they might not have any interest/knowledge of whats being voted on.
Yeah, true, that problematic.
Personally I don't like a "commitee" for each little task that needs done. I'm much more a fan of "hey these are the people doing the work, make sure they talk to eachother, and report progress somewhere". [...]
Yes, in an ideal world that should work. In a small Core-world it seems to have worked well, too. But I don't think it will work in a big community project...
Just my 2 cent.
Cu thl
Josh Boyer schrieb:
On Fri, 2007-01-05 at 09:44 -0500, Jesse Keating wrote:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board. FESCo is really responsible for making sure the full repo is there, and the Distribution cabal (hopefully there will be more than just me) is responsible for taking content from that repository and creating installable iso sets from it.
I think it's a little more complicated than that.
I think it is.
Or maybe not. If there are two committees, one for the repo and one for the release, they need to work really closely together.
And that often sucks. Even with FESCo and the Packaging Committee (they are practically on the same level currently, so none of the two can give the other orders [yes, we normally should not give orders, but sometimes it might be helpfull]) there were some situations where one was pointing to the other "you have to solve this particular issue". That was a bit problematic, and I'd like to avoid a similar situations in the future as much as possible.
The release cabal needs a stable set of packages to build the releases from and the repo cabal would need to enforce that. E.g. feature freeze, string freeze, etc.
Personally, I'd rather see the current FESCo and Core cabal merged into a single entity that shares both responsibilities.
+1
The Packaging Committee would certainly still exist to come up with the packaging guidelines, so that wouldn't change.
It should be clear that it remains FESCo's job to enforce the stuff the packaging committee decides. But FESCo should be able to say "Packaging Committee, work out rules for foo, as we have a packaging problem here that needs to be solved, and you guys know best about this kind of stuff is handled"
[...]
CU thl
Le Ven 5 janvier 2007 16:01, Josh Boyer a écrit :
On Fri, 2007-01-05 at 09:44 -0500, Jesse Keating wrote:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board. FESCo is really responsible for making sure the full repo is there, and the Distribution cabal (hopefully there will be more than just me) is responsible for taking content from that repository and creating installable iso sets from it.
I think it's a little more complicated than that. Or maybe not. If there are two committees, one for the repo and one for the release, they need to work really closely together. The release cabal needs a stable set of packages to build the releases from and the repo cabal would need to enforce that. E.g. feature freeze, string freeze, etc.
My feeling is somehow different. I'd really love to have a clear separation between the group that makes long-term transverse decisions and the group responsible for driving a particular release (with perhaps given Fedora's short lifecycle & usual manager burnout different groups for different releases).
That's the only way you'll get clear release focus
Regards,
Jesse Keating schrieb:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board.
Nearly the same wording as jeremy two minutes earlier ;-)
Well, I can live with that, but could one of the Board members (I'm sure at least Rahul, Jeremy and rdieter will read this mail) bring this issue up in the next Board meeting please?
FESCo is really responsible for making sure the full repo is there, and the Distribution cabal (hopefully there will be more than just me) is responsible for taking content from that repository and creating installable iso sets from it.
/me in that case I'm really wondering why I got two rough ACKs from rdieter and gdk when I wrote "the things that the Core cabal did and does (release process, bring the tree in shape for release, plan feature to work on or the next release, ...) somehow need to be done by FESCo then" at https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00248...
/me more and more feels uncomfortable with the situation and now is even more confused -- its getting more and more unclear who is responsible for what in this whole game. Hopefully we sort this out soon...
CU thl
Thorsten Leemhuis wrote:
Jesse Keating schrieb:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board.
Nearly the same wording as jeremy two minutes earlier ;-)
Well, I can live with that, but could one of the Board members (I'm sure at least Rahul, Jeremy and rdieter will read this mail) bring this issue up in the next Board meeting please?
Yes. I will. My opinion as I have already expressed before several times is that we need to replace the core cabal and FESCo with a technical steering committee with public irc weekly meetings and only escalate issues to the board if there is heavy conflict. The more board members are involved in micro management, the less we will be thinking about long term changes.
Rahul
Rahul Sundaram schrieb:
Thorsten Leemhuis wrote:
Jesse Keating schrieb:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board.
Nearly the same wording as jeremy two minutes earlier ;-) Well, I can live with that, but could one of the Board members (I'm sure at least Rahul, Jeremy and rdieter will read this mail) bring this issue up in the next Board meeting please?
Yes. I will.
Many thanks.
My opinion as I have already expressed before several times is that we need to replace the core cabal and FESCo with a technical steering committee with public irc weekly meetings and only escalate issues to the board if there is heavy conflict. The more board members are involved in micro management, the less we will be thinking about long term changes.
Fully agreed.
CU thl
Thorsten Leemhuis wrote:
On 04.01.2007 22:22, Rahul Sundaram wrote:
It would be consistent to have something like Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition) It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
+1 from me to this as a long term Gnome user that's not much interested in KDE; but I know others are.
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Sounds like the consensus (so far) is the Board. You can now count 2 Board members (Rahul and me) for being in favor of this. (:
-- Rex
Rex Dieter schrieb:
Thorsten Leemhuis wrote:
On 04.01.2007 22:22, Rahul Sundaram wrote:
It would be consistent to have something like Fedora Desktop (GNOME edition) and Fedora Desktop (KDE edition) It's confusing and discriminatory to call one of the spins as the desktop when you have more (which is likely to increase) than one desktop oriented spins.
+1 from me to this as a long term Gnome user that's not much interested in KDE; but I know others are.
This issue brings up a interesting question: Which board has the power to influence and adjust this particular naming scheme in our new "merged" world? FESCo or the Fedora Board?
Sounds like the consensus (so far) is the Board.
BTW, in case it wasn't clear from my other mails: I actually agree that the Boards is the best place for this sort of decision, as it's more a political "big picture" thing. Nevertheless I think it's FESCo (or better: it not yet defined successor) job to work out the details (maybe in a FESCo-distribution-sub-committee) and present it to the Boards to get an ACK from it.
You can now count 2 Board members (Rahul and me) for being in favor of this. (:
thx.
Cu thl
Vnpenguin wrote:
- Add the nouveau drivers for nVidia cards
"nouveau" ? :-)
I am not sure whether that was a serious question or a joke I didnt understand. If its a serious question OP did refer to http://fedoraproject.org/wiki/Releases/7/Features which has the details. If it's a joke I would be curious to know what it is.
Rahul
Le vendredi 05 janvier 2007 à 02:45 +0530, Rahul Sundaram a écrit :
Vnpenguin wrote:
- Add the nouveau drivers for nVidia cards
"nouveau" ? :-)
I am not sure whether that was a serious question or a joke I didnt understand. If its a serious question OP did refer to http://fedoraproject.org/wiki/Releases/7/Features which has the details. If it's a joke I would be curious to know what it is.
Rahul
I think it can be a pun... As "nouveau" means "new" in French, I first understood it as : "Add the new drivers for nVidia cards".
The term nouveau here refers to the name of the new nVidia driver, which is a new technology. I think finding a word of French origin was seen odd from Vnpenguin and that he thought it was a mistake in the writing.
"Add the new nouveau drivers for nVidia cards"
... is gorgeous to read :p
On Friday 05 January 2007 10:21 am, Thomas Canniot wrote:
I think it can be a pun... As "nouveau" means "new" in French, I first understood it as : "Add the new drivers for nVidia cards".
FWIW and due to the strange relations between French and English, nouveau is also an English word:
http://www.m-w.com/dictionary/nouveau
On 1/5/07, José Matos wrote:
FWIW and due to the strange relations between French and English, nouveau is also an English word:
Some of the core team of nouveau are french, that may be the reason :) http://nouveau.freedesktop.org/wiki/ This is the homepage of nouveau, a project which aims at producing Open Source 3D drivers for nVidia cards. "nouveau" [nuvo] is the french word for "new"
http://icps.u-strasbg.fr/~marchesin/perso/
Chitlesh
On 1/5/07, Thomas Canniot thomas.canniot@laposte.net wrote:
I think it can be a pun... As "nouveau" means "new" in French, I first understood it as : "Add the new drivers for nVidia cards".
The term nouveau here refers to the name of the new nVidia driver, which is a new technology. I think finding a word of French origin was seen odd from Vnpenguin and that he thought it was a mistake in the writing.
"Add the new nouveau drivers for nVidia cards"
... is gorgeous to read :p
Thank you Thomas, I see now it's the _name_ of new driver :) Cool !
Cheers,
Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
jpo
Jose Pedro Oliveira wrote:
Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
... and we need to decide on whether we need to use cdrkit or stay with the current version of cdrecord in Fedora. Let me know if a RFE is required.
Rahul
On Thursday 04 January 2007 16:12, Rahul Sundaram wrote:
... and we need to decide on whether we need to use cdrkit or stay with the current version of cdrecord in Fedora. Let me know if a RFE is required.
Or libburn, which is in Extras.
On Thu, 2007-01-04 at 16:27 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 16:12, Rahul Sundaram wrote:
... and we need to decide on whether we need to use cdrkit or stay with the current version of cdrecord in Fedora. Let me know if a RFE is required.
Or libburn, which is in Extras.
libburn is only a library, and a slowly progressing one (latest release was in Feb 2004). There was a project takeover at some point (some unknown guy suddenly announced a project revival and a new web site at libburn.pykix.org, not minding that the project was still active...) which instead resulted in a fork called libburnia which integrates a cdrecord-like frontend. I'm not sure how usable it is, but it's certainly far from being as mature as cdrtools (or cdrkit.)
On Thursday 04 January 2007 17:15, Mark Rosenstand wrote:
There was a project takeover at some point (some unknown guy suddenly announced a project revival and a new web site at libburn.pykix.org, not minding that the project was still active...) which instead resulted in a fork called libburnia which integrates a cdrecord-like frontend. I'm not sure how usable it is, but it's certainly far from being as mature as cdrtools (or cdrkit.)
Yes, this is what is in Extras right now, I packaged it up at the request of these folks. http://libburnia.pykix.org/ is the "new" URL now.
They've been progressing quite well from what I can tell. Sure, probably not ready for Fedora by F7, but something to investigate by more knowledgeable people.
On Thu, 2007-01-04 at 17:17 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 17:15, Mark Rosenstand wrote:
There was a project takeover at some point (some unknown guy suddenly announced a project revival and a new web site at libburn.pykix.org, not minding that the project was still active...) which instead resulted in a fork called libburnia which integrates a cdrecord-like frontend. I'm not sure how usable it is, but it's certainly far from being as mature as cdrtools (or cdrkit.)
Yes, this is what is in Extras right now, I packaged it up at the request of these folks. http://libburnia.pykix.org/ is the "new" URL now.
Heh. I've been the maintainer of the real libburn (http://icculus.org/burn/) for another distro for a long time, and the forker claimed that my package was broken since it referenced the "old" URL of the project.
That was after calling for project revival[0] and after the libburn project leader dismissed it[1]. It's cool that they now switched to another name, perhaps the Fedora package could do the same.
They've been progressing quite well from what I can tell. Sure, probably not ready for Fedora by F7, but something to investigate by more knowledgeable people.
Agreed. The idea of a generic CD-writing library seems like a worthy long-term goal, but for FL7, cdrkit, being a free drop-in replacement of S(ch)illy's programs, could probably do the trick.
[0] http://lists.freedesktop.org/archives/libburn/2006-July/000434.html [1] http://lists.freedesktop.org/archives/libburn/2006-August/000444.html
Rahul Sundaram (sundaram@fedoraproject.org) said:
Jose Pedro Oliveira wrote:
Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
... and we need to decide on whether we need to use cdrkit or stay with the current version of cdrecord in Fedora. Let me know if a RFE is required.
What needs to happen is that someone needs to Step Up and claim repsonsibility for these things with a plan for fixing them (on fedora-devel-list, and then on the wiki). I'm perfectly willing to add features to the list, but we need people who are going to be accountable for them.
Bill
On Thu, 2007-01-04 at 21:54 -0500, Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Jose Pedro Oliveira wrote:
Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
... and we need to decide on whether we need to use cdrkit or stay with the current version of cdrecord in Fedora. Let me know if a RFE is required.
What needs to happen is that someone needs to Step Up and claim repsonsibility for these things with a plan for fixing them (on fedora-devel-list, and then on the wiki). I'm perfectly willing to add features to the list, but we need people who are going to be accountable for them.
Please do. Feel free to add the Releases/FeatureTexLive to the list of features for F7 assigning me there as an owner, with "Needs done by: Test2".
Thanks, Jindrich
Jindrich Novy (jnovy@redhat.com) said:
What needs to happen is that someone needs to Step Up and claim repsonsibility for these things with a plan for fixing them (on fedora-devel-list, and then on the wiki). I'm perfectly willing to add features to the list, but we need people who are going to be accountable for them.
Please do. Feel free to add the Releases/FeatureTexLive to the list of features for F7 assigning me there as an owner, with "Needs done by: Test2".
*cough* It's a wiki. :)
Bill
On Fri, 2007-01-05 at 14:07 -0500, Bill Nottingham wrote:
Jindrich Novy (jnovy@redhat.com) said:
What needs to happen is that someone needs to Step Up and claim repsonsibility for these things with a plan for fixing them (on fedora-devel-list, and then on the wiki). I'm perfectly willing to add features to the list, but we need people who are going to be accountable for them.
Please do. Feel free to add the Releases/FeatureTexLive to the list of features for F7 assigning me there as an owner, with "Needs done by: Test2".
*cough* It's a wiki. :)
heh, done ;-)
* Jose Pedro Oliveira (2007-01-04 21:13 +0000) said: ^^^^^^^^^^^^^^^^^^^
Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
It will be a pity if it is not fixed for Fedora 7 ;)
On Thu, 2007-01-04 at 21:13 +0000, Jose Pedro Oliveira wrote:
Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
There was a private discussion among teTeX maintainers from mainline distributions related to teTeX replacement involving TeXLive upstream which resulted in a series of TeXLive styles which should function as a teTeX replacement, you can find out more at:
http://tug.org/svn/texlive/trunk/Master/texmf/tpm/ (look for tetex)
I'm still in close contact with TeXLive upstream and the current work is focused on how to package it in the best way.
Jindrich
On 1/5/07, Jindrich Novy jnovy@redhat.com wrote:
I'm still in close contact with TeXLive upstream and the current work is focused on how to package it in the best way.
Are you looking for community co-maintainers to help you out with this after the core+extras merge? The tex stack is pretty important for scientific publications, there are probably several competent contributors out here on the other side of the fenceline who are concerned enough to invest time in keeping the functionality working.
-jef
On Fri, 2007-01-05 at 13:45 -0900, Jeff Spaleta wrote:
On 1/5/07, Jindrich Novy jnovy@redhat.com wrote:
I'm still in close contact with TeXLive upstream and the current work is focused on how to package it in the best way.
Are you looking for community co-maintainers to help you out with this after the core+extras merge? The tex stack is pretty important for scientific publications, there are probably several competent contributors out here on the other side of the fenceline who are concerned enough to invest time in keeping the functionality working.
Definitely, the community involvement here is appreciated as I cannot cover all the TeX features because of their vast range, so I'm really open to any suggestions/testings/proposals from you guys.
Feel free to subscribe to freshly created feature page if you want to help or to stay informed:
http://fedoraproject.org/wiki/Releases/FeatureTexLive
Jindrich
Bill Nottingham wrote,
If you've got new features you'd like to add, and you are willing to do the work, or have the ability to get others to do the work for you, we can add them too. Note that Test2 is the feature freeze.
NetworkManager 0.7? Allegedly due RSN, with a set of new and updated features which looks like it'll finally make NM usable (by me, at least),
http://live.gnome.org/NetworkManagerToDo
Cheers,
Miles
On Thursday 04 January 2007 13:50, Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Whats needed to add Fedora Directory Server to the List? that would be a great additional tool to have in F7
On Thursday 04 January 2007 17:47, Dennis Gilmore wrote:
Whats needed to add Fedora Directory Server to the List? that would be a great additional tool to have in F7
Somebody to be on the hook to make sure it gets done in time for the deadlines.
From Releases/7 page:
I've got this great feature idea!
OK. Are you going to work on it? Can you cajole/force someone else to be Accountable? Then we'll add it!
On Thursday 04 January 2007 16:49, Jesse Keating wrote:
On Thursday 04 January 2007 17:47, Dennis Gilmore wrote:
Whats needed to add Fedora Directory Server to the List? that would be a great additional tool to have in F7
Somebody to be on the hook to make sure it gets done in time for the deadlines.
From Releases/7 page:
I've got this great feature idea!
OK. Are you going to work on it? Can you cajole/force someone else to be Accountable? Then we'll add it!
Jarod Wilson and I will be accountable to ensure that Fedora Directory Server is available in F7
Jesse Keating wrote:
On Thursday 04 January 2007 17:47, Dennis Gilmore wrote:
Whats needed to add Fedora Directory Server to the List? that would be a great additional tool to have in F7
Somebody to be on the hook to make sure it gets done in time for the deadlines.
From Releases/7 page:
I've got this great feature idea!
OK. Are you going to work on it? Can you cajole/force someone else to be Accountable? Then we'll add it!
http://wtogami.livejournal.com/12517.html This todo list still applies to get FDS into Fedora proper. Toshio already did one part.
Warren Togami wtogami@redhat.com
On Saturday 06 January 2007 1:48 am, Warren Togami wrote:
Jesse Keating wrote:
OK. Are you going to work on it? Can you cajole/force someone else to be Accountable? Then we'll add it!
Ive added FDS to the list ;)
http://wtogami.livejournal.com/12517.html This todo list still applies to get FDS into Fedora proper. Toshio already did one part.
When talking to the developers of FDS yesterday We may hit a snag. the java bits. still need suns java. Red Hat's Java team have made them build with gcj but they don't run 100% yet with it. So we will have everything for the ldap server in but we may not be able to get the admin tools in.
So if we have any Java developers looking for something to do. We could use help porting the admin console to gcj.
On Sat, 2007-06-01 at 08:53 -0600, Dennis Gilmore wrote:
When talking to the developers of FDS yesterday We may hit a snag. the java bits. still need suns java. Red Hat's Java team have made them build with gcj but they don't run 100% yet with it.
I'm pretty sure Tom Fitzsimmons told me that things do indeed work. Tom?
Andrew
On Saturday 06 January 2007 9:47 am, Andrew Overholt wrote:
On Sat, 2007-06-01 at 08:53 -0600, Dennis Gilmore wrote:
When talking to the developers of FDS yesterday We may hit a snag. the java bits. still need suns java. Red Hat's Java team have made them build with gcj but they don't run 100% yet with it.
I'm pretty sure Tom Fitzsimmons told me that things do indeed work. Tom?
Andrew,
I really hope that they do.
Andrew Overholt wrote:
On Sat, 2007-06-01 at 08:53 -0600, Dennis Gilmore wrote:
When talking to the developers of FDS yesterday We may hit a snag. the java bits. still need suns java. Red Hat's Java team have made them build with gcj but they don't run 100% yet with it.
I'm pretty sure Tom Fitzsimmons told me that things do indeed work. Tom?
I'm not sure what is meant by "100%" here. There is an issue with the console script that causes gij to OOM on startup:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183962
Once that problem is fixed (early this year, according to the bug report), the tools will run well -- I did some smoke testing just before FC-6 was released.
If there are other issues running FDS on GCJ, please file them in Red Hat Bugzilla against the java-1.4.2-gcj-compat component.
Tom
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
Also, maybe it could be worth considering allowing to use fcron instead of anacron+cron.
-- Pat
On Thursday 04 January 2007 10:56 pm, Patrice Dumas wrote:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
I remember the opposite. :-)
March is a too tight schedule for F7, and java is heavy-weight by any account. ;-) (I am referring the package relations not run-time...)
-- Pat
On Thu, 2007-01-04 at 23:10 +0000, José Matos wrote:
On Thursday 04 January 2007 10:56 pm, Patrice Dumas wrote:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
I remember the opposite. :-)
March is a too tight schedule for F7, and java is heavy-weight by any account. ;-) (I am referring the package relations not run-time...)
FYI: Jpackage [1] has been packaging SUN's java (distributed as a .nosrc.rpm that reuires SUN's .bin file to build the .rpm) for a long time. Seems to play nice with alternatives, naming, location of files etc. Perhaps worth a look for Fedora 7?
[1] http://mirrors.dotsrc.org/jpackage/1.6/generic/non-free/repodata/repoview/ja...
">" == Saikat Guha saikat@cs.cornell.edu writes:
FYI: Jpackage [1] has been packaging SUN's java (distributed as a .nosrc.rpm that reuires SUN's .bin file to build the .rpm) for a long time. Seems to play nice with alternatives, naming, location of files etc. Perhaps worth a look for Fedora 7?
It isn't free software.
We'll be taking a close look at OpenJDK once all the bits have been released. I'm pretty sure this will miss Fedora 7 and have to wait for Fedora 8.
Tom
Patrice Dumas (pertusus@free.fr) said:
Also, maybe it could be worth considering allowing to use fcron instead of anacron+cron.
IIRC, fcron natively supports SELinux. Maybe get the Extras fcron maintainer (aportal@univ-montp2.fr) and the Core vixie-cron/anacron maintainer (mmaslano@redhat.com) together and see what would need to be done to migrate and see what the benefits would be?
Bill
* Patrice Dumas pertusus@free.fr [2007-01-04 18:01]:
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
Andrew
On Friday 05 January 2007 12:21, Andrew Overholt wrote:
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
Can the n-v-r be fixed to adhere to the guidelines sooner rather than later? (:
On Fri, 2007-05-01 at 13:04 -0500, Jesse Keating wrote:
On Friday 05 January 2007 12:21, Andrew Overholt wrote:
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
Can the n-v-r be fixed to adhere to the guidelines sooner rather than later? (:
It already is and has been for a while. It's JPackage-inherited packages that need fixing.
Andrew
On Saturday 06 January 2007 10:48, Andrew Overholt wrote:
Can the n-v-r be fixed to adhere to the guidelines sooner rather than later? (:
It already is and has been for a while. It's JPackage-inherited packages that need fixing.
I must have been looking at an old version, sorry about that.
Hi,
Andrew Overholt wrote:
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
FYI, I have renamed this page to http://fedoraproject.org/wiki/Releases/FeatureEclipsePlugins to match the template and other specifications.
Rahul
Patrice Dumas wrote:
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
All parts of Sun Java will not be released until a time where it is far too late to be usable in Fedora 7. Sun Java might require additional work to be properly integrated, which is perhaps likely in Fedora 8.
Warren Togami wtogami@redhat.com
On Sat, 2007-06-01 at 02:50 -0500, Warren Togami wrote:
Patrice Dumas wrote:
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
All parts of Sun Java will not be released until a time where it is far too late to be usable in Fedora 7. Sun Java might require additional work to be properly integrated, which is perhaps likely in Fedora 8.
I think he means 1.5 language support in gcj et al.
Andrew
Bill Nottingham írta:
It's time to bite the bullet. ...
- Add wireless firmware for all the chipsets we can
Speaking of hardware that needs firmware to work at all, how about adding the foo2zjs driver and the firmware for the cheap HP LaserJet series like 1000/1015/1018/1020?
Best regards, Zoltán Böszorményi
On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
Bill Nottingham írta:
It's time to bite the bullet. ...
- Add wireless firmware for all the chipsets we can
Speaking of hardware that needs firmware to work at all, how about adding the foo2zjs driver and the firmware for the cheap HP LaserJet series like 1000/1015/1018/1020?
Is it freely redistributable? URL?
josh
Josh Boyer írta:
On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
Bill Nottingham írta:
It's time to bite the bullet. ...
- Add wireless firmware for all the chipsets we can
Speaking of hardware that needs firmware to work at all, how about adding the foo2zjs driver and the firmware for the cheap HP LaserJet series like 1000/1015/1018/1020?
Is it freely redistributable? URL?
josh
http://foo2zjs.rkkda.com/ http://foo2zjs.rkkda.com/foo2zjs.tar.gz The COPYING file says:
-----------------8<---------------------------- Copyright HP... sihp1000.img (2001) sihp1005.img (2002) sihp1018.img (2005) sihp1020.img (2005) hpclj2600n-0.icm (2003) 3700
Copyright Konica Minolta... CPWL12W.icm (1998) CPWL24W.icm (1998) CPWL6W.icm (1998) DL2200RGB.icm (1999) DL2312.icm (2001) DL2324.icm (2001) km2430_0.icm (2003) km2430_1.icm (2003) km2430_2.icm (2003)
Copyright Rick Richardson. All Rights Reserved. hpclj2600n-1.icm (2006)
Everything else is... ----------------------------------------------------------------------------- GNU GENERAL PUBLIC LICENSE Version 2, June 1991 ... (regular GPLv2 COPYING continues) -----------------8<----------------------------
So, the same treatment would apply to the HP firmwares and HP/Minolta ICM files as to the wireless firmwares: find lawyers and have the vendors to make them redistributable. Anyway, these files are on their respective driver CDs, with the slight exception of the sihp* files above. In my case, on the driver disk for the HP 1020, these files can be found:
hp1020.img hp1022.img hp1022n.img
These have to be run through the "arm2hpdl" program which foo2zjs provides and which prepends a small PJL header:
And I know that the driver is in Livna, but it provides neither the HP firmware files nor the needed hotplug/udev scripts to upload them when the system encounters such a printer on boot or when the printer is turned on. foo2zjs has them in the .tar.gz. Well, for the case of HP 1020, it carries an older firmware release (20040929) and the newer one (20050318) that's on the driver disk makes the printer speedier.
And in case you wonder, the whole ZJStream protocol is open so a GPL driver could have been written. Link can be found on the foo2zjs homepage.
Best regards, Zoltán Böszörményi
On 1/5/07, Zoltan Boszormenyi zboszor@freemail.hu wrote:
Josh Boyer írta:
On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
Bill Nottingham írta:
It's time to bite the bullet. ...
- Add wireless firmware for all the chipsets we can
Speaking of hardware that needs firmware to work at all, how about adding the foo2zjs driver and the firmware for the cheap HP LaserJet series like 1000/1015/1018/1020?
Is it freely redistributable? URL?
josh
http://foo2zjs.rkkda.com/ http://foo2zjs.rkkda.com/foo2zjs.tar.gz The COPYING file says:
...
And in case you wonder, the whole ZJStream protocol is open so a GPL driver could have been written. Link can be found on the foo2zjs homepage.
It depends on jbigkit, which is allegedly patent encumbered.
Deji
Deji Akingunola írta:
On 1/5/07, Zoltan Boszormenyi zboszor@freemail.hu wrote:
Josh Boyer írta:
On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
Bill Nottingham írta:
It's time to bite the bullet. ...
- Add wireless firmware for all the chipsets we can
Speaking of hardware that needs firmware to work at all, how about adding the foo2zjs driver and the firmware for the cheap HP LaserJet series like 1000/1015/1018/1020?
Is it freely redistributable? URL?
josh
http://foo2zjs.rkkda.com/ http://foo2zjs.rkkda.com/foo2zjs.tar.gz The COPYING file says:
...
And in case you wonder, the whole ZJStream protocol is open so a GPL driver could have been written. Link can be found on the foo2zjs homepage.
It depends on jbigkit, which is allegedly patent encumbered.
Deji
Of which half of them is expired already, some of them are pending (they aren't valid yet) and for the rest (which _might apply_, not known apply) HP and Konica/Minolta must have payed the bill already and the driver is for their printers.
Until proper support for all HP printers, hplip is literally only a lip service. :-(
Best regards, Zoltán Böszörményi
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
<snip>
Nothing about anaconda? In particular, the partitioning phase is (more or less) the same since FC1 and not having something in place to resize an existing (most likely ntfs) partition is a big drawback when compared to other distros.
Just for the records, I used ntfsresize successfully with the last laptop I installed FC6 onto.
On Fri, 2007-01-05 at 00:25 +0100, Gianluca Sforna wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
<snip>
Nothing about anaconda? In particular, the partitioning phase is (more or less) the same since FC1 and not having something in place to resize an existing (most likely ntfs) partition is a big drawback when compared to other distros.
Handling resize nicely is going to require a bit of rethinking and reworking of the entire partitioning interface (not to mention the backend code). Given resource constraints, there's just not really a good way to get to something that's feature complete without losing big pieces in time for the feature freeze at test2.
It's definitely something on the bigger picture roadmap for anaconda, but this just isn't going to be the release where it's reasonable for it to happen.
Jeremy
On 1/5/07, Jeremy Katz katzj@redhat.com wrote:
Handling resize nicely is going to require a bit of rethinking and reworking of the entire partitioning interface
What if someone (ie. me) provide some mockups of a potential interface for doing that? Is there a dedicated development list for anaconda to interact with?
(not to mention the backend code).
Which admittedly, I did never look at...
Given resource constraints, there's just not really a good way to get to something that's feature complete without losing big pieces in time for the feature freeze at test2.
I see. However, I think this is important enough so it deserves to be started, so at least it could be ready for proper testing in time from F8
It's definitely something on the bigger picture roadmap for anaconda, but this just isn't going to be the release where it's reasonable for it to happen.
ACK
On Fri, 2007-01-05 at 08:58 +0100, Gianluca Sforna wrote:
On 1/5/07, Jeremy Katz katzj@redhat.com wrote:
Handling resize nicely is going to require a bit of rethinking and reworking of the entire partitioning interface
What if someone (ie. me) provide some mockups of a potential interface for doing that? Is there a dedicated development list for anaconda to interact with?
Yes:
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Keith.
On Fri, 2007-01-05 at 08:58 +0100, Gianluca Sforna wrote:
On 1/5/07, Jeremy Katz katzj@redhat.com wrote:
Handling resize nicely is going to require a bit of rethinking and reworking of the entire partitioning interface
What if someone (ie. me) provide some mockups of a potential interface for doing that? Is there a dedicated development list for anaconda to interact with?
Yep, there's anaconda-devel-list and I'm all for starting some discussion around it now, getting some mockups going, etc.
Thanks!
Jeremy
On 05.01.2007 03:59, Jeremy Katz wrote:
On Fri, 2007-01-05 at 00:25 +0100, Gianluca Sforna wrote: [...]
<snip> Nothing about anaconda? In particular, the partitioning phase is (more or less) the same since FC1 and not having something in place to resize an existing (most likely ntfs) partition is a big drawback when compared to other distros.
Handling resize nicely is going to require a bit of rethinking and reworking of the entire partitioning interface (not to mention the backend code). Given resource constraints, there's just not really a good way to get to something that's feature complete without losing big pieces in time for the feature freeze at test2.
It's definitely something on the bigger picture roadmap for anaconda, but this just isn't going to be the release where it's reasonable for it to happen.
Just FYI: Vista will afaik be able to resize NTFS filesystems on it own. Thus you should be able to free some space on a hard-disk with Vista and install Linux to it. So I'm wondering if we need the resize-feature in the future as much as we do today.
Sure, there are a lot of XP machines out in the wild, but most of the *new* machines (where the ability to resize NTFS is mostly needed) will ship with Vista by F8.
CU thl
On 1/5/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 05.01.2007 03:59, Jeremy Katz wrote:
On Fri, 2007-01-05 at 00:25 +0100, Gianluca Sforna wrote: [...]
<snip> Nothing about anaconda? In particular, the partitioning phase is (more or less) the same since FC1 and not having something in place to resize an existing (most likely ntfs) partition is a big drawback when compared to other distros.
Handling resize nicely is going to require a bit of rethinking and reworking of the entire partitioning interface (not to mention the backend code). Given resource constraints, there's just not really a good way to get to something that's feature complete without losing big pieces in time for the feature freeze at test2.
It's definitely something on the bigger picture roadmap for anaconda, but this just isn't going to be the release where it's reasonable for it to happen.
Just FYI: Vista will afaik be able to resize NTFS filesystems on it own.
I was not aware. thanks.
Thus you should be able to free some space on a hard-disk with Vista and install Linux to it. So I'm wondering if we need the resize-feature in the future as much as we do today.
Given that, I guess there will be less pressure to add that feature. However, I think it's global value is still quite the same, because it gives users the ability to install Fedora on a brand new PC without intermediate steps in an external environment: just insert the install DVD and boot.
tor, 04 01 2007 kl. 14:50 -0500, skrev Bill Nottingham:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
There was for a long time interest in replacing the much hated esd with another solution. Pulseaudio was suggested and is already in Extras. To be a drop in replacement I think all we need is a package for the gstreamer sink.
Would this be feasble for Fedora 7?
Here's to making Fedora 7 the best release yet!
No objections
- David Nielsen
On Fri, 2007-01-05 at 01:12 +0100, David Nielsen wrote:
tor, 04 01 2007 kl. 14:50 -0500, skrev Bill Nottingham:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
There was for a long time interest in replacing the much hated esd with another solution. Pulseaudio was suggested and is already in Extras. To be a drop in replacement I think all we need is a package for the gstreamer sink.
Would this be feasble for Fedora 7?
I had some issues with pulseaudio playing with other apps that I regrettably didn't file (reinstalled with FC6 soon after and forgot about it.) I think esd releases the sound device after a period of inactivity which allows other applications to use it whereas pulseaudio doesn't. Not sure though as I tried running padsp <PROGRAM> and some other things with no change.
Regardless, we should evaluate how well pulseaudio plays with other programs early in the cycle so we have a chance to find and fix any little compatibility issues that crop up.
-Toshio
On Thu, 2007-01-04 at 16:25 -0800, Toshio Kuratomi wrote:
Regardless, we should evaluate how well pulseaudio plays with other programs early in the cycle so we have a chance to find and fix any little compatibility issues that crop up.
This is on Monty's TODO list for F7. I don't know if he put the writeup of his "fix audio" plans in the wiki yet (he has recently been distracted by more important things), but I'm sure he'll be happy about any help with testing and evaluation.
Matthias
tor, 04 01 2007 kl. 19:34 -0500, skrev Matthias Clasen:
On Thu, 2007-01-04 at 16:25 -0800, Toshio Kuratomi wrote:
Regardless, we should evaluate how well pulseaudio plays with other programs early in the cycle so we have a chance to find and fix any little compatibility issues that crop up.
This is on Monty's TODO list for F7. I don't know if he put the writeup of his "fix audio" plans in the wiki yet (he has recently been distracted by more important things), but I'm sure he'll be happy about any help with testing and evaluation.
Monty, Please shine your rays of enlightenment on us, your meager subjects. Also I'll happily test anything so long as it's reasonably easily installable.
- David
Bill Nottingham wrote:
30 January 2007 | F7 Test1 Release
I'm torn between really wanting to test the Test Releases on my hardware, and the need to have an at least relatively stable OS to do my work.
So if y'all could add a Live CD to the Fedora Test releases, that would be awesome. It won't test the installer or the disk storage, but it will be able to test pretty much everything else.
On Thu, 2007-01-04 at 17:36 -0800, Florin Andrei wrote:
So if y'all could add a Live CD to the Fedora Test releases, that would be awesome. It won't test the installer or the disk storage, but it will be able to test pretty much everything else.
That's the plan. http://fedoraproject.org/wiki/FedoraLiveCD
Jeremy
Bill Nottingham wrote:
20 February 2007 | F7 FEATURE Freeze
Maybe I'm partial to this topic, but I really like the idea of an inotify daemon:
https://www.redhat.com/archives/fedora-extras-list/2007-January/thread.html#...
Let's say - if I whip up an RPM tonight and submit it to Extras, what would be the chances to get a sponsor and push the package to Extras in time for the F7 feature freeze?
Pretty please? :-)
On Thu, 2007-01-04 at 17:48 -0800, Florin Andrei wrote:
Bill Nottingham wrote:
20 February 2007 | F7 FEATURE Freeze
Maybe I'm partial to this topic, but I really like the idea of an inotify daemon:
https://www.redhat.com/archives/fedora-extras-list/2007-January/thread.html#...
Let's say - if I whip up an RPM tonight and submit it to Extras, what would be the chances to get a sponsor and push the package to Extras in time for the F7 feature freeze?
That needs to be worked out yet. Extras is a rolling release at the moment. In the Brave New World, we'll need to seriously look at that and figure out what to do.
josh
On 1/4/07, Florin Andrei florin@andrei.myip.org wrote:
Let's say - if I whip up an RPM tonight and submit it to Extras, what would be the chances to get a sponsor
If you do not want to wait for a sponsor I will take lead maintainership of the package and work with you through the review process. You can be co-maintainer and get and file bugreports and can send any potential cvs commits to me for me to process via bugzilla. This will get it into extras asap, but does not address the question of release engineering such an item into publishable install targets.
-jef
Jeff Spaleta wrote:
If you do not want to wait for a sponsor I will take lead maintainership of the package and work with you through the review process. You can be co-maintainer and get and file bugreports and can send any potential cvs commits to me for me to process via bugzilla.
Sounds good to me.
This will get it into extras asap, but does not address the question of release engineering such an item into publishable install targets.
Well, at least it's there so people can play with it and try and see just how far it can go.
On Thu, 2007-01-04 at 18:20 -0800, Florin Andrei wrote:
Jeff Spaleta wrote:
If you do not want to wait for a sponsor I will take lead maintainership of the package and work with you through the review process. You can be co-maintainer and get and file bugreports and can send any potential cvs commits to me for me to process via bugzilla.
Sounds good to me.
This will get it into extras asap, but does not address the question of release engineering such an item into publishable install targets.
Well, at least it's there so people can play with it and try and see just how far it can go.
This would be awesome. I know that I want to look at it some and this will save me some up-front effort ;)
Jeremy
On Thursday 04 January 2007 21:02, Jeff Spaleta wrote:
but does not address the question of release engineering such an item into publishable install targets.
Show that the software works and is desireable to have in say Desktop or Server spins, and we'll make it happen.
On 1/4/07, Jesse Keating jkeating@redhat.com wrote:
Show that the software works and is desireable to have in say Desktop or Server spins, and we'll make it happen.
I doubt that those two bins will be big enough to fill the space of interest 2 years out. Does a completely open source version of k12ltsp fit in either bin? Does a professional open source audio studio operating system fit in either bin? Does a home media center-centric open operating system fit into either bin? Does an open source orbiting deathray operating system fit into either bin?
-jef
On Thursday 04 January 2007 23:18, Jeff Spaleta wrote:
I doubt that those two bins will be big enough to fill the space of interest 2 years out. Does a completely open source version of k12ltsp fit in either bin? Does a professional open source audio studio operating system fit in either bin? Does a home media center-centric open operating system fit into either bin? Does an open source orbiting deathray operating system fit into either bin?
Sure, farther down the road there might be other targets. For F7, we're focusing on Desktop and Server, and a KDE.
Is the core problem simply one of space? If all packages fit on HD-DVD (Blu-Ray) for example then we no longer need separate spins? (forgetting for now that there is no mass market penetration of said devices).
Will there ever be a removable storage unit large enough to hold all available packages, probably, as flash moves along.
I have not bothered with DVDs for a long time, preferring instead to use network boot as it's just cleaner/faster for me. It can be handy though to build ones own DVDs with specific package sets.
Although with 8,16,32GB flash memory more common I'd rather just use a simple application to select the packages I want a "burn" then to a USB storage device, from which I could then boot/install.
On Friday 05 January 2007 00:19, Naoki wrote:
Is the core problem simply one of space? If all packages fit on HD-DVD (Blu-Ray) for example then we no longer need separate spins? (forgetting for now that there is no mass market penetration of said devices).
Not space on medium, but amount to download. Why should somebody download 8gigs worth for an install that would fit on one/two CDs?
On Fri, 2007-01-05 at 08:05 -0500, Jesse Keating wrote:
On Friday 05 January 2007 00:19, Naoki wrote:
Is the core problem simply one of space? If all packages fit on HD-DVD (Blu-Ray) for example then we no longer need separate spins? (forgetting for now that there is no mass market penetration of said devices).
Not space on medium, but amount to download. Why should somebody download 8gigs worth for an install that would fit on one/two CDs?
If download size is the overriding issue, we should think about beefing up repotrack and publishing recommended configs for its use for various cases - if the differences in emphasis and audience for desktop and server are the issue, we'd probably want to think beyond a pared down package set.
David
Em Qui, 2007-01-04 às 14:50 -0500, Bill Nottingham escreveu:
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
I'm quite new to Fedora (came from other distros), and some things I'll be discussing bellow may already be implemented somehow, but I couldn't easily find them. If that's the case, please ignore me.
Speaking about wireless, I would have two suggestions:
#1 - Having some *very* easy way to switch between NetworkManager and regular 'ifup'. I know SUSE has something similar: you just go into their network configuration tool and select a radio box (Use NM / Use ifup). It would be cool for laptop users that roam a lot (like me). If there is nobody available to work on that, I would be glad to if you point me the directions on whom should I coordinate with.
#2 - Improving the system-config-securitylevel. This I need to split in two:
#2.1 - The current way of setting up firewall rules is excessively simple, and makes it very difficult to have simple things like internet connection sharing for a home network. It would be very cool to have the ability to configure a simple 1:N NAT and some port redirection.
#2.2 - The local firewall has no logging feature. It's quite difficult for a user/home admin to know why something is not working if you don't have any kind of logs about what is being dropped because of the firewall blocking. Probably having logging enabled by default could be just overkill (most end-users won't care about it), but having a way to enable/configure logging would help those people a lot.
I think I can help with most things suggested, I just need to know where to start. :)
Mauricio Teixeira (netmask) (netmask@webset.net) said:
#1 - Having some *very* easy way to switch between NetworkManager and regular 'ifup'. I know SUSE has something similar: you just go into their network configuration tool and select a radio box (Use NM / Use ifup). It would be cool for laptop users that roam a lot (like me). If there is nobody available to work on that, I would be glad to if you point me the directions on whom should I coordinate with.
I'm not sure this is the right answer - it's certainly the wrong question to be asking the user in general. For the cases that NM hits now, we'd want to fix any cases that would cause people to want to switch to ifup, at least.
Bill
On Thursday 04 January 2007 8:59 pm, Bill Nottingham wrote:
Mauricio Teixeira (netmask) (netmask@webset.net) said:
#1 - Having some *very* easy way to switch between NetworkManager and regular 'ifup'. I know SUSE has something similar: you just go into their network configuration tool and select a radio box (Use NM / Use ifup). It would be cool for laptop users that roam a lot (like me). If there is nobody available to work on that, I would be glad to if you point me the directions on whom should I coordinate with.
I'm not sure this is the right answer - it's certainly the wrong question to be asking the user in general. For the cases that NM hits now, we'd want to fix any cases that would cause people to want to switch to ifup, at least.
I think the right Answer is to make NM cover all cases. where you don't need to go to other tools. I use entirely NM. but i could see instances where i need to choose between multiple static wired configs that NM may not be the easiest tool to use.
On Thu, Jan 04, 2007 at 09:18:00PM -0600, Dennis Gilmore wrote:
I'm not sure this is the right answer - it's certainly the wrong question to be asking the user in general. For the cases that NM hits now, we'd want to fix any cases that would cause people to want to switch to ifup, at least.
I think the right Answer is to make NM cover all cases.
The biggest hurdle afaics, is that NM treats a network connection as a per-user thing rather than a system wide thing. Having to log in before you can use the network is busted.
Dave
On Thursday 04 January 2007 9:21 pm, Dave Jones wrote:
On Thu, Jan 04, 2007 at 09:18:00PM -0600, Dennis Gilmore wrote:
I'm not sure this is the right answer - it's certainly the wrong question to be asking the user in general. For the cases that NM hits now, we'd want to fix any cases that would cause people to want to switch to ifup, at least.
I think the right Answer is to make NM cover all cases.
The biggest hurdle afaics, is that NM treats a network connection as a per-user thing rather than a system wide thing. Having to log in before you can use the network is busted.
according to the TODO list for 0.7 working before you log in is one of the goals. Which will help when using network authentication.
On Thu, 2007-01-04 at 21:25 -0600, Dennis Gilmore wrote:
On Thursday 04 January 2007 9:21 pm, Dave Jones wrote:
On Thu, Jan 04, 2007 at 09:18:00PM -0600, Dennis Gilmore wrote:
I'm not sure this is the right answer - it's certainly the wrong question to be asking the user in general. For the cases that NM hits now, we'd want to fix any cases that would cause people to want to switch to ifup, at least.
I think the right Answer is to make NM cover all cases.
The biggest hurdle afaics, is that NM treats a network connection as a per-user thing rather than a system wide thing. Having to log in before you can use the network is busted.
according to the TODO list for 0.7 working before you log in is one of the goals. Which will help when using network authentication.
It would be nice if NM supported profiles too. Like "Home" and "Office" where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want for the two different networks.
Maybe that isn't one of the goals, but it'd make moving around a hell of a lot easier.
josh
On Thu, 2007-01-04 at 23:42 -0500, Bill Nottingham wrote:
Josh Boyer (jwboyer@jdub.homelinux.org) said:
It would be nice if NM supported profiles too. Like "Home" and "Office" where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
you mean dhcp, not dns.
and overrides for both are common in most network configuration applications.
-sv
On Thu, 2007-01-04 at 23:42 -0500, Bill Nottingham wrote:
Josh Boyer (jwboyer@jdub.homelinux.org) said:
It would be nice if NM supported profiles too. Like "Home" and "Office" where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
DHCP, yes. However some companies, and personal home routers for that matter, totally suck in that regard.
My router decides to assign itself as the primary DNS server and then routinely pukes after a few minutes of that. So I pre-pend something in /etc/dhclient-eth0.conf to work around that, but then my laptop sucks at work because it isn't using the site DNS servers.
And at home, my router is doesn't actually resolve the machine names, so I add names to /etc/hosts. Which again breaks when I switch networks. It's very annoying. Having something like a "Home" profile that would switch to the right settings when selected vs. an "Office" or "External" profile would be highly welcome.
josh
On Thursday 04 January 2007 23:58, Josh Boyer wrote:
And at home, my router is doesn't actually resolve the machine names, so I add names to /etc/hosts. Which again breaks when I switch networks. It's very annoying. Having something like a "Home" profile that would switch to the right settings when selected vs. an "Office" or "External" profile would be highly welcome.
I actually wrote an app that did this for me, before NM was created. It was a neat way to learn some pygtk/glade stuff. Of course, it only made sense to me so I never really let the code see the light of day.
On Fri, 2007-01-05 at 00:04 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 23:58, Josh Boyer wrote:
And at home, my router is doesn't actually resolve the machine names, so I add names to /etc/hosts. Which again breaks when I switch networks. It's very annoying. Having something like a "Home" profile that would switch to the right settings when selected vs. an "Office" or "External" profile would be highly welcome.
I actually wrote an app that did this for me, before NM was created. It was a neat way to learn some pygtk/glade stuff. Of course, it only made sense to me so I never really let the code see the light of day.
Share the source man! Or send it to Dan and tell him to integrate it into NM :)
josh
On Friday 05 January 2007 06:53, Josh Boyer wrote:
Share the source man! Or send it to Dan and tell him to integrate it into NM
Oh no, this was horrible stuff. A very simple UI that was a radio button between work and home, with an apply/cancel button under it. The backend would do a series of os.system calls to iwconfig, dhclient, echos into resolve.conf, stuff like that. It wouldn't be very useful, and I think the code for it is long lost in one of my reinstalls.
On Fri, 2007-01-05 at 08:18 -0500, Jesse Keating wrote:
On Friday 05 January 2007 06:53, Josh Boyer wrote:
Share the source man! Or send it to Dan and tell him to integrate it into NM
Oh no, this was horrible stuff. A very simple UI that was a radio button between work and home, with an apply/cancel button under it. The backend would do a series of os.system calls to iwconfig, dhclient, echos into resolve.conf, stuff like that. It wouldn't be very useful, and I think the code for it is long lost in one of my reinstalls.
Config for 0.7 will be much more flexible in addition to allowing system-wide configuration. The page here explains at least the _conceptual_ structure of how the configuration should work. Some of the implementation details are up in the air until we figure out how they relate to/fit in with PolicyKit, which we're looking at now.
http://live.gnome.org/NetworkManagerConfiguration
One note should be that 'dns-search' should probably be a string array and not just a string item. But once the details are figured out there'll be a spec for these key/value pairs and their type.
Really, it's just an array of "connection" objects, each of which itself is an array of dictionary objects that contains key/value pairs that describe the settings. It doesn't really matter how they are stored, whether in GConf, KConfig, LDAP, text files, on a smartcard, or whatever, as long as it can be spit back out in this pretty simple format.
Dan
On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
Config for 0.7 will be much more flexible in addition to allowing system-wide configuration. The page here explains at least the _conceptual_ structure of how the configuration should work. Some of the implementation details are up in the air until we figure out how they relate to/fit in with PolicyKit, which we're looking at now.
Hmmm, looks like this kind of definition is going to have a hard time working in real setups. Lemme give you some examples of what I use on a regular basis:
- eth0 has a static IP in 192.44.78/24, DNS, gw, etc, and also has a static route allowing to use the interface for 192.168.87.0/24 using its static IP which is not in 192.168.*
- eth0 has a static IP in 192.44.78/24, DNS, gw. eth1 has an IP in 192.168.87/24.
- eth0 and eth1 have the same static IP in 192.168.87/24, eth1 has the route for 192.168.87/24, eth0 has only a route for 192.44.78/24.
To that you can sometimes add another interface on another private network for iSCSI. Interfaces, addresses, routes, gateways and upper-level services (DNS, NIS...) are orthogonal for a reason. NM needs to keep this orthogonality at the lower configuration level otherwise there is no chance it will work in real-world setups. Nobody has the intellectual capacity to imagine all the possible setups that exist out there, especially when historical reasons are involved.
Even on laptops you can have fun scenarios, for instance I've more than once used my laptop which was connected to an hotel's internet through ethernet as a wifi relay for my SO's laptop. So don't forget ad-hoc wifi connections, masquerading and forwarding ;-)
OG.
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
Config for 0.7 will be much more flexible in addition to allowing system-wide configuration. The page here explains at least the _conceptual_ structure of how the configuration should work. Some of the implementation details are up in the air until we figure out how they relate to/fit in with PolicyKit, which we're looking at now.
Hmmm, looks like this kind of definition is going to have a hard time working in real setups. Lemme give you some examples of what I use on a regular basis:
Which is why it's good to have feedback :) So at least the 'gateway' item needs to be re-thought, since that's route-based and not interface/connection specific underneath. Though to many users it appears so, because they do not have complex setups, the flexibility needs to be there underneath.
- eth0 has a static IP in 192.44.78/24, DNS, gw, etc, and also has a static route allowing to use the interface for 192.168.87.0/24 using its static IP which is not in 192.168.*
Can you explain the configuration for these in a bit more detail? So in this example, eth0 has a static IP and DNS, gw, etc are _also_ in the same 192.44.78/24 network. But you've added a route that pushes traffic for the 192.168.87.0/24 network over eth0 (which has no IP address in that network range), correct?
- eth0 has a static IP in 192.44.78/24, DNS, gw. eth1 has an IP in 192.168.87/24.
I think the config would cover that, no? Each interface can obviously have different IP settings (addr, mask, bcast). DNS is a bit different because the order of resolvers in resolv.conf determines some of the behavior, even if the routing rules determine which interface the requests against a particular server actually go out on.
What does the output of /sbin/route -n look like for this case?
- eth0 and eth1 have the same static IP in 192.168.87/24, eth1 has the route for 192.168.87/24, eth0 has only a route for 192.44.78/24.
I'm not sure the configuration mentioned above excludes this possibility, can you be more specific on how you couldn't configure your interfaces this way in the proposed config structure? (keeping in mind that gateway should be handled differently than the config structure says)
Dan
To that you can sometimes add another interface on another private network for iSCSI. Interfaces, addresses, routes, gateways and upper-level services (DNS, NIS...) are orthogonal for a reason. NM needs to keep this orthogonality at the lower configuration level otherwise there is no chance it will work in real-world setups.
Well, there's certainly a relationship between interfaces and addresses
Nobody has the intellectual capacity to imagine all the possible setups that exist out there, especially when historical reasons are involved.
Even on laptops you can have fun scenarios, for instance I've more than once used my laptop which was connected to an hotel's internet through ethernet as a wifi relay for my SO's laptop. So don't forget ad-hoc wifi connections, masquerading and forwarding ;-)
OG.
On Fri, Jan 05, 2007 at 10:46:49AM -0500, Dan Williams wrote:
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
- eth0 has a static IP in 192.44.78/24, DNS, gw, etc, and also has a static route allowing to use the interface for 192.168.87.0/24 using its static IP which is not in 192.168.*
Can you explain the configuration for these in a bit more detail? So in this example, eth0 has a static IP and DNS, gw, etc are _also_ in the same 192.44.78/24 network. But you've added a route that pushes traffic for the 192.168.87.0/24 network over eth0 (which has no IP address in that network range), correct?
Yep. These are the desktop boxes, which want to be able to talk to the boxes on the internal network.
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:08:74:a8:7c:f8 brd ff:ff:ff:ff:ff:ff inet 192.44.78.23/24 brd 192.44.78.255 scope global eth0 inet6 fe80::208:74ff:fea8:7cf8/64 scope link valid_lft forever preferred_lft forever
192.168.87.0/24 dev eth0 scope link 192.44.78.0/24 dev eth0 proto kernel scope link src 192.44.78.23 169.254.0.0/16 dev eth0 scope link default via 192.44.78.22 dev eth0
- eth0 has a static IP in 192.44.78/24, DNS, gw. eth1 has an IP in 192.168.87/24.
I think the config would cover that, no? Each interface can obviously have different IP settings (addr, mask, bcast). DNS is a bit different because the order of resolvers in resolv.conf determines some of the behavior, even if the routing rules determine which interface the requests against a particular server actually go out on.
Yeah, it's globally more standard. It was to show that it's not a given every interface has dns/nis/etc. These are the servers which are connected to both networks equally.
Note btw that the internal network has a (friggin' fast) secondary NIS server, and the configuration is broadcast. So most of the times these boxes use the NIS server on eth1 rather than eth0.
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:5a:c3:ee brd ff:ff:ff:ff:ff:ff inet 192.44.78.93/24 brd 192.44.78.255 scope global eth0 inet6 fe80::230:48ff:fe5a:c3ee/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:5a:c3:ef brd ff:ff:ff:ff:ff:ff inet 192.168.87.89/24 brd 192.168.87.255 scope global eth1 inet6 fe80::230:48ff:fe5a:c3ef/64 scope link valid_lft forever preferred_lft forever
192.168.87.0/24 dev eth1 proto kernel scope link src 192.168.87.89 192.44.78.0/24 dev eth0 proto kernel scope link src 192.44.78.93 169.254.0.0/16 dev eth1 scope link 224.0.0.0/4 dev eth1 scope link default via 192.44.78.22 dev eth0
What does the output of /sbin/route -n look like for this case?
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.87.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.44.78.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1 0.0.0.0 192.44.78.22 0.0.0.0 UG 0 0 0 eth0
- eth0 and eth1 have the same static IP in 192.168.87/24, eth1 has the route for 192.168.87/24, eth0 has only a route for 192.44.78/24.
I'm not sure the configuration mentioned above excludes this possibility, can you be more specific on how you couldn't configure your interfaces this way in the proposed config structure? (keeping in mind that gateway should be handled differently than the config structure says)
I'm not sure it doesn't, I'm not sure it does, but the orthogonality between address and route is interesting. These are the internal boxes, with no gw access (they're not routable anyway).
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:14:5e:86:81:58 brd ff:ff:ff:ff:ff:ff inet 192.168.87.171/24 brd 192.168.87.255 scope global eth0 inet6 fe80::214:5eff:fe86:8158/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:14:5e:86:81:59 brd ff:ff:ff:ff:ff:ff inet 192.168.87.171/24 scope global eth1 inet6 fe80::214:5eff:fe86:8159/64 scope link valid_lft forever preferred_lft forever
192.168.87.0/24 dev eth1 proto kernel scope link src 192.168.87.171 192.44.78.0/24 dev eth0 scope link 169.254.0.0/16 dev eth1 scope link 224.0.0.0/4 dev eth1 scope link
OG.
Dan Williams wrote:
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
Hmmm, looks like this kind of definition is going to have a hard time working in real setups. Lemme give you some examples of what I use on a regular basis:
Which is why it's good to have feedback :) So at least the 'gateway' item needs to be re-thought, since that's route-based and not interface/connection specific underneath. Though to many users it appears so, because they do not have complex setups, the flexibility needs to be there underneath.
It is at least important to be able to add multiple addresses to one (physical) interface. I personally don't like the old eth0:0 eth0:1 (...), but prefer the new iproute2 style, but I guess I can live with aliases as long as it is easy to add/remove them.
Rgds.
On Fri, 2007-01-05 at 17:09 +0100, Ola Thoresen wrote:
Dan Williams wrote:
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
Hmmm, looks like this kind of definition is going to have a hard time working in real setups. Lemme give you some examples of what I use on a regular basis:
Which is why it's good to have feedback :) So at least the 'gateway' item needs to be re-thought, since that's route-based and not interface/connection specific underneath. Though to many users it appears so, because they do not have complex setups, the flexibility needs to be there underneath.
It is at least important to be able to add multiple addresses to one (physical) interface.
Yep! That's obviously required.
I personally don't like the old eth0:0 eth0:1 (...), but prefer the new
That format is vile.
iproute2 style, but I guess I can live with aliases as long as it is easy to add/remove them.
Dan
On 1/5/07, Dan Williams dcbw@redhat.com wrote:
On Fri, 2007-01-05 at 17:09 +0100, Ola Thoresen wrote:
It is at least important to be able to add multiple addresses to one (physical) interface.
Yep! That's obviously required.
I personally don't like the old eth0:0 eth0:1 (...), but prefer the new
That format is vile.
iproute2 style, but I guess I can live with aliases as long as it is easy to add/remove them.
Could someone illuminate me on the non-vile iproute2 style of doing this (give me the right jargon to Google)? Is it that you can call the aliases anything you want with a mapping/iface combo in /etc/network/interfaces? Apparently, I was being vile and didn't know it and want to reform.
/Mike
Michael Wiktowy (michael.wiktowy@gmail.com) said:
Could someone illuminate me on the non-vile iproute2 style of doing this (give me the right jargon to Google)? Is it that you can call the aliases anything you want with a mapping/iface combo in /etc/network/interfaces? Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Bill
Bill Nottingham wrote:
Michael Wiktowy (michael.wiktowy@gmail.com) said:
Could someone illuminate me on the non-vile iproute2 style of doing this (give me the right jargon to Google)? Is it that you can call the aliases anything you want with a mapping/iface combo in /etc/network/interfaces? Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Not having done aliases via iproute2 shouldn't that be 192.168.1.1/32 above?
Eric J. Feldhusen (efeldhusen.lists@gmail.com) said:
Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Not having done aliases via iproute2 shouldn't that be 192.168.1.1/32 above?
Well, /<whatever your netmask is>.
Bill
On 1/5/07, Bill Nottingham notting@redhat.com wrote:
Michael Wiktowy (michael.wiktowy@gmail.com) said:
Could someone illuminate me on the non-vile iproute2 style of doing this (give me the right jargon to Google)? Is it that you can call the aliases anything you want with a mapping/iface combo in /etc/network/interfaces? Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Thanks ... I'll have to investigate how this survives the DHCP client as my point to using aliases in the past was to ensure that I had a static IP that I can reach from the outside via port forwarded ssh through a router that seems to mysteriously change internal IP assignments when it uses DHCP.
/Mike
Hi Bill,
On Fri, 05 Jan 2007, Bill Nottingham wrote:
Michael Wiktowy (michael.wiktowy@gmail.com) said:
Could someone illuminate me on the non-vile iproute2 style of doing this (give me the right jargon to Google)? Is it that you can call the aliases anything you want with a mapping/iface combo in /etc/network/interfaces? Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132925 time to get rid of this bug until Fedora 7. And maybe you're able to fix the problem with aliases (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132912), too. ;-)
Greetings, Robert
Ola Thoresen (redhat@olen.net) said:
It is at least important to be able to add multiple addresses to one (physical) interface. I personally don't like the old eth0:0 eth0:1 (...), but prefer the new iproute2 style, but I guess I can live with aliases as long as it is easy to add/remove them.
Aliases (eth0:0) need to die. Of course, I've been saying that for years and haven't killed them yet. :/
Bill
On Fri, 2007-01-05 at 16:09 -0500, Bill Nottingham wrote:
Ola Thoresen (redhat@olen.net) said:
It is at least important to be able to add multiple addresses to one (physical) interface. I personally don't like the old eth0:0 eth0:1 (...), but prefer the new iproute2 style, but I guess I can live with aliases as long as it is easy to add/remove them.
Aliases (eth0:0) need to die. Of course, I've been saying that for years and haven't killed them yet. :/
SUSE moved to iproute2 style aliases awhile back and it would be nice to have one less difference in distributions (especially for me, since I write books covering Linux distros).
The only drawback is you can no longer depend on /sbin/ifconfig to show you the all the IPs bound to a NIC. This is especially jarring for sys admins moving from a-flavor-of-UNIX to Linux. It would be nice if ifconfig displayed iproute2 style aliases.
Dax Kelson Guru Labs
On Fri, Jan 05, 2007 at 03:54:17PM +0100, Olivier Galibert wrote:
Even on laptops you can have fun scenarios, for instance I've more than once used my laptop which was connected to an hotel's internet through ethernet as a wifi relay for my SO's laptop. So don't forget ad-hoc wifi connections, masquerading and forwarding ;-)
Yep. I have fun scenarios on laptops all the time Wireless is usually the way out, and when I plug something into the wired port it's often just a point-to-point connection to some device that I need to talk to. Some times there might be a dhcp/tftp server running on that interface (so, say I can do a PXE network install of my laptop),
That or I want to transfer a file fast from some machine on the wired network over GigE, some times configuring the interface manually, some times with DHCP.
Since this happens pretty regularly, I can't really use NM. + bugzilla #209009 + something bad with NM & aironet scanning, so it only sees one AP for a long time after resuming the laptop (iwlist eth1 scan shows everything. Not sure if it's actually an applet thing, if I manually tell it to join a network that works fine.
Maybe some command line scripts for controlling NM would be useful.
nm-join-network <network> <wep key (optional, should look in the keyring too if that's available)>
and it'd then try very hard to connect to that network.
nm-freeze-config and it'd stop trying to change the network config even if I plug/unplug a cable.
Well, those are my use cases, probably pretty rare in general, but it's what I need personally ;)
Well ok, occasionally there's the need for having an ad-hoc wlan + sharing a GPRS/3G bluetooth connection. Typically requiring some RTFM to figure out what the iptables masquerade syntax was again :) I would love some connection sharing configuration thingy. Outside the scope of NM, sure, but if NM is to be the way to configure all network devices at some point, such an application should interact well with it :)
On Thu, Jan 04, 2007 at 11:42:27PM -0500, Bill Nottingham wrote:
It would be nice if NM supported profiles too. Like "Home" and "Office" where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
From DNS? How's *that* gonna work without a resolv.conf? :)
But anyway, man do I hate it when a DHCP connection overrides the default search path I put in there. When I type an unqualified name on my laptop, I expect it to always mean the same thing. Sigh.
On Fri, 2007-01-05 at 00:07 -0500, Matthew Miller wrote:
On Thu, Jan 04, 2007 at 11:42:27PM -0500, Bill Nottingham wrote:
It would be nice if NM supported profiles too. Like "Home" and "Office" where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
From DNS? How's *that* gonna work without a resolv.conf? :)
But anyway, man do I hate it when a DHCP connection overrides the default search path I put in there. When I type an unqualified name on my laptop, I expect it to always mean the same thing. Sigh.
I agree fully. I don't mind (in fact, I'm glad) that the name server changes. However, don't touch my DNS search path.
It would be great if NetworkManager allowed defining a DNS domain that could be prepended to whatever the DHCP sent (if any). Windows allows this.
This can be done with dhclient-XXX.conf
Dax Kelson Guru Labs
On Thursday 04 January 2007 9:18 pm, Dennis Gilmore wrote:
I think the right Answer is to make NM cover all cases. where you don't need to go to other tools. I use entirely NM. but i could see instances where i need to choose between multiple static wired configs that NM may not be the easiest tool to use.
I should add i use NM on laptops only. servers and desktops I dont use it.
On Thu, 2007-01-04 at 21:24 -0600, Dennis Gilmore wrote:
On Thursday 04 January 2007 9:18 pm, Dennis Gilmore wrote:
I think the right Answer is to make NM cover all cases. where you don't need to go to other tools. I use entirely NM. but i could see instances where i need to choose between multiple static wired configs that NM may not be the easiest tool to use.
I should add i use NM on laptops only. servers and desktops I dont use it.
FWIW: I have never managed to get NM working anywhere for me. After having played with it on laptops, desktops/network-clients and my home network's server, I found my myself having disabled NM everywhere.
Ralf
Ralf Corsepius wrote:
On Thu, 2007-01-04 at 21:24 -0600, Dennis Gilmore wrote:
On Thursday 04 January 2007 9:18 pm, Dennis Gilmore wrote:
I think the right Answer is to make NM cover all cases. where you don't need to go to other tools. I use entirely NM. but i could see instances where i need to choose between multiple static wired configs that NM may not be the easiest tool to use.
I should add i use NM on laptops only. servers and desktops I dont use it.
FWIW: I have never managed to get NM working anywhere for me. After having played with it on laptops, desktops/network-clients and my home network's server, I found my myself having disabled NM everywhere.
I use it on both laptops and desktops. I still get frequent cases of having to select my wireless network multiple times until it successfully connects, and the fact it doesn't connect until the user logs in means once I'm logged I have to restart some services such as squid. NM has the thankless job of having to deal with wireless drivers of extremely varying quality and stability.
My laptop chipset is well suppobrted (aironet), but on the desktop it's a nightmare. I have a PCI madwifi-based card that's stable but yields horrible signal strength, and two of those little USB wifi adapters. One (Netgear MA111v2) works with ndiswrapper but systematically crashes the kernel on shutdown, the other (a Sagem XG-760N) is only supported by the very unstable zd1211b driver. *sigh*.
#2 - Improving the system-config-securitylevel. This I need to split in two:
I maintain s-c-securitylevel, so I'll address this.
#2.1 - The current way of setting up firewall rules is excessively simple, and makes it very difficult to have simple things like internet connection sharing for a home network. It would be very cool to have the ability to configure a simple 1:N NAT and some port redirection.
These sorts of features would be handy, I agree. If they can be simple one checkbox sorts of things, that's even better. Getting into the port redirection stuff takes s-c-securitylevel down a path I don't think we want to go, though. It's my understanding that it's never been developed as the be-all firewall configuration tool that does everything you'd want to do. I certainly have not maintained it as such.
A checkbox for enabling NAT would be decent, but I don't know how much farther beyond that I want to go.
#2.2 - The local firewall has no logging feature. It's quite difficult for a user/home admin to know why something is not working if you don't have any kind of logs about what is being dropped because of the firewall blocking. Probably having logging enabled by default could be just overkill (most end-users won't care about it), but having a way to enable/configure logging would help those people a lot.
I have an open bug about this (151647 - it's fairly old at this point) but have never gotten around to working on it since I didn't see it as a huge feature. Of course, I can go in and add it if there's that much demand. I can see it being useful for debugging firewalls.
The trick with both of these features is to add them without making the UI a nightmare to use and maintain. Maybe I should spend a while thinking about how to do it.
Two things I want to do in s-c-securitylevel (and if I ever get done reworking pykickstart, I'll get these in for 7) are:
(1) Rewrite lokkit in Python. I can hack C but I'm slower at it and I don't see it as particularly well suited to this sort of program, especially with the goofy newt stuff.
(2) Make s-c-securitylevel not destroy any customizations you make by hand. I think this is the biggest problem affecting the program right now and if I can come up with a good way to deal with it, I'll put the fix in right away. There's an open bug for this - 138143.
- Chris
On Thu, 2007-01-04 at 23:05 -0300, Mauricio Teixeira (netmask) wrote:
Em Qui, 2007-01-04 às 14:50 -0500, Bill Nottingham escreveu:
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
I'm quite new to Fedora (came from other distros), and some things I'll be discussing bellow may already be implemented somehow, but I couldn't easily find them. If that's the case, please ignore me.
Speaking about wireless, I would have two suggestions: #2 - Improving the system-config-securitylevel. This I need to split in two:
#2.1 - The current way of setting up firewall rules is excessively simple, and makes it very difficult to have simple things like internet connection sharing for a home network. It would be very cool to have the ability to configure a simple 1:N NAT and some port redirection.
Simple is good.
I'd be OK with a "NAT all traffic leaving interface X" setting, but please, do not morph it into the SuSEfirewall2 monster.
Dax Kelson Guru Labs
This is going to sound really stupid but what the heck; The nice thing about the "core" and "extras" differentiation was you knew what was "core" and what was "extra".
Without this distinction how does average Joe know that compiz is preferred over beryl, or that xmms is the option to Rhythmbox not the other way around? Just the definition inside comps.xml or something more complex?
We can give access to well over 5,000 packages in the same place but won't it be a bit of a jumble?
Also, how will this help the creation of RHEL? If Fedora is to remain the basis for RHEL will this not slightly confuse things?
On Fri, 2007-01-05 at 11:24 +0900, Naoki wrote:
This is going to sound really stupid but what the heck; The nice thing about the "core" and "extras" differentiation was you knew what was "core" and what was "extra".
Without this distinction how does average Joe know that compiz is preferred over beryl, or that xmms is the option to Rhythmbox not the other way around? Just the definition inside comps.xml or something more complex?
How does Joe user know this now? They're just using the graphical tools which (intentionally) don't show this. It's definitely an area that could deal with improvement, but differentiation based on repo isn't really the answer. There's a real opportunity to explore some new ways of showing the defaults[1]
Jeremy
[1] as well as other "interesting" information that isn't contained in the package itself, think reviews, screenshots, etc)
On 1/4/07, Jeremy Katz katzj@redhat.com wrote:
There's a real opportunity to explore some new ways of showing the defaults[1]
The definition of a "default" gets really really murky, if we are opening up installer image space and allowing the opportunity for community to step-in and attempt to maintain alternative installer target images. What's default in the Gnome-centric desktop installer target and what is default in my garunteed to be hugely popular Emacs as desktop interface installer target or to a niche installer target like a KDE desktop.... will be totally different.
-jef"replace Emacs with vi, as needed"spaleta
On Thu, 2007-01-04 at 22:06 -0500, Jeremy Katz wrote:
On Fri, 2007-01-05 at 11:24 +0900, Naoki wrote:
This is going to sound really stupid but what the heck; The nice thing about the "core" and "extras" differentiation was you knew what was "core" and what was "extra".
Without this distinction how does average Joe know that compiz is preferred over beryl, or that xmms is the option to Rhythmbox not the other way around? Just the definition inside comps.xml or something more complex?
How does Joe user know this now?
Good point, my idea of Joe user is obviously different the the "normal" My Joe user only ever uses the command line (servers).
They're just using the graphical tools which (intentionally) don't show this. It's definitely an area that could deal with improvement, but differentiation based on repo isn't really the answer. There's a real opportunity to explore some new ways of showing the defaults[1]
Cool.
On Fri, 2007-01-05 at 11:24 +0900, Naoki wrote:
This is going to sound really stupid but what the heck; The nice thing about the "core" and "extras" differentiation was you knew what was "core" and what was "extra".
<snip>
Also, how will this help the creation of RHEL? If Fedora is to remain the basis for RHEL will this not slightly confuse things?
Why is this a concern for Fedora? It's not. It's something Red Hat will have to figure out. Though I doubt it will be very hard for them to do so.
Besides, RHEL already contains a package set that spans today's Core and Extras. Exim is an example. It's in RHEL, and it's in Extras. Let the engineers at Red Hat decide what to put in RHEL. They seem to be doing a fine job already.
josh
Josh Boyer (jwboyer@jdub.homelinux.org) said:
Also, how will this help the creation of RHEL? If Fedora is to remain the basis for RHEL will this not slightly confuse things?
Why is this a concern for Fedora? It's not. It's something Red Hat will have to figure out. Though I doubt it will be very hard for them to do so.
Right.
Besides, RHEL already contains a package set that spans today's Core and Extras. Exim is an example. It's in RHEL, and it's in Extras. Let the engineers at Red Hat decide what to put in RHEL. They seem to be doing a fine job already.
I'm sure someone will be willing to argue with you on that. :)
Bill
This is going to sound really stupid but what the heck; The nice thing about the "core" and "extras" differentiation was you knew what was "core" and what was "extra".
<snip> > Also, how will this help the creation of RHEL? If Fedora is to remain > the basis for RHEL will this not slightly confuse things?
Why is this a concern for Fedora? It's not. It's something Red Hat will have to figure out. Though I doubt it will be very hard for them to do so.
Besides, RHEL already contains a package set that spans today's Core and Extras. Exim is an example. It's in RHEL, and it's in Extras. Let the engineers at Red Hat decide what to put in RHEL. They seem to be doing a fine job already.
I suspect it will be just another spin of the Fedora package tree like Desktop or Server that is then further stabilised so not much different to now. Most of the stuff that's happening in Fedora is just as relevant to rhel as it is fedora.
Peter
On Fri, 2007-01-05 at 03:01 +0000, Bojan Smojver wrote:
Bill Nottingham <notting <at> redhat.com> writes:
- Add KVM virtualization support to our tools
Does this mean that Xen is gone?
No; there's no reason the tools can't support multiple types of virtualization. That's why libvirt was started in the first place
Jeremy
Bojan Smojver (bojan@rexursive.com) said:
No; there's no reason the tools can't support multiple types of virtualization. That's why libvirt was started in the first place
Thanks.
That being said, if Xen can't be beaten into shape to reasonably follow upstream kernels, or get upstream itself....
Bill
Once upon a time, Bill Nottingham notting@redhat.com said:
Starting with Fedora 7, there is no more Core, and no more Extras; there is only Fedora. One single repository, built in the community on open source tools, assembled into whatever spins the Fedora community desires.
How will this be distributed? Will ISOs still be available that cover the whole repository? Right now, Core has release targets (and then updates), while Extras is a rolling target. Lots of users (and potential users) don't have high speed or even reliable Internet access; they need everything they install to be on physical media.
I've said this before because of previous experiences trying to help a friend with only modem access, but now I'm mailing DVDs to another friend stationed in Iraq. Having a "GNOME DVD" and a "KDE DVD" and a "Server DVD" doesn't really help, since I can't anticipate what he'll want (and all three DVDs would have a bunch in common, wasting space).
On Thursday 04 January 2007 23:18, Chris Adams wrote:
I've said this before because of previous experiences trying to help a friend with only modem access, but now I'm mailing DVDs to another friend stationed in Iraq. Having a "GNOME DVD" and a "KDE DVD" and a "Server DVD" doesn't really help, since I can't anticipate what he'll want (and all three DVDs would have a bunch in common, wasting space).
A "kitchen-sink" DVD set may be possible, but I don't expect it to be hosted by our mirror system. Perhaps bittorrent only or an easy script to generate one yourself.
On Thu, Jan 04, 2007 at 10:18:54PM -0600, Chris Adams wrote:
How will this be distributed? Will ISOs still be available that cover the whole repository? Right now, Core has release targets (and then
There will be tools that make it easy to make ISOs that cover any subset of the whole repository -- including, if for some reason you need it, the entire thing.
Bill Nottingham wrote:
[..]
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
what about updating from fc6 -> f7 ? lets say some has gnome+kde+server packages installed is it possible to upgrade to f7 *without* requiring a network connection during install? seems not until we have a Fedora 7 DVD similar to Fedora Core now.
[..] Here's to making Fedora 7 the best release yet!
go for it!
Bill
On Friday 05 January 2007 04:56, dragoran wrote:
what about updating from fc6 -> f7 ? lets say some has gnome+kde+server packages installed is it possible to upgrade to f7 *without* requiring a network connection during install? seems not until we have a Fedora 7 DVD similar to Fedora Core now.
How many Fedora 6 installs do you know of that have JUST core installed, no extras? We've long needed to be able to access Extras at upgrade time, now more than ever. Look at the crapstorm that ubuntu went through when their upgrade feature didn't take universe into account.
Jesse Keating wrote:
On Friday 05 January 2007 04:56, dragoran wrote:
what about updating from fc6 -> f7 ? lets say some has gnome+kde+server packages installed is it possible to upgrade to f7 *without* requiring a network connection during install? seems not until we have a Fedora 7 DVD similar to Fedora Core now.
How many Fedora 6 installs do you know of that have JUST core installed, no extras? We've long needed to be able to access Extras at upgrade time, now more than ever. Look at the crapstorm that ubuntu went through when their upgrade feature didn't take universe into account.
so we need a everything DVD "Fedora 7 Complete" mirros can have the iso file and loopback mount it to get the "normal tree" saving diskspace. but I doubt that many mirror will do it. we could also ship it only over bittorent.
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
so we need a everything DVD "Fedora 7 Complete" mirros can have the iso file and loopback mount it to get the "normal tree" saving diskspace. but I doubt that many mirror will do it. we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
so we need a everything DVD "Fedora 7 Complete" mirros can have the iso file and loopback mount it to get the "normal tree" saving diskspace. but I doubt that many mirror will do it. we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
You are making a assumption that the same person is using bittorrent and the installation. That's far from true. I can download using bittorrent and burn several thousand copies for friends who dont have network access.
Rahul
On Fri, Jan 05, 2007 at 08:34:52PM +0530, Rahul Sundaram wrote:
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
You are making a assumption that the same person is using bittorrent and the installation. That's far from true. I can download using bittorrent and burn several thousand copies for friends who dont have network access.
True, but in my experience, that's not the typical case. I think it'd be better to make an easy way for you to generate the DVD iso for this specific purpose than to provide a general one which will get downloaded millions of times by people who would have been better off with a network install.
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 08:34:52PM +0530, Rahul Sundaram wrote:
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
You are making a assumption that the same person is using bittorrent and the installation. That's far from true. I can download using bittorrent and burn several thousand copies for friends who dont have network access.
True, but in my experience, that's not the typical case.
You are in a place with tons of bandwidth. I am not surprised by this thinking but please dont assume this is common scenario.
I think it'd be
better to make an easy way for you to generate the DVD iso for this specific purpose than to provide a general one which will get downloaded millions of times by people who would have been better off with a network install.
The solution to people picking the wrong choice for their purpose is good documentation and guidance with tools where applicable. The only objection I heard to putting up a DVD is mirror space but we can avoid that problem by using a different name space so mirrors would have to pull it explicitly and in bittorrent. Considering that several distributions like Debian with large ISO sets has managed to get lots of mirrors, I dont think the problem of mirror space would affect us much. We should discuss this with mirror administrators rather than assuming its a problem.
Rahul
Rahul Sundaram schrieb:
The solution to people picking the wrong choice for their purpose is good documentation and guidance with tools where applicable. The only objection I heard to putting up a DVD is mirror space but we can avoid that problem by using a different name space so mirrors would have to pull it explicitly and in bittorrent. Considering that several distributions like Debian with large ISO sets has managed to get lots of mirrors, I dont think the problem of mirror space would affect us much. We should discuss this with mirror administrators rather than assuming its a problem.
What I'd like to see is some sort of yum-proxy to save bandwidth for users. E.g. let some sort of yum-procy run on a local network server; fill it's cache with what you have already from the distribution cd; clients connect to the proxy; if the package is in the cache send it back; otherwise download it from the web, send it over, and put it in the cache; now and then check if a package is still in the upstream repos; if not, drop it from the cache.
I don't think something like that exists for yum. Or did I miss that? Debian has something similar iirc -- ohh boy, I should learn python properly and implement above proxy myself...
CU thl
Thorsten Leemhuis wrote:
Rahul Sundaram schrieb:
The solution to people picking the wrong choice for their purpose is good documentation and guidance with tools where applicable. The only objection I heard to putting up a DVD is mirror space but we can avoid that problem by using a different name space so mirrors would have to pull it explicitly and in bittorrent. Considering that several distributions like Debian with large ISO sets has managed to get lots of mirrors, I dont think the problem of mirror space would affect us much. We should discuss this with mirror administrators rather than assuming its a problem.
What I'd like to see is some sort of yum-proxy to save bandwidth for users. E.g. let some sort of yum-procy run on a local network server; fill it's cache with what you have already from the distribution cd; clients connect to the proxy; if the package is in the cache send it back; otherwise download it from the web, send it over, and put it in the cache; now and then check if a package is still in the upstream repos; if not, drop it from the cache.
I don't think something like that exists for yum. Or did I miss that? Debian has something similar iirc -- ohh boy, I should learn python properly and implement above proxy myself...
Have you looked at mrepo? http://dag.wieers.com/home-made/mrepo/
Rahul
Rahul Sundaram sundaram@fedoraproject.org wrote:
[...]
Have you looked at mrepo? http://dag.wieers.com/home-made/mrepo/
Interesting, but it doesn't look exactly like what was asked...
I'd like to do the following: Net-installing machine #1 gets the stuff required for that install (only!) and caches it, from cache install machines #2 .. #30. Now update machine #1, cache updates (so they can be used to update #2 .. #30, or even for fresh installs of #31 .. #35). If machine #20 needs some extra package, get and cache that one. If some machine asks for a package, look if what is up to date and hand that over; if not, get the last version.
Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure, it'll need some smarts to figure out that a package is obsoleted by another (version) to free space, but this might be handled by hand. Disk space is inexpensive, international network access is limited and expensive here (and it is probably much worse elsewhere). And it is not fun downloading the same files 30 times, or mirroring 10 files that aren't used locally to get the one you'll install 30 times.
On Friday 05 January 2007 14:43, Horst H. von Brand wrote:
I'd like to do the following: Net-installing machine #1 gets the stuff required for that install (only!) and caches it, from cache install machines #2 .. #30. Now update machine #1, cache updates (so they can be used to update #2 .. #30, or even for fresh installs of #31 .. #35). If machine #20 needs some extra package, get and cache that one. If some machine asks for a package, look if what is up to date and hand that over; if not, get the last version.
Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure, it'll need some smarts to figure out that a package is obsoleted by another (version) to free space, but this might be handled by hand. Disk space is inexpensive, international network access is limited and expensive here (and it is probably much worse elsewhere). And it is not fun downloading the same files 30 times, or mirroring 10 files that aren't used locally to get the one you'll install 30 times.
Er, how is this not possible with a sufficiently large squid caching proxy?
...... Original Message ....... On Fri, 5 Jan 2007 14:49:09 -0500 "Jesse Keating" jkeating@redhat.com wrote:
On Friday 05 January 2007 14:43, Horst H. von Brand wrote:
I'd like to do the following: Net-installing machine #1 gets the stuff required for that install (only!) and caches it, from cache install machines #2 .. #30. Now update machine #1, cache updates (so they can be used to update #2 .. #30, or even for fresh installs of #31 .. #35). If machine #20 needs some extra package, get and cache that one. If some machine asks for a package, look if what is up to date and hand that
over;
if not, get the last version.
Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure, it'll need some smarts to figure out that a package is obsoleted by
another
(version) to free space, but this might be handled by hand. Disk space is inexpensive, international network access is limited and expensive here (and it is probably much worse elsewhere). And it is not fun downloading the same files 30 times, or mirroring 10 files that aren't used locally
to
get the one you'll install 30 times.
Er, how is this not possible with a sufficiently large squid caching proxy?
It isn't that simple.
The problem is that if client1 fetches an RPM from one mirror and client2 tries to fetch the same RPM from a different mirror, no caching is done.
As I recall, Squid uses the MD5 of the entire URI as the unique object identifier.
You need to have all the clients fetching from the same mirror AND ideally, this should happen automatically without config change on the clients.
If I bring my laptop to the office, then it should use the local network cache automatically. When I go home, it should use the mirrors like normal.
I figure I can implement that at the office with DNS hijacking plus using Squid as a transparent proxy. It is on my TODO list.
___ Dax Kelson Guru Labs Sent with my Treo (please pardon any brevity)
Thorsten Leemhuis (fedora@leemhuis.info) said:
What I'd like to see is some sort of yum-proxy to save bandwidth for users. E.g. let some sort of yum-procy run on a local network server; fill it's cache with what you have already from the distribution cd; clients connect to the proxy; if the package is in the cache send it back; otherwise download it from the web, send it over, and put it in the cache; now and then check if a package is still in the upstream repos; if not, drop it from the cache.
I don't think something like that exists for yum. Or did I miss that? Debian has something similar iirc -- ohh boy, I should learn python properly and implement above proxy myself...
Well, you *could* just do this with any specially configured web cache.
Bill
On Fri, Jan 05, 2007 at 06:19:20PM +0100, Thorsten Leemhuis wrote:
What I'd like to see is some sort of yum-proxy to save bandwidth for users. E.g. let some sort of yum-procy run on a local network server; fill it's cache with what you have already from the distribution cd; clients connect to the proxy; if the package is in the cache send it back; otherwise download it from the web, send it over, and put it in the cache; now and then check if a package is still in the upstream repos; if not, drop it from the cache.
Even better would be the use of mDNS and DNS-SD to search for such a proxy. This way, you don't need to hardcode anything in configuration files.
I don't know if yum provides enough hooks to implement such a plugin, but ideally it would look for a local proxy and fallback to the "original" repository URL if none can be found. That'd useful if you are a laptop user and only sometimes have fast local access to such a proxy. Or it would allow for graceful degradation if the proxy has died or is undergoing maintenance. Or, in a network with many systems, it can provide for load balancing, by using more than one proxy (I guess you can look at all the services discovered on the local network, not just the first one replying to your broadcast request). All you'd need to do is installing the plugin's RPM or make a convincing case for its inclusion in yum itself - not likely to happen today, but maybe in a few years the use case won't be as uncommon as it is now.
Instead of a proxy, one could also use DNS-SD to implement something closer to the P2P model, where machines on a local network search for any neighbour systems that have already downloaded updates, basically sharing the yum cache.
On Fri, 2007-01-05 at 21:01 +0100, Rudi Chiarito wrote:
Even better would be the use of mDNS and DNS-SD to search for such a proxy. This way, you don't need to hardcode anything in configuration files.
I think misa's service discovery plugin [1] would be a good starting point. Probably needs some dusting off.
David
[1] https://lists.dulug.duke.edu/pipermail/yum-devel/2006-May/002194.html
Rudi Chiarito ha scritto:
On Fri, Jan 05, 2007 at 06:19:20PM +0100, Thorsten Leemhuis wrote:
What I'd like to see is some sort of yum-proxy to save bandwidth for users. E.g. let some sort of yum-procy run on a local network server; fill it's cache with what you have already from the distribution cd; clients connect to the proxy; if the package is in the cache send it back; otherwise download it from the web, send it over, and put it in the cache; now and then check if a package is still in the upstream repos; if not, drop it from the cache.
Even better would be the use of mDNS and DNS-SD to search for such a proxy. This way, you don't need to hardcode anything in configuration files.
FYI: http://freshmeat.net/projects/apt-zeroconf/
Instead of a proxy, one could also use DNS-SD to implement something closer to the P2P model, where machines on a local network search for any neighbour systems that have already downloaded updates, basically sharing the yum cache.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Problemi di Liquidità? Con Logos Finanziaria 30.000 in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi clicca qui * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2907&d=6-1
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
so we need a everything DVD "Fedora 7 Complete" mirros can have the iso file and loopback mount it to get the "normal tree" saving diskspace. but I doubt that many mirror will do it. we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
I have a 6Mbit flatrate thats not the point, I have many boxes (4) (not connected to the internet) they should be able to be updated to. also I think a media install is faster(I prefer hdd installs but since I am using md raid its no longer possible) and safer than a networkinstall(or even worse update) over internet.
Matthew Miller schrieb:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
so we need a everything DVD "Fedora 7 Complete" mirros can have the iso file and loopback mount it to get the "normal tree" saving diskspace. but I doubt that many mirror will do it. we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
But maybe you have the bandwidth on one machine, want to burn a dvd, travel home, and install/use it there...
CU thl
DVDs are a pain, they are cumbersome and too small to fit a full OS necessitating the separate Desktop/Server/KDE spins that are currently garnering so much attention.
Fedora Core started supporting installation from a USB device with core 6, which is excellent. Although the procedure as documented ( http://fedora.redhat.com/docs/install-guide/fc6/en/sn-preparing-usb-media.ht... ) states you need to download and 'burn' the diskboot image with dd to the device. But doesn't seem to explain much after that, do you use HDD install from that device?
Considering for ~$100 you can get an 8GB USB flash or 20G HDD storage device, and USB ports have appeared on every computer since about the same time as DVD came out (USB 1.0 spec released in January 1996) it's now considerably cheaper and more practical than the combination of a DVD burner on a network attached machine, DVD-ROM drives on all the client machines, and DVD media.
So would it not make sense to have an "everything" ISO for use on removable USB devices?
Naoki (naoki@valuecommerce.com) said:
DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
So would it not make sense to have an "everything" ISO for use on removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a raw FS standpoint. You could have a torrent that just makes a directory, even.
Bill
On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
Naoki (naoki@valuecommerce.com) said:
DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
So would it not make sense to have an "everything" ISO for use on removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a raw FS standpoint. You could have a torrent that just makes a directory, even.
ISOs are convenient from a distribution standpoint just to ensure that things were downloaded correctly[1]. I can see how spending some time to make the "install from a USB device" a little bit easier could definitely have advantages. At the same time, I don't think that the areas for which DVDs are a problem will be better off with large USB storage devices.
Jeremy
[1] Also, for ensuring that people don't delete things because "I don't need that" then leading to install problems. Not that such a thing ever happened with hd tree installs :-)
On Tuesday 16 January 2007 08:36am, Jeremy Katz wrote:
On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
Naoki (naoki@valuecommerce.com) said:
DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
So would it not make sense to have an "everything" ISO for use on removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a raw FS standpoint. You could have a torrent that just makes a directory, even.
ISOs are convenient from a distribution standpoint just to ensure that things were downloaded correctly[1]. I can see how spending some time to make the "install from a USB device" a little bit easier could definitely have advantages.
Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio" that's 8GB+ (whatever) in size. That could be downloaded and extracted to wherever, be it a USB disk or a file server (NFS, etc.).
At the same time, I don't think that the areas for which DVDs are a problem will be better off with large USB storage devices.
Agreed. For those environments, network installs typically make much more sense. Even on my home systems, I do network installs when I can because it's typically faster and easier than swapping CDs or burning DVDs.
However, to set up a network installation with all available packages, I would probably just continue to create my own mirror of the released packages and of the updates repo. But I agree that having a single file to download for initial setup of such file servers would be advantageous. It could also be the "roll-your-own-fedora-spin-kit" with all fedora packages + the spin tools (to build DVD and CD ISOs).
Jeremy
[1] Also, for ensuring that people don't delete things because "I don't need that" then leading to install problems. Not that such a thing ever happened with hd tree installs :-)
Yup.
On Tue, 2007-01-16 at 09:42 -0700, Lamont Peterson wrote:
On Tuesday 16 January 2007 08:36am, Jeremy Katz wrote:
On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
Naoki (naoki@valuecommerce.com) said:
DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
So would it not make sense to have an "everything" ISO for use on removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a raw FS standpoint. You could have a torrent that just makes a directory, even.
ISOs are convenient from a distribution standpoint just to ensure that things were downloaded correctly[1]. I can see how spending some time to make the "install from a USB device" a little bit easier could definitely have advantages.
Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio" that's 8GB+ (whatever) in size. That could be downloaded and extracted to wherever, be it a USB disk or a file server (NFS, etc.).
We support having the ISO being accessed over NFS. And you can loopback mount for HTTP/FTP. In the interest of our mirrors not hunting me down and killing me, I'd prefer to have as few different copies of the "same" bits as possible :-)
Jeremy
On Tuesday 16 January 2007 12:08, Jeremy Katz wrote:
We support having the ISO being accessed over NFS. And you can loopback mount for HTTP/FTP. In the interest of our mirrors not hunting me down and killing me, I'd prefer to have as few different copies of the "same" bits as possible :-)
In the interest of having the compose finish in anything possibly considered reasonable time, I'd rather not repackage up the same bits in many different containers.
On Tuesday 16 January 2007 10:08am, Jeremy Katz wrote:
On Tue, 2007-01-16 at 09:42 -0700, Lamont Peterson wrote:
On Tuesday 16 January 2007 08:36am, Jeremy Katz wrote:
On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
Naoki (naoki@valuecommerce.com) said:
DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
So would it not make sense to have an "everything" ISO for use on removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a raw FS standpoint. You could have a torrent that just makes a directory, even.
ISOs are convenient from a distribution standpoint just to ensure that things were downloaded correctly[1]. I can see how spending some time to make the "install from a USB device" a little bit easier could definitely have advantages.
Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio" that's 8GB+ (whatever) in size. That could be downloaded and extracted to wherever, be it a USB disk or a file server (NFS, etc.).
We support having the ISO being accessed over NFS. And you can loopback mount for HTTP/FTP. In the interest of our mirrors not hunting me down and killing me, I'd prefer to have as few different copies of the "same" bits as possible :-)
Very good point.
So, I'll just keep using the full os/ + updates repo. I think that's the best solution for both network and hard drive installs when people want the full distribution.
Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio" that's 8GB+ (whatever) in size. That could be downloaded and extracted to wherever, be it a USB disk or a file server (NFS, etc.).
The point of an ISO, is you can "dd" it and have a bootable device in one step. Just an ease of use thing really. Although see comments below ..
Agreed. For those environments, network installs typically make much more sense. Even on my home systems, I do network installs when I can because it's typically faster and easier than swapping CDs or burning DVDs.
I've often argued about dropping ISOs altogether in favor of just network installs. That tends to catch of lot of flack from the "I download at the office and install at home", or, "I live in X where broad band is too costly" crowds. All of which are valid points I might add. So if we're making ISOs already, how about one that would be far more practical than DVD for many people.
With a large ISO for other storage mediums I envisage something like this :
* Download it. * "dd" it to device. * Write my custom kickstart file. * Go to server / home box / whatever * Plug in / Boot / Go play with the dogs.
And changing the kickstart file doesn't require more cost (media).
The same could probably be done by just copying the mirror to a removable device, making it bootable etc, but that's not a currently documented install method.
However, to set up a network installation with all available packages, I would probably just continue to create my own mirror of the released packages and of the updates repo. But I agree that having a single file to download for initial setup of such file servers would be advantageous. It could also be the "roll-your-own-fedora-spin-kit" with all fedora packages + the spin tools (to build DVD and CD ISOs).
Now here is where I really start to like the idea. I also very much agree with the point made by Mr Katz when he says "I'd prefer to have as few different copies of the "same" bits as possible".
If there was a simple tool could download selected packages (and package groups) from selected repos, and then 'burn' it to a bootable device it would be the holy grail. It would allow totally flexible/custom builds. Although it's nothing that can't already be done with a network install setup, but as discussed that isn't always feasible for people.
Part of 'system-config-kickstart' ?
On Tuesday 16 January 2007 21:37, Naoki wrote:
If there was a simple tool could download selected packages (and package groups) from selected repos, and then 'burn' it to a bootable device it would be the holy grail. It would allow totally flexible/custom builds. Although it's nothing that can't already be done with a network install setup, but as discussed that isn't always feasible for people.
http://hosted.fedoraproject.org/projects/pungi
On Tue, 2007-01-16 at 21:42 -0500, Jesse Keating wrote:
On Tuesday 16 January 2007 21:37, Naoki wrote:
If there was a simple tool could download selected packages (and package groups) from selected repos, and then 'burn' it to a bootable device it would be the holy grail. It would allow totally flexible/custom builds. Although it's nothing that can't already be done with a network install setup, but as discussed that isn't always feasible for people.
Aha!! That sounds wonderful :
"We'll need to do five basic tasks:
1) Gather packages from repos into a directory tree 2) Run anaconda tools (buildinstall) on said directory tree 3) Split tree into CD iso size chunks 4) Create isos of the chunks 5) Sanity check the tree"
I'd suggest variable sized ISO chunks rather than CD specific, but I understand it's pretty much a work in progress.
In the interim though, see any merit in an everything ISO? Or is that just too big for mirrors and networks to deal with?
By the sounds of things there is an non-documented alternative of grab mirror, stick on storage device and (somehow) make your own bootable, installable image that functions like a DVD.
If anybody knows the "somehow" bit I'd love to know and would be happy to document.
On Tuesday 16 January 2007 23:35, Naoki wrote:
I'd suggest variable sized ISO chunks rather than CD specific, but I understand it's pretty much a work in progress.
Well, presumably one could make the "CD Size" configurable, so you could ask for 4gig size "CDs" or whatnot. Right now I think it is hardcoded, but a sensable patch to make it a semi-hidden option would be acceptable to me.
In the interim though, see any merit in an everything ISO? Or is that just too big for mirrors and networks to deal with?
Mostly too big for mirrors, for the little use it would be for.
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Jesse Keating Sent: Tuesday, January 16, 2007 9:54 PM To: fedora-devel-list@redhat.com Subject: Re: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 23:35, Naoki wrote:
I'd suggest variable sized ISO chunks rather than CD specific, but I understand it's pretty much a work in progress.
Well, presumably one could make the "CD Size" configurable, so you could ask for 4gig size "CDs" or whatnot. Right now I think it is hardcoded, but a sensable patch to make it a semi-hidden option would be acceptable to me.
In the interim though, see any merit in an everything ISO? Or is that just too big for mirrors and networks to deal with?
Mostly too big for mirrors, for the little use it would be for.
-- Jesse Keating Release Engineer: Fedora
I looked at putting Linux on a USB flash drive and from what I have read they don't always work. And if you get larger than 1 Gig then you have problems or have to have multiple partitions. Most things I have read want to use FAT16 for compatibility. So great idea, just don't think the hardware is that stable/compatible.
Here is a Knoppix how to http://www.knoppix.net/wiki/Bootable_USB_Key I would think this would fit better into the Fedora Live CD project.
The only other thought I have is maybe to get around the boot problem is to use the small boot cd and then do a hard drive install from the usb device. So you could install on old hardware that doesn't boot from usb and have the ability to change the content on the usb device.
On Tue, 2007-01-16 at 22:59 -0700, Jerry Williams wrote:
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Jesse Keating Sent: Tuesday, January 16, 2007 9:54 PM To: fedora-devel-list@redhat.com Subject: Re: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 23:35, Naoki wrote:
I'd suggest variable sized ISO chunks rather than CD specific, but I understand it's pretty much a work in progress.
Well, presumably one could make the "CD Size" configurable, so you could ask for 4gig size "CDs" or whatnot. Right now I think it is hardcoded, but a sensable patch to make it a semi-hidden option would be acceptable to me.
In the interim though, see any merit in an everything ISO? Or is that just too big for mirrors and networks to deal with?
Mostly too big for mirrors, for the little use it would be for.
-- Jesse Keating Release Engineer: Fedora
I looked at putting Linux on a USB flash drive and from what I have read they don't always work. And if you get larger than 1 Gig then you have problems or have to have multiple partitions. Most things I have read want to use FAT16 for compatibility. So great idea, just don't think the hardware is that stable/compatible.
I would somewhat disagree here, there is always the problem with older BIOSes but since USB boot has been pretty standard for motherboard manufacturers for a while now that would be a special case, not the norm. I've been installing windows from USB for a while now so the hardware is stable (IME). Size also shouldn't be an issue, if the BIOS can handle 750GB HDDs it can handle 8-16GB on a flash disk.
And the FS is a matter of what the kernel supports. The BIOS is only interested in boot sectors, not what file system is there.
Here is a Knoppix how to http://www.knoppix.net/wiki/Bootable_USB_Key I would think this would fit better into the Fedora Live CD project.
The only other thought I have is maybe to get around the boot problem is to use the small boot cd and then do a hard drive install from the usb device. So you could install on old hardware that doesn't boot from usb and have the ability to change the content on the usb device.
The boot process is the same for anything, be it CD/DVD/HDD/Flash with the only difference being at the hardware enumeration level. In theory you can make any device act the same so a boot and install should be easily possible from USB storage.
We already know we can run an installation from USB, we know we can make USB rescue disks. But so far it seems there has been no interest in installing from USB, which is a shame as it's easier and cheaper than CD/DVD.
If so, I'd like to document and add to the supported list of install methods.
Once upon a time, Matthew Miller mattdm@mattdm.org said:
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent, you've got the bandwidth to do a network install.
That makes a big assumption: that they location with bandwidth is the location being installed.
Even with DSL at home, I often download large things at work (OC3 >> DSL) and carry them home on DVD (or notebook hard drive).
On Fri, Jan 05, 2007 at 09:20:36AM -0600, Chris Adams wrote:
Even with DSL at home, I often download large things at work (OC3 >> DSL) and carry them home on DVD (or notebook hard drive).
Okay, but can't you also decide what you want at work?
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 09:20:36AM -0600, Chris Adams wrote:
Even with DSL at home, I often download large things at work (OC3 >> DSL) and carry them home on DVD (or notebook hard drive).
Okay, but can't you also decide what you want at work?
I use the DVD downloaded from work to install both my desktop box and my server box at home...
Paul.
Once upon a time, Matthew Miller mattdm@mattdm.org said:
On Fri, Jan 05, 2007 at 09:20:36AM -0600, Chris Adams wrote:
Even with DSL at home, I often download large things at work (OC3 >> DSL) and carry them home on DVD (or notebook hard drive).
Okay, but can't you also decide what you want at work?
I install my computers (server, desktop, notebook) and some family computers. I also give media to several friends that can't reasonably download anything (some on dialup, one in Iraq). Each has different preferences.
Folks,
Perhaps I missed it - now that "Core" is being dropped, does that mean that trademark issues with the original open source Fedora project (www.fedora.info) have now been resolved?
Thanks, Mike
Matthew Miller mattdm@mattdm.org wrote:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
so we need a everything DVD "Fedora 7 Complete" mirros can have the iso file and loopback mount it to get the "normal tree" saving diskspace. but I doubt that many mirror will do it. we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest versions over the network eventually. If you've got the bandwidth for bittorrent,
Yep.
you've got the bandwidth to do a network install.
Nope.
It doesn't matter if getting the image(s) takes a day or so (with a half dozen network problems requiring restarting the download thrown in just for fun), it /does/ matter greatly for an install.
On 1/5/07, Neal Becker ndbecker2@gmail.com wrote:
Any thoughts on moving to suspend2?
I didn't see anything in there to say the fedora kernel guys were changing there 'upstream' policy :-)
Peter
...... Original Message ....... On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" notting@redhat.com wrote:
It's time to bite the bullet.
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
___ Dax Kelson Sent with my Treo (please pardon any brevity)
On Fri, 2007-01-05 at 15:09 -0700, Dax Kelson wrote:
...... Original Message ....... On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" notting@redhat.com wrote:
It's time to bite the bullet.
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
I'm going to bite the bullet here based on *way* too many historical threads and say, "Um, no." I don't think merging the repos makes any of the existing reasons for doing away with this selection any less sound.
Refer to countless archives for said reasons, although I'm sure any sufficiently compelling, *brand-new* reason to put this back in will be happily debated here. It's not like this thread was long enough already or anything! ;-D
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
I don't think merging the repos makes any of the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of 'Everything' was the creation of extras.
It is useful for a variety of situations. Many, many, people have asked for it back. Now that the merge is happening, let's *restore* the feature that existed for years.
Dax Kelson Guru Labs
On Fri, Jan 05, 2007 at 03:43:58PM -0700, Dax Kelson wrote:
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
I don't think merging the repos makes any of the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of 'Everything' was the creation of extras.
It is useful for a variety of situations.
Examples? What problem are you actually trying to solve?
Many, many, people have asked for it back.
That doesn't mean it's the right thing to do. Many people have asked for all sorts of misguided features. Thankfully most of the time, sanity has prevailed.
Now that the merge is happening, let's *restore* the feature that existed for years.
The merge makes the case for not doing it even stronger. Before it was feasible that someone might not have extras configured, and might want everything from core.
core+extras today is around 5000 packages iirc. This is only going to get bigger. How can possibly make sense to install every package known to man? How do you deal with conflicting packages that want to do the same thing (like say, binding to a network socket). How do you navigate a gnome application menu with thousands of applications? Given a typical install today takes way too long, an everything install of 5000 packages must be hurrendous. And god, if people think yum takes too long now, installing updates for 5000 packages sounds like a world of unfun.
It's a seriously bad idea that makes less sense over time.
Dave
On Fri, Jan 05, 2007 at 09:22:04PM -0500, Dave Jones wrote:
core+extras today is around 5000 packages iirc. This is only going to get bigger. How can possibly make sense to install every package known to man?
What makes you think the installation is pointed at a full core+extras mirror instead of a selected subset? Not everybody is stupid you know.
OG.
On Sat, Jan 06, 2007 at 03:26:34AM +0100, Olivier Galibert wrote:
On Fri, Jan 05, 2007 at 09:22:04PM -0500, Dave Jones wrote:
core+extras today is around 5000 packages iirc. This is only going to get bigger. How can possibly make sense to install every package known to man?
What makes you think the installation is pointed at a full core+extras mirror instead of a selected subset? Not everybody is stupid you know.
I wish I shared your faith in humanity. Some people _will_ see an everything button and try it on a core+extras dist. Probably more than the alternative scenario you propose.
A better solution to subsets than using 'everything' would be to use the same mechanism we'll be using for the server spin or the kde spin or whatever.
Dave
On Friday 05 January 2007 21:26, Olivier Galibert wrote:
What makes you think the installation is pointed at a full core+extras mirror instead of a selected subset? Not everybody is stupid you know.
Because that's not "everything" and saying it is just puts us back into that confusing place where everything doesn't mean everything. We don't install kenrel.i586 kernel.i686 kernel-xen etc... on systems that don't support it. A yum install * would do this, and bam, your box won't boot. How fun is that?
Now, when you bring up a selected subset, these spins could be "everything" by default, as in you're getting the Desktop CD set, it could list all packages that were targetted for this spin as default (some manditory) and you've got "everything". Deselect what you don't want.
Will we do this for Fedora Desktop/Server/KDE? Probably not.
On Sat, Jan 06, 2007 at 03:26:34AM +0100, Olivier Galibert wrote:
What makes you think the installation is pointed at a full core+extras mirror instead of a selected subset? Not everybody is stupid you know.
But, in what way is that "everything", then? It's not at all!
On 1/5/07, Olivier Galibert galibert@pobox.com wrote:
On Fri, Jan 05, 2007 at 09:22:04PM -0500, Dave Jones wrote:
core+extras today is around 5000 packages iirc. This is only going to get bigger. How can possibly make sense to install every package known to man?
What makes you think the installation is pointed at a full core+extras mirror instead of a selected subset? Not everybody is stupid you know.
To be honest, because people (myself included) are morons. We are sure that we are being gipped by the packagers and unless we have it ALL we may be missing some secret tool, item that they are keeping away from us. [God the number of bugs we used to get on "I clicked on Everything and found out that it didnt install all the files because of my language choice. This is a stop critical bug!"]
80% of the people who opened tickets during 7 did everything installs when asked. The problems they had were mostly due to having everything installed (running out disk, wondering why tux was conflicting with httpd (or something like that).
On 1/6/07, Dave Jones davej@redhat.com wrote:
That doesn't mean it's the right thing to do. Many people have asked for all sorts of misguided features. Thankfully most of the time, sanity has prevailed.
Now that the merge is happening, let's *restore* the feature that existed for years.
The merge makes the case for not doing it even stronger. Before it was feasible that someone might not have extras configured, and might want everything from core.
core+extras today is around 5000 packages iirc. This is only going to get bigger. How can possibly make sense to install every package known to man? How do you deal with conflicting packages that want to do the same thing (like say, binding to a network socket). How do you navigate a gnome application menu with thousands of applications? Given a typical install today takes way too long, an everything install of 5000 packages must be hurrendous. And god, if people think yum takes too long now, installing updates for 5000 packages sounds like a world of unfun.
It's a seriously bad idea that makes less sense over time.
Completely agree with you !
On 1/5/07, Dave Jones davej@redhat.com wrote:
On Fri, Jan 05, 2007 at 03:43:58PM -0700, Dax Kelson wrote:
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
I don't think merging the repos makes any of the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of 'Everything' was the creation of extras.
It is useful for a variety of situations.
Examples? What problem are you actually trying to solve?
Many, many, people have asked for it back.
That doesn't mean it's the right thing to do. Many people have asked for all sorts of misguided features. Thankfully most of the time, sanity has prevailed.
Yes, one of the most requested items we got after 5.0 was "Could you make it so passwords were not needed for root default?" this later morphed into "Please make it so that anyone can run anything by default" ... and the routine that someone wanted us to have so that if you pinged a port it would reset all the passwords on the system. "Great for our ISP to manage boxes when the owner has locked himself out."
Dax Kelson wrote:
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
I don't think merging the repos makes any of the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of 'Everything' was the creation of extras.
It was more about anaconda supporting installations from any number of yum repositories.
As stated many many many times in the past, Everything cannot be defined when we allow people to install from an arbitrary number of repositories.
And if we did install everything we found (and assuming the backend didn't crash when resolving dependencies), people would complain that the install took too long.
It is useful for a variety of situations. Many, many, people have asked for it back. Now that the merge is happening, let's *restore* the feature that existed for years.
Of all of the complaints that have come in just in the past year regarding the removal of the Everything install, only *one* was reasonable, IMHO. And solving that was a matter of educating the user on how to set up kickstart to provision systems (and we still support Everything installs via kickstart using '*' under %packages). In their case, systems were provisioned and then carried in to a secure DoD research environment without any Internet connectivity. They wanted to set up the systems with everything installed up front and not have to install later since they _couldn't_ do that.
My solution was to set up kickstart to do a normal install, mirror all the packages to the /var/cache/yum tree and then let them use yum later on if they need to install things. It worked well.
On 1/6/07, David Cantrell dcantrell@redhat.com wrote:
Of all of the complaints that have come in just in the past year regarding the removal of the Everything install, only *one* was reasonable, IMHO. And solving that was a matter of educating the user on how to set up kickstart to provision systems (and we still support Everything installs via kickstart using '*' under %packages).
+1 How do we do this for the Fedora community in general? How do we effectively educate people concerning the use of kickstart, so they will be willing to reach for kickstart as a solution for legitimate niche install scenarios? Do we need to start compiling well commented examples of useful kickstart files into the wiki and point to them from the release notes? What will it take to get people stop looking for the UI to be encumbered with unnecessary flexibility and to have them start reaching for kickstart to be the flexible solution that it was meant to be?
-jef
On Sat, Jan 06, 2007 at 12:12:42PM -0900, Jeff Spaleta wrote:
On 1/6/07, David Cantrell dcantrell@redhat.com wrote:
Of all of the complaints that have come in just in the past year regarding the removal of the Everything install, only *one* was reasonable, IMHO. And solving that was a matter of educating the user on how to set up kickstart to provision systems (and we still support Everything installs via kickstart using '*' under %packages).
+1 How do we do this for the Fedora community in general? How do we effectively educate people concerning the use of kickstart, so they will be willing to reach for kickstart as a solution for legitimate niche install scenarios? Do we need to start compiling well commented examples of useful kickstart files into the wiki and point to them from the release notes? What will it take to get people stop looking for the UI to be encumbered with unnecessary flexibility and to have them start reaching for kickstart to be the flexible solution that it was meant to be?
Ok, I burn a standard fedora iso, I boot on it, please do tell me where is the command line or whatever I can use to input kickstart commands.
Why do you have any package choices in anaconda anyway? You can do it all after the install, isn't it? If what you people want is a minimal install that only gives a reliable network and/or cdrom afterwards and have the real install being done after having booted on it, just do it. But stop pussyfooting around. Make a damn decision.
OG.
On 1/7/07, Olivier Galibert galibert@pobox.com wrote:
Ok, I burn a standard fedora iso, I boot on it, please do tell me where is the command line or whatever I can use to input kickstart commands.
Have a look at: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickst...
HTH
On Sun, Jan 07, 2007 at 06:58:58AM +0100, Vnpenguin wrote:
On 1/7/07, Olivier Galibert galibert@pobox.com wrote:
Ok, I burn a standard fedora iso, I boot on it, please do tell me where is the command line or whatever I can use to input kickstart commands.
Have a look at: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickst...
HTH
No it doesn't, sorry. Please re-read what you quoted, and realize that I do know about kickstart. AFAIK, you can't give any kickstart commands when you're doing a cdrom install using a standard fedora iso.
OG.
Olivier Galibert wrote:
No it doesn't, sorry. Please re-read what you quoted, and realize that I do know about kickstart. AFAIK, you can't give any kickstart commands when you're doing a cdrom install using a standard fedora iso.
The whole point of kickstart is to *automate* that steps so you dont have to do a standard installation or click any buttons.
Rahul
On 1/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Olivier Galibert wrote:
No it doesn't, sorry. Please re-read what you quoted, and realize that I do know about kickstart. AFAIK, you can't give any kickstart commands when you're doing a cdrom install using a standard fedora iso.
The whole point of kickstart is to *automate* that steps so you dont have to do a standard installation or click any buttons.
I use kickstart with "interactive" option. So all selections were defined as defaults. I could "click" without any problem to change any value.
On Sunday 07 January 2007 08:53, Olivier Galibert wrote:
No it doesn't, sorry. Please re-read what you quoted, and realize that I do know about kickstart. AFAIK, you can't give any kickstart commands when you're doing a cdrom install using a standard fedora iso.
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
On Sun, Jan 07, 2007 at 12:50:15PM -0500, Jesse Keating wrote:
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
I don't know if you support it, but I've already used this with RHEL4 ;-).
On 1/7/07, Jesse Keating jkeating@redhat.com wrote:
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
computers still come with floppy drives?
-jef
On 1/7/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 1/7/07, Jesse Keating jkeating@redhat.com wrote:
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
computers still come with floppy drives?
Yeah, my box (which runs FC1..FC6) has one and it works well :)
Sorry for OT,
On Sunday 07 January 2007 14:14, Jeff Spaleta wrote:
On 1/7/07, Jesse Keating jkeating@redhat.com wrote:
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
computers still come with floppy drives?
Some do, there are USB floppies too.
I wouldn't be opposed to having a set of kickstart config files on the isos too, interactive of course, but I'll wait for those to be submitted.
Once upon a time Sunday 07 January 2007 2:11 pm, Jesse Keating wrote:
On Sunday 07 January 2007 14:14, Jeff Spaleta wrote:
On 1/7/07, Jesse Keating jkeating@redhat.com wrote:
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
computers still come with floppy drives?
Some do, there are USB floppies too.
I wouldn't be opposed to having a set of kickstart config files on the isos too, interactive of course, but I'll wait for those to be submitted.
What would be nice for kickstart files on iso's namely DVD iso is pre-defined installs for postfix mail server, sendmail mail server, mysql database server , postgresql server etc. Ones that install a predefined set of packages. but have the user set partitioning, root password etc.
On Sunday 07 January 2007 15:24, Dennis Gilmore wrote:
What would be nice for kickstart files on iso's namely DVD iso is pre-defined installs for postfix mail server, sendmail mail server, mysql database server , postgresql server etc. Ones that install a predefined set of packages. but have the user set partitioning, root password etc.
Well, one could have different comps files used based upon which option you select, so if you select a mailserver in anaconda, it would use the comps file for that which has the right stuff mandatory/default. Something to think about for say F8.
On Sun, 2007-01-07 at 15:32 -0500, Jesse Keating wrote:
On Sunday 07 January 2007 15:24, Dennis Gilmore wrote:
What would be nice for kickstart files on iso's namely DVD iso is pre-defined installs for postfix mail server, sendmail mail server, mysql database server , postgresql server etc. Ones that install a predefined set of packages. but have the user set partitioning, root password etc.
Well, one could have different comps files used based upon which option you select, so if you select a mailserver in anaconda, it would use the comps file for that which has the right stuff mandatory/default. Something to think about for say F8.
Why would you need different comps files ? Wouldn't it be enough to have separate 'sendmail mailserver' and 'postfix mailserver' groups ?
In general, I am not convinced that basing this on tools that are mainly meant for interactive use (like comps) is really all that useful in the server world - what we want is something like kickstart, but with a clean separation between the stuff that is site-independent (e.g. which packages go on a postfix mailserver) and the stuff that is very site dependent (storage setup, authentication, backup, ...)
For servers, you quickly get into questions that are more config mgmt questions than install/provisioning questions. Either way, having a good list of the most popular server setups and/or package lists for them would be a very good start.
David
On 1/7/07, Dennis Gilmore dennis@ausil.us wrote:
What would be nice for kickstart files on iso's namely DVD iso is pre-defined installs for postfix mail server, sendmail mail server, mysql database server , postgresql server etc. Ones that install a predefined set of packages. but have the user set partitioning, root password etc.
I think its time to start compiling a selection of contributed kickstart files, so they can be gone over and culled into a group that can be considered for inclusion into iso images or prettied up for consumption from the wiki as standard reference kickstart scenarios.
Who has semi-useful kickstart files they can drop into the wiki with a short description of the situation you use it for?
-jef
On Sun, 2007-01-07 at 14:24 -0600, Dennis Gilmore wrote:
Once upon a time Sunday 07 January 2007 2:11 pm, Jesse Keating wrote:
On Sunday 07 January 2007 14:14, Jeff Spaleta wrote:
On 1/7/07, Jesse Keating jkeating@redhat.com wrote:
You can with a remote kickstart file or a file on a floppy, or (do we support ks on a USB stick yet?)
computers still come with floppy drives?
Some do, there are USB floppies too.
I wouldn't be opposed to having a set of kickstart config files on the isos too, interactive of course, but I'll wait for those to be submitted.
What would be nice for kickstart files on iso's namely DVD iso is pre-defined installs for postfix mail server, sendmail mail server, mysql database server , postgresql server etc. Ones that install a predefined set of packages. but have the user set partitioning, root password etc.
That I think is where a Ferdora Server spin would add a lot of value: if it came with the tools that are necessary to set up various 'server personalities' (for lack of a better word)
There's a good amount of overlap with this idea and the 'virtual appliances' that everybody likes these days. From a sysadmin's point of view, the two should be very similar.
David
On Sat, Jan 06, 2007 at 12:12:42PM -0900, Jeff Spaleta wrote:
niche install scenarios? Do we need to start compiling well commented examples of useful kickstart files into the wiki and point to them from the release notes? What will it take to get people stop looking
Put them on the install CDs.
On Sat, 2007-01-06 at 20:22 -0500, Matthew Miller wrote:
On Sat, Jan 06, 2007 at 12:12:42PM -0900, Jeff Spaleta wrote:
niche install scenarios? Do we need to start compiling well commented examples of useful kickstart files into the wiki and point to them from the release notes? What will it take to get people stop looking
Put them on the install CDs.
A good collection would be useful for other purposes, too, e.g. for cobbler[1] or prm[2] - basically, what everybody wants is answers to common setup/config questions that can be consumed by tools. A collection of kickstart files would definitely be a good first step towards that.
David
[1] http://cobbler.et.redhat.com/ [2] http://et.redhat.com/emd/prm/
On 1/8/07, David Lutterkort dlutter@redhat.com wrote:
A good collection would be useful for other purposes, too, e.g. for cobbler[1] or prm[2] - basically, what everybody wants is answers to common setup/config questions that can be consumed by tools. A collection of kickstart files would definitely be a good first step towards that.
Do you have any kickstart files on hand we can use as a starting putting for a raw collection?
-jef
On Fri, 2007-01-05 at 15:09 -0700, Dax Kelson wrote:
...... Original Message ....... On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" notting@redhat.com wrote:
It's time to bite the bullet.
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
While an "everything" install may have made some sense in the pre-Extras days, it's just silly now. There are so many packages in Core+Extras, many of which duplicate functionality. I mean you'll get at least three SMTP servers (sendmail, exim, postfix), probably four or five window managers/desktop environments, and who knows what else.
Jeff
Jeffrey C. Ollie jeff@ocjtech.us:
While an "everything" install may have made some sense in the pre-Extras days, it's just silly now. There are so many packages in Core+Extras, many of which duplicate functionality.
Nebvertheless, there are real uses for "install everything". Notably, one can be working tools that are designed to audit the entire distribution. When I test doclifter, I want the largest possible corpus of man pages to work on.
On Fri, Jan 05, 2007 at 05:43:31PM -0500, Eric S. Raymond wrote:
Nebvertheless, there are real uses for "install everything". Notably, one can be working tools that are designed to audit the entire distribution. When I test doclifter, I want the largest possible corpus of man pages to work on.
That's what "yum install '*'" is for.
Eric S. Raymond wrote:
Jeffrey C. Ollie jeff@ocjtech.us:
While an "everything" install may have made some sense in the pre-Extras days, it's just silly now. There are so many packages in Core+Extras, many of which duplicate functionality.
Nebvertheless, there are real uses for "install everything". Notably, one can be working tools that are designed to audit the entire distribution. When I test doclifter, I want the largest possible corpus of man pages to work on.
There are easy ways to do this with yum or kickstart even now.
Rahul
On Fri, 2007-01-05 at 16:32 -0600, Jeffrey C. Ollie wrote:
While an "everything" install may have made some sense in the pre-Extras days, it's just silly now. There are so many packages in Core+Extras, many of which duplicate functionality. I mean you'll get at least three SMTP servers (sendmail, exim, postfix), probably four or five window managers/desktop environments, and who knows what else.
Jeff
I disagree. Just because you can't envision a use for it doesn't mean that others cant.
The alternatives system deployed in RHL ages ago (1999) so that you can have multiple "conflicting' packages installed at the same time.
For a "production" box that is performing some defined task(s), I agree that "everything" is a bad idea.
For a "power user"/developer/consultant/helpdesk box, I don't see any problem with an "everything" install. Hard disk space is cheap and plentiful (note that 1TB drives were announced yesterday).
There are numerous situations where an application dynamically gets extra functionality and features if other *addon* or *plugin* packages get installed.
Dax Kelson Guru Labs
On Friday 05 January 2007 16:09, Dax Kelson wrote:
...... Original Message ....... On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" notting@redhat.com
wrote:
It's time to bite the bullet.
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
You really want over 3500 packages on your system? and even if you could have that its not possible some packages are mutually exclusive
On Fri, 2007-01-05 at 16:50 -0600, Dennis Gilmore wrote:
"even if you could have that its not possible some packages are mutually exclusive."
Sendmail and Postfix both have "/sbin/sendmail", but you can have them both installed at the same time.
Any mutually exclusive cases should be considered a bug(1). See update-alternatives(8).
Dax Kelson Guru Labs
(1) A class of bug that RHL/FC did without for 15 years or so because Everything installs existed.
On Fri, Jan 05, 2007 at 03:09:34PM -0700, Dax Kelson wrote:
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
Doesn't this boil down to running 'yum install *' just after installation ?
Emmanuel
On 1/5/07, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
On Fri, Jan 05, 2007 at 03:09:34PM -0700, Dax Kelson wrote:
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
Doesn't this boil down to running 'yum install *' just after installation ?
I would suspect so. Your machine might explode soon after though :]
yum install *.i386 and/or yum install *.`uname -m` might make it explode less. It is simple to do this once you have a net connection.
For those people who want "install everything" on removable media I am wondering what removable media they are going to store "everything" on?
Maybe a compomise would be to have an option to "install everything available on media". That makes more sense than a straight "install everything" in this yum-enabled-anaconda world. Kinda.
/Mike
Dax Kelson wrote:
...... Original Message ....... On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" notting@redhat.com wrote:
It's time to bite the bullet.
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that RHL/FC had for years?
For which release? Server, GNOME, KDE? Tell us more details.
Rahul
At 2:50 PM -0500 1/4/07, Bill Nottingham wrote:
Hence, Fedora 7. Name TBD, but probably not 'Bride of Zod'.
How about "Corson, the demon child of the unholy marriage of Core and Extras"? (Google "corson" and feel lucky.)
Bill Nottingham wrote:
[...]
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
- Make LiveCDs as a part of the distribution release process
- Ability to customize non-packaging distrubution parameters
- Switch to libata drivers for PATA support
- Speedup of bootup and shutdown
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
- CodecBuddy
- Fixing the proliferation of dictionary packages
- Support encrypted filesystems
- Fast user switching in the desktop
- Fix the firewire stack
- Switch to a tickless kernel by default
- Fix unnecessary wakeups across the distribution
- Add KVM virtualization support to our tools
- Investigate (but probably don't switch to) new init technologies
- Add the nouveau drivers for nVidia cards
- Speed up Yum and RPM
- Add support for RandR 1.2
- Switch to syslog-ng
- Make the update system useable by all
can we add this to the list: make yum/pirut able to install software from media (cd/dvd) ? This was on the TODO list since FC5 is out and its still not fixed I know that this works by setting up a local repo but this isn't really a option (for new users) and requiring a broadband connection to install software will let some users switch to <insertdistrowiththisfeature> or even back to windows.
On Sat, 2007-01-06 at 16:47 +0100, dragoran wrote:
can we add this to the list: make yum/pirut able to install software from media (cd/dvd) ? This was on the TODO list since FC5 is out and its still not fixed I know that this works by setting up a local repo but this isn't really a option (for new users) and requiring a broadband connection to install software will let some users switch to <insertdistrowiththisfeature> or even back to windows.
It's one of the big-ish things I'm hoping to get done; I have the start of poking some infrastructure down into yum lying around from right after Thanksgiving, I need to just flesh it out and send a proposal to yum-devel on how it should work. I'll try to add it to the wiki list later today. Of course, that depends on if I ever finish reading my mail ;-)
Jeremy
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
Two things here:
1) Is there going to be further effort towards a minimalistic install as official release option? I seem to here/see people asking for a 1-2 CD media install option (as in they can safely download only the first two cd isos and get a Fedora install up)
2) The Desktop Environment catch 22 seems to be continuing: KDE gets less love since the measurable KDE using community is small, while the measurable KDE community is small since those who heavily use KDE go elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent bad press, there may be a few who would like another distro to use KDE on.
Might also mention (for no particular reason) that I actually like the fact that the system-config tools are in Gtk and look different from my desktop (Qt) application
- Make LiveCDs as a part of the distribution release process
Any insight if these LiveCDs will be an adequate replacement for a Knoppix CD?
- Speedup of bootup and shutdown
I've never worried about this too much, but i suppose that would be nice.
- Add wireless firmware for all the chipsets we can
I would be just happy for a way of reliably knowing that I even need a code - as opposed to modules (drivers) just failing to work.
- Fixing the proliferation of dictionary packages
This is a Linux wide need
I vote for keeping Fedora 7 unreleased till at least 90% of these features are implemented, they seem to be worth the wait.
On Sunday 07 January 2007 06:47, Arthur Pemberton wrote:
Two things here:
- Is there going to be further effort towards a minimalistic install
as official release option? I seem to here/see people asking for a 1-2 CD media install option (as in they can safely download only the first two cd isos and get a Fedora install up)
Yes, one, two CDs are the size mark for these spins. Without X we could get really small with the Server spin, but we'll see where we go.
- The Desktop Environment catch 22 seems to be continuing: KDE gets
less love since the measurable KDE using community is small, while the measurable KDE community is small since those who heavily use KDE go elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent bad press, there may be a few who would like another distro to use KDE on.
So how does 'Fedora KDE' vs 'Fedora Desktop' differ from 'Ubuntu' vs 'Kubuntu' ? We don't even force a different project name.
Might also mention (for no particular reason) that I actually like the fact that the system-config tools are in Gtk and look different from my desktop (Qt) application
- Make LiveCDs as a part of the distribution release process
Any insight if these LiveCDs will be an adequate replacement for a Knoppix CD?
We hope so. We'd like it to be even better than the Ubuntu live CD.
On 1/8/07, Jesse Keating jkeating@redhat.com wrote:
On Sunday 07 January 2007 06:47, Arthur Pemberton wrote:
Two things here:
- Is there going to be further effort towards a minimalistic install
as official release option? I seem to here/see people asking for a 1-2 CD media install option (as in they can safely download only the first two cd isos and get a Fedora install up)
Yes, one, two CDs are the size mark for these spins. Without X we could get really small with the Server spin, but we'll see where we go.
For a server cd, I don't mind doing yum install xorg and xfce is necessary post install, however. That brings up the other point where I notice that a lot of usefule/semi useful commands have no man pages. (I guess I should take the initiative and at least writeup a script to search these apps up) one example would be lshal (recently found out about it)
[ snip ]
- Make LiveCDs as a part of the distribution release process
Any insight if these LiveCDs will be an adequate replacement for a Knoppix CD?
We hope so. We'd like it to be even better than the Ubuntu live CD.
The only live CD I'm familiar with is Knoppix, but I'll assume from your comment that the Ubuntu live CD is as good or better.
-- Jesse Keating Release Engineer: Fedora
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sunday 07 January 2007 15:01, Arthur Pemberton wrote:
For a server cd, I don't mind doing yum install xorg and xfce is necessary post install, however. That brings up the other point where I notice that a lot of usefule/semi useful commands have no man pages. (I guess I should take the initiative and at least writeup a script to search these apps up) one example would be lshal (recently found out about it)
Well, I think we should still include the xorg libs, so that one could run the gui system config tools over ssh.
On 1/8/07, Jesse Keating jkeating@redhat.com wrote:
On Sunday 07 January 2007 06:47, Arthur Pemberton wrote:
[ snip ]
- The Desktop Environment catch 22 seems to be continuing: KDE gets
less love since the measurable KDE using community is small, while the measurable KDE community is small since those who heavily use KDE go elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent bad press, there may be a few who would like another distro to use KDE on.
So how does 'Fedora KDE' vs 'Fedora Desktop' differ from 'Ubuntu' vs 'Kubuntu' ? We don't even force a different project name.
I don't know... I am/was trying to consider things from those who see this as a problem. Write now the lack of KDE in the name isn't preventing me from using Fedora. But from reading around the internet, it seems a non-ignorable percentage simply do not consider Fedora when looking for a distro to use KDE on - while it is obviously not really a popularity content, more users don't add that much more load to a project (I would think) while with more users, more helpers should come - there by spreading the work and love around.
On 1/7/07, Arthur Pemberton pemboa@gmail.com wrote:
- The Desktop Environment catch 22 seems to be continuing: KDE gets
less love since the measurable KDE using community is small, while the measurable KDE community is small since those who heavily use KDE go elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent bad press, there may be a few who would like another distro to use KDE on.
Hmm I guess you are wrong here knowing the fact there aren't many statistics to prove me wrong, there are a lot of Fedora KDE users around than you can imagine. If there are many leaving fedora kde for something, It might be because fedora doesn't love much kde and work needs to be here!
To be honest, as a fedora ambassador, I see 3 of 5 fedora installs are KDE installs.
Chitlesh
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
1) Is there any plan to have some sort of Fedora recommends hardware of manufacturer X,Y,Z? I'm not thinking of hardware certification, just recommendations. I think this would be very beneficial.
2) I haven't heard much of Python 2.5 for Fedora 7. Comments would be appreciated.
Arthur Pemberton wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
- Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification, just recommendations. I think this would be very beneficial.
we should create some sort of hw db where people can check which hw is supported by fedora and which not
- I haven't heard much of Python 2.5 for Fedora 7. Comments would be
appreciated.
its in rawhide so it should be in F7
dragoran wrote:
Arthur Pemberton wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
- Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification, just recommendations. I think this would be very beneficial.
we should create some sort of hw db where people can check which hw is supported by fedora and which not
See http://fedoraproject.org/wiki/MikeMcGrath/HardwareProfiler
Rahul
On 1/8/07, dragoran drago01@gmail.com wrote:
Arthur Pemberton wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
- Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification, just recommendations. I think this would be very beneficial.
we should create some sort of hw db where people can check which hw is supported by fedora and which not
That's great. I don't even ask for the word 'support' to be used, I would be happy with:
* works with clean fedora (no binary blob drivers or firmware required) * works with non fedora worthy firmware * works in Linux, but not Fedora ready (or clean enough) * no idea * doesn't work
- I haven't heard much of Python 2.5 for Fedora 7. Comments would be
appreciated.
its in rawhide so it should be in F7
Arthur Pemberton pemboa@gmail.com wrote:
On 1/8/07, dragoran drago01@gmail.com wrote:
Arthur Pemberton wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
- Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification, just recommendations. I think this would be very beneficial.
we should create some sort of hw db where people can check which hw is supported by fedora and which not
That's great. I don't even ask for the word 'support' to be used, I would be happy with:
- works with clean fedora (no binary blob drivers or firmware required)
- works with non fedora worthy firmware
- works in Linux, but not Fedora ready (or clean enough)
- no idea
- doesn't work
Who would compile and keep this up to date? Have you any idea of how many brands and models of different pieces are around?
On 1/8/07, Horst H. von Brand vonbrand@inf.utfsm.cl wrote:
Arthur Pemberton pemboa@gmail.com wrote:
On 1/8/07, dragoran drago01@gmail.com wrote:
Arthur Pemberton wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
And, what would a release be without features. We've identified 28 features that we'd like to include in the release, available at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
- Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification, just recommendations. I think this would be very beneficial.
we should create some sort of hw db where people can check which hw is supported by fedora and which not
That's great. I don't even ask for the word 'support' to be used, I would be happy with:
- works with clean fedora (no binary blob drivers or firmware required)
- works with non fedora worthy firmware
- works in Linux, but not Fedora ready (or clean enough)
- no idea
- doesn't work
Who would compile and keep this up to date? Have you any idea of how many brands and models of different pieces are around?
The community would. For example:
1) I install F7 2) My tv card works immediately without any additional drivers 3) I pull the card info from available sources 4) I add it to the db if it isn't already there
The process would just need to have to peer review/dispute
Another exmaple:
1) I instal FC6 2) I try a sound interface card (Echo Gina 24) 3) I realise the drivers are in the FC6 kernel (gina24.ko) 4) I realise that I need firmware not availabe in the official fedora repos to get the device to work with alsa 5) I gather the info on the card (including the fac that it is a discontinued model) 6) I add it to the db if it isn't ther
All I'm asking for a Fedora blessed infrastructure to be put in place, not for any one person to be responsible for populating it
The benefit of this being that next time I'm buying hardware, I can scurry over to the db and check what the best options are.
Arthur Pemberton wrote:
The community would. For example:
- I install F7
- My tv card works immediately without any additional drivers
- I pull the card info from available sources
- I add it to the db if it isn't already there
The process would just need to have to peer review/dispute
Another exmaple:
- I instal FC6
- I try a sound interface card (Echo Gina 24)
- I realise the drivers are in the FC6 kernel (gina24.ko)
- I realise that I need firmware not availabe in the official fedora
repos to get the device to work with alsa 5) I gather the info on the card (including the fac that it is a discontinued model) 6) I add it to the db if it isn't ther
All I'm asking for a Fedora blessed infrastructure to be put in place, not for any one person to be responsible for populating it
The benefit of this being that next time I'm buying hardware, I can scurry over to the db and check what the best options are.
Since we're talking pie in the sky, I give to you Hardware Buddy.
1) Install FC7+ 2) Opt in to "Automated Fedora-Compatibile Hardware Reporting" (in firstboot?) 3) for every piece of hardware that's ever detected on this machine, including removable devices like USB keys, etc. a) Hardware Buddy compiles a report on the device b) checks that the device hasn't been reported from this machine c) asks user to confirm if device is working correctly d) submits the report to some wiki with optional user comments
In the wiki, such votes are automatically analyzed by kernel/etc version, and percentage working device reports out of all reports.
(B) would cut down on duplicates. Although the definitition of "machine" can be foggy, we could operationalize this as just a file in /var that keeps a log of what's been reported.
(C) is crucial, because just being able to detect a device isn't the same as being able to confirm that it works. Some confirming could be automated (it's easy to tell if a network card or a USB drive work), some would have to be manual. Ideally, one would present the user with a suggested testing scenario, e.g., for a printer, does this test page look OK?
For devices both working and non, Hardware Buddy could automatically collect info like the output of lspci, etc.
For bonus points, the wiki can automatically cheer Linux-friendly manufacturers (lots of compatible devices), and jeer unfriendly ones (lots of incompatible hardware) on its front page.
Lots of interesting questions remain. If a new kernel comes out with new drivers supporting some piece of hardware, what happens to old reports in the wiki? Perhaps they expire after some time. Or perhaps not, since we can just keep them as cumulative statistics. What if some device is "partially" supported? But it seems like this could be a fruitful direction.
On 1/8/07, Jack Tanner ihok@hotmail.com wrote:
[snip some more detailed usage scenarios]
Since we're talking pie in the sky, I give to you Hardware Buddy.
- Install FC7+
- Opt in to "Automated Fedora-Compatibile Hardware Reporting" (in
firstboot?) 3) for every piece of hardware that's ever detected on this machine, including removable devices like USB keys, etc. a) Hardware Buddy compiles a report on the device b) checks that the device hasn't been reported from this machine c) asks user to confirm if device is working correctly d) submits the report to some wiki with optional user comments
Perhaps a modification of "sysreport", which already exists? 3b-3d could be done outside of the tool on a server and sysreport could be modified to submit to this hypothetical server instead of to RH support. 3a would obviously require running the tool each time dbus reports some new hardware.
"Description : Sysreport is a utility that gathers information about a system's hardware and configuration. The information can then be used for diagnostic purposes and debugging. Sysreport is commonly used to help support technicians and developers by providing a "snapshot" of a system's current layout."
Oisin Feeley
Le Lun 8 janvier 2007 16:24, Oisin Feeley a écrit :
Perhaps a modification of "sysreport", which already exists?
IMHO klive (http://klive.cpushare.com/) is closer to what's needed
Regards,
Le Lun 8 janvier 2007 16:03, Jack Tanner a écrit :
Since we're talking pie in the sky, I give to you Hardware Buddy.
1. You don't want an install-time check because a. in our brave new hotplug world hardware composition of a system evolves over time b. just because something does not work *today* does not mean it won't work a month later when the software part is updated (unfortunately, the reverse is true). The user must have the possibility to change his evaluation
2. You don't want to cull failing devices too - knowing the installed hardware base available to linux systems is crucial to focus new driver development/manufacturer evangelization
3. You should allow fully automated non-interactive mode - non reviewed data is better than no data and most users will get sick reporting every time they plug a new usb bit on their system
4. Feeds to other projects (for example pciid database feed) would be beneficial both to the community and as Fedora advertising.
Unfortunately, we're both a bit late for Christmas.
Nicolas Mailhot wrote:
- You don't want an install-time check because
a. in our brave new hotplug world hardware composition of a system evolves over time
Obviously. No, what I suggested for firstboot was that the user would get to opt in to the whole reporting procedure. I'm not sure that firstboot is the best place for even that. Ideally, you want to ask the person who's actually the console user. Perhaps this should be per user, even.
b. just because something does not work *today* does not mean it won't work a month later when the software part is updated (unfortunately, the reverse is true). The user must have the possibility to change his evaluation
Yup.
- You don't want to cull failing devices too - knowing the installed
hardware base available to linux systems is crucial to focus new driver development/manufacturer evangelization
Yup.
- You should allow fully automated non-interactive mode - non reviewed
data is better than no data and most users will get sick reporting every time they plug a new usb bit on their system
Sure. Fully automated should still be opted into. So:
( ) Prompt me for comments whenever Hardware Buddy wants to report a new device (*) Don't ask for comments, just report automatically (What info is included?) ( ) Disable Hardware Buddy altogether
- Feeds to other projects (for example pciid database feed) would be
beneficial both to the community and as Fedora advertising.
Yup.
Unfortunately, we're both a bit late for Christmas.
Yup. Hm. Anyone want to play cupid? Valentine's Day is coming up, and I could fall in love with my Hardware Buddy. :)
Arthur Pemberton pemboa@gmail.com wrote:
On 1/8/07, Horst H. von Brand vonbrand@inf.utfsm.cl wrote:
Arthur Pemberton pemboa@gmail.com wrote:
[...]
That's great. I don't even ask for the word 'support' to be used, I would be happy with:
- works with clean fedora (no binary blob drivers or firmware required)
- works with non fedora worthy firmware
- works in Linux, but not Fedora ready (or clean enough)
- no idea
- doesn't work
Who would compile and keep this up to date? Have you any idea of how many brands and models of different pieces are around?
The community would. For example:
- I install F7
OK.
- My tv card works immediately without any additional drivers
Or it doesn't.
- I pull the card info from available sources
Which ones?
- I add it to the db if it isn't already there
Who checks your entry is correct? What happens if you reported it didn't work, and it works fine for me, or viceversa?
[...]
All I'm asking for a Fedora blessed infrastructure to be put in place, not for any one person to be responsible for populating it
This requires manpower (to check for junk, to clean up entries, to discriminate among conclicting entries, ...). Ask the people at http://www.linuxprinting.org if this is a trivial job. And printers are outside the box, so it is /simple/ compared to all possible strange interactions among in-box pieces.
The benefit of this being that next time I'm buying hardware, I can scurry over to the db and check what the best options are.
For higher-end stuff the data is usually at hand, for el-cheapo not (and better stay away from that in any case).
On 1/9/07, Horst H. von Brand vonbrand@inf.utfsm.cl wrote:
- I add it to the db if it isn't already there
Who checks your entry is correct? What happens if you reported it didn't work, and it works fine for me, or viceversa?
Inevitably some hardware will work for all, some will work for a proportion of users and some won't work at all. If I'm looking at the DB, I'd like to see something like "works for X% of users."
You could also add info on whether or not it work OOTB too. Personally, I'm happy trying to get some of my hardware configured, but others I just wouldn't know where to start.
On 1/10/07, Horst H. von Brand vonbrand@inf.utfsm.cl wrote: [...]
[...]
All I'm asking for a Fedora blessed infrastructure to be put in place, not for any one person to be responsible for populating it
This requires manpower (to check for junk, to clean up entries, to discriminate among conclicting entries, ...). Ask the people at http://www.linuxprinting.org if this is a trivial job. And printers are outside the box, so it is /simple/ compared to all possible strange interactions among in-box pieces.
I may be ignorant on the finer details, but between the outputs of lspci, and lsusb, how many dupplicates can their possibly be?
While it may be non trivial to maintain linuxprinting.org it is a very useful resource for pre-purchase printer considerations.
Google is a great resource, but it only goes so far.
I recently had to setup an older sound interface pci card on a fedora box I setup at work. And indiciations were bright that it was linux compatible and fully alsa supported. I did a locate and found the module already in the fedora kernel tree , i thought great.
2-3 hours later I finally found out that the card needed firmware, not available in extras or core, and just barely mentioned on the driver's author's page.
It would have been nice to know that the kernel module is Fedora compatible, but the firmware (to make the device work) is not.
The benefit of this being that next time I'm buying hardware, I can scurry over to the db and check what the best options are.
For higher-end stuff the data is usually at hand, for el-cheapo not (and better stay away from that in any case).
I'm not sure what more one needs than the output of lspci, and lsusb, and dmesg...of course I could be missing something here.
Arthur Pemberton pemboa@gmail.com wrote:
On 1/10/07, Horst H. von Brand vonbrand@inf.utfsm.cl wrote: [...]
[...]
All I'm asking for a Fedora blessed infrastructure to be put in place, not for any one person to be responsible for populating it
This requires manpower (to check for junk, to clean up entries, to discriminate among conclicting entries, ...). Ask the people at http://www.linuxprinting.org if this is a trivial job. And printers are outside the box, so it is /simple/ compared to all possible strange interactions among in-box pieces.
I may be ignorant on the finer details, but between the outputs of lspci, and lsusb, how many dupplicates can their possibly be?
I've seen a WiFi card with a (somewhat) supported TI chipset which didn't work at all, due to differences in the handling of firmware by the rest of the card (or that was what we ended up suspecting, as firmware loading just didn't work). lspci/lsusb saying something is no guarantee that the rest of the card isn't screwed up beyond hope.
While it may be non trivial to maintain linuxprinting.org it is a very useful resource for pre-purchase printer considerations.
Yes. Now multiply that job by 10 (WiFi cards, say, have a much shorter lifespan than printers and there are much more companies making the stuff) for each type of device out there, and you are in the ballpark of what this requires.
Google is a great resource, but it only goes so far.
A web page purporting to list all devices supported by Fedora will make information materialize out of thin air exactly how? If it ain't in Google, it doesn't exist...
But what do I know... set up the webpage and start collecting data. I'd love to be proven wrong.
I recently had to setup an older sound interface pci card on a fedora box I setup at work. And indiciations were bright that it was linux compatible and fully alsa supported. I did a locate and found the module already in the fedora kernel tree , i thought great.
2-3 hours later I finally found out that the card needed firmware, not available in extras or core, and just barely mentioned on the driver's author's page.
It would have been nice to know that the kernel module is Fedora compatible, but the firmware (to make the device work) is not.
If the /author/ doesn't tell you that, how are the Fedora folks to know about that minor detail?
The benefit of this being that next time I'm buying hardware, I can scurry over to the db and check what the best options are.
For higher-end stuff the data is usually at hand, for el-cheapo not (and better stay away from that in any case).
I'm not sure what more one needs than the output of lspci, and lsusb, and dmesg...of course I could be missing something here.
lspci(8) mostly tells you the base chip in the card, and to get there you have to install it somewhere sane. Won't work for buying a card by mail order. And that is not enough, as other pieces/variations of the chip might (or not) work.
On Thu, Jan 11, 2007 at 09:51:52 -0300, "Horst H. von Brand" vonbrand@inf.utfsm.cl wrote:
Arthur Pemberton pemboa@gmail.com wrote:
2-3 hours later I finally found out that the card needed firmware, not available in extras or core, and just barely mentioned on the driver's author's page.
It would have been nice to know that the kernel module is Fedora compatible, but the firmware (to make the device work) is not.
If the /author/ doesn't tell you that, how are the Fedora folks to know about that minor detail?
OpenBSD might have information on whether or not the firmware has a license that permits redistribution. If it does, then you can probably get it from them if it isn't in the Fedora driver. If it doesn't then Fedora shouldn't have it and you will want to see if the manufacturer distributes it under acceptible terms from their website.
On Sun, 2007-01-07 at 06:10 -0600, Arthur Pemberton wrote:
- I haven't heard much of Python 2.5 for Fedora 7. Comments would be
appreciated.
It's already in rawhide and thus will be in Fedora 7. It could have a bullet on the feature list, but new foo x.y.z just isn't that interesting as a "feature", IMHO
Jeremy
On 2007-01-04, Bill Nottingham said:
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
- Make LiveCDs as a part of the distribution release process
- Ability to customize non-packaging distrubution parameters
- Switch to libata drivers for PATA support
- Speedup of bootup and shutdown
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
- CodecBuddy
- Fixing the proliferation of dictionary packages
- Support encrypted filesystems
- Fast user switching in the desktop
- Fix the firewire stack
- Switch to a tickless kernel by default
- Fix unnecessary wakeups across the distribution
- Add KVM virtualization support to our tools
- Investigate (but probably don't switch to) new init technologies
- Add the nouveau drivers for nVidia cards
- Speed up Yum and RPM
- Add support for RandR 1.2
- Switch to syslog-ng
- Make the update system useable by all
It will also be good to finalize the ruby and rails packing guidelines so that people can start packing things.
On Tue, 2007-01-16 at 07:15 +0000, Leo wrote:
It will also be good to finalize the ruby and rails packing guidelines so that people can start packing things.
The ruby guidelines have been around for a while [1]; what we don't have is guidelines on packaging rubygems. That's a little more difficult since gems implement their own packaging system, and making sure that rpm-packaged gems and plain gems interoperate nicely requires some thought (and work) In addition, gems are not suitable for distributing binary extensions since they lack any semblance of multilib support.
Having said all that, I have packaged ruby-activerecord and ruby-activesupport; one day, I swear I'll package the rest of rails, but I'd love to see somebody beat me to it.
David