Hi All,
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge. I tried to get an industrial firewire camera to work with the stock Fedora kernel using the juju stack. Long story short, it didn't work.
Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really surprising, quoting that page: "Almost no support for IIDC cameras: Not compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. Improvements are to be expected in Linux 2.6.25-rc1."
Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras). Add to that that the above referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers."
Does this mean that Fedora should not have shipped the new stack? No it doesn't! Getting code out there early into many hands for testing is a good thing.
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
---
Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL: https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&comp...
Again I think its good to be shipping this, and even that its good having it on by default, but we should also provide a small gui utility for easily turning ir off.
---
Considering the current state of affairs with regards to both features, I would even like to advocate to make them both optional for Fedora 9.
Regards,
Hans
p.s.
I'll also be posting this to my blog for some wider exposure.
On 09.01.2008 19:45, Hans de Goede wrote:
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
+1
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge.
See below. But actually I think we here and there are not even cutting edge enough; we for example left users on Firefox2 for FC6 for about 7 months until we shipped F7 -- that looked totally odd for a distribution that is curring edge in most other areas.
Another example: hplip is still on 2.7.7 for F8 right now while upstream is at 2.7.12 in between and supports 22 new printers ( http://hplip.sourceforge.net/release_notes.html ). We don't provide any solutions for users that buy those printers right now besides using rawhide. Thus they have to wait/ask for a proper update or wait until F9 or -- the latter means waiting about 6 months for driver. That's IMHO unacceptable -- especially as printer manufacturers release successor models quite often (it feels to me like a new successor model get released in each printer class about once a year, but I didn't check).
I tried to get an industrial firewire camera to work with the stock Fedora kernel using the juju stack. Long [...] story short, it didn't work.
Does this mean that Fedora should not have shipped the new stack? No it doesn't! Getting code out there early into many hands for testing is a good thing.
+1
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
That's what I call "Fedora knows better then you". It's afaics not the first time Fedora forces users to use a new technology instead of giving them a choice for a small period. For example there are still users that would like to use the ntfs-module from the kernel, but we don't enable it (making ntfs-3g the default and eabling ntfs in the kernel should solve this problem). Another example: Xgl never made it into the Fedora repos (which in parts is due to packaging problems, but it looks a bit odd). Another example: Zope/Plone was excluded in F7 and later because we jumped to python 2.5 but didn't want to ship a compat-python package (this + Zope/Plone are now in livna for F7 and soon F8 and devel).
Another example of Fedora being to cutting edge is pulseaudio, [...]
Not sure about pulseaudio -- works well for me afaics. But yeah, might be a similar issue.
Linux is about choice.
Just my 2 cent.
Cu knurd
Thorsten Leemhuis wrote:
Another example: hplip is still on 2.7.7 for F8 right now while upstream is at 2.7.12 in between and supports 22 new printers ( http://hplip.sourceforge.net/release_notes.html ). We don't provide any solutions for users that buy those printers right now besides using rawhide. Thus they have to wait/ask for a proper update or wait until F9 or -- the latter means waiting about 6 months for driver. That's IMHO unacceptable -- especially as printer manufacturers release successor models quite often (it feels to me like a new successor model get released in each printer class about once a year, but I didn't check).
What about NetworkManger? While our release engineers were screaming "It's not ready!" and refusing to enable it by default, Ubuntu was being credited for saving linux with it.
--CJD
On Jan 9, 2008 1:20 PM, Casey Dahlin cjdahlin@ncsu.edu wrote:
Thorsten Leemhuis wrote:
Another example: hplip is still on 2.7.7 for F8 right now while upstream is at 2.7.12 in between and supports 22 new printers ( http://hplip.sourceforge.net/release_notes.html ). We don't provide any solutions for users that buy those printers right now besides using rawhide. Thus they have to wait/ask for a proper update or wait until F9 or -- the latter means waiting about 6 months for driver. That's IMHO unacceptable -- especially as printer manufacturers release successor models quite often (it feels to me like a new successor model get released in each printer class about once a year, but I didn't check).
What about NetworkManger? While our release engineers were screaming "It's not ready!" and refusing to enable it by default, Ubuntu was being credited for saving linux with it.
There are always going to be examples of something that is chosen or not chosen to work with a release.. and some other distro is going to do it and get the credit. Fedora has probably gotten credit for things that Ubuntu was too extreme.. Choices have to be made of how many engineers are going to focus on some problem and what problems will have to wait.
Linux is about choice.
If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again.
As a consumer, yes, you have lots of choices in which Linux you use. This does not mean Linux is in any sense _about_ choice, any more than because there are so many kinds of cars you can buy that cars are about choice.
The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once. If you try to deliver both at once you have to also deliver a way of switching between the two. Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions). We have essentially already posited that we have insufficient developer effort to have 100%-complete features at ship time, so asking them to take on six times the failure rate when they're already overburdened is just madness. Alternatively, we could say that we're integrating features too rapidly, but you do that at the expense of goal 1, to be the showcase for the latest and greatest in free software.
Software is hard. The way to fix it is to fix it, not sweep it under the rug.
There is a legitimate discussion to be had about where and how we draw the line for feature inclusion, about how we increase and formalize our testing efforts, and about how we develop and deploy spike solutions for corner-case problems like the one device class that juju happens to do worse than the old stack. But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
- ajax
On Wed, 09 Jan 2008 15:58:45 -0500 Adam Jackson ajackson@redhat.com wrote:
But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
I cannot agree more.
On Jan 9, 2008 9:46 PM, Jesse Keating jkeating@redhat.com wrote:
On Wed, 09 Jan 2008 15:58:45 -0500 Adam Jackson ajackson@redhat.com wrote:
But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
I cannot agree more.
+1000
On Wed, 2008-01-09 at 15:58 -0500, Adam Jackson wrote:
Linux is about choice.
If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again.
Damn you where's my FreeBSD kernel package for Fedora?
:)
Dave.
On Thu, Jan 10, 2008 at 06:52:52AM +1000, Dave Airlie wrote:
Damn you where's my FreeBSD kernel package for Fedora?
Weren't the Debian people targeting at a GNU Hurd-based version of their distro? :-)
On 2008-01-09, 20:52 GMT, Dave Airlie wrote:
Damn you where's my FreeBSD kernel package for Fedora?
You have to for it somewhere else http://www.us.debian.org/ports/kfreebsd-gnu/
:-)
Matěj
On Thu, Jan 10, 2008 at 06:52:52AM +1000, Dave Airlie wrote:
On Wed, 2008-01-09 at 15:58 -0500, Adam Jackson wrote:
Linux is about choice.
If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again.
Damn you where's my FreeBSD kernel package for Fedora?
I guess that you are joking, but I think that a FreeBSD kernel package is perfectly right for fedora. It should not go in a stable release until it is stable, and could be less well integrated than the linux kernel but it would definitively be something interesting.
-- Pat
Patrice Dumas wrote:
Linux is about choice.
If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again.
Damn you where's my FreeBSD kernel package for Fedora?
I guess that you are joking, but I think that a FreeBSD kernel package is perfectly right for fedora. It should not go in a stable release until it is stable, and could be less well integrated than the linux kernel but it would definitively be something interesting.
Can we have OpenSolaris (with zfs) too? I was going to point out that Linux wasn't about choice but about providing a free and compatible alternative to Unix. But this would complete the circle...
Les Mikesell wrote:
Can we have OpenSolaris (with zfs) too? I was going to point out that Linux wasn't about choice but about providing a free and compatible alternative to Unix. But this would complete the circle...
You can have a lot of things if you step up to contribute. Wishlists are already overflowing.
Rahul
On 2008-01-10, 00:08 GMT, Les Mikesell wrote:
Can we have OpenSolaris (with zfs) too? I was going to point out that Linux wasn't about choice but about providing a free and compatible alternative to Unix. But this would complete the circle...
I would put my hope into http://oss.oracle.com/projects/btrfs/ rather than into port of ZFS on Linux. Yes, it is still alpha, and yes Oracle could screw it up somehow (I don't exepct it, though), but creating our own implementation of the stuff seems like The Linux Way (rather than whinning that Sun didn't give us the candy).
Matej
Matej Cepl wrote:
On 2008-01-10, 00:08 GMT, Les Mikesell wrote:
Can we have OpenSolaris (with zfs) too? I was going to point out that Linux wasn't about choice but about providing a free and compatible alternative to Unix. But this would complete the circle...
I would put my hope into http://oss.oracle.com/projects/btrfs/ rather than into port of ZFS on Linux. Yes, it is still alpha, and yes Oracle could screw it up somehow (I don't exepct it, though), but creating our own implementation of the stuff seems like The Linux Way (rather than whinning that Sun didn't give us the candy).
Zfs isn't the only interesting thing about opensolaris and Sun does give you the candy if you take the whole package. It is only the Linux terms that keep you from adding the parts. Solaris has an entirely different attitude about backwards compatibility which makes the mention slightly on topic for this conversation. I can't, for example, imagine them ever changing a device name arbitrarily and breaking a previously working configuration while Linux has no such respect for its users' previous work. Fedora may not be the place for it, but I would seriously like to see a distribution based on the OpenSolaris kernel and the same user programs you'd find in a current Linux or *bsd distro. If nothing else, it would be an interesting exercise in testing Posix compatibility.
On Thu, Jan 10, 2008 at 08:06:53AM -0600, Les Mikesell wrote:
Zfs isn't the only interesting thing about opensolaris and Sun does give you the candy if you take the whole package. It is only the Linux terms that keep you from adding the parts. Solaris has an entirely different attitude about backwards compatibility which makes the mention slightly on topic for this conversation. I can't, for example, imagine them ever changing a device name arbitrarily and breaking a previously working configuration while Linux has no such respect for its users' previous work. Fedora may not be the place for it, but I would seriously like to see a distribution based on the OpenSolaris kernel and the same user programs you'd find in a current Linux or *bsd distro.
Given that it's the user programs that have the lack of respect for previous configurations (Linus considers backwards-compatibility very important), I doubt you'll see any change for the better.
OG.
Olivier Galibert wrote:
On Thu, Jan 10, 2008 at 08:06:53AM -0600, Les Mikesell wrote:
Zfs isn't the only interesting thing about opensolaris and Sun does give you the candy if you take the whole package. It is only the Linux terms that keep you from adding the parts. Solaris has an entirely different attitude about backwards compatibility which makes the mention slightly on topic for this conversation. I can't, for example, imagine them ever changing a device name arbitrarily and breaking a previously working configuration while Linux has no such respect for its users' previous work. Fedora may not be the place for it, but I would seriously like to see a distribution based on the OpenSolaris kernel and the same user programs you'd find in a current Linux or *bsd distro.
Given that it's the user programs that have the lack of respect for previous configurations (Linus considers backwards-compatibility very important), I doubt you'll see any change for the better.
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily - or turns what used to be detected as eth0 into eth2 when a different kernel is booted? Admittedly it has been a while since I've used Solaris, but I can't recall anything like that ever happening with it. In a unix-like system where access to everything is through its device/file name, what is more fundamental than that?
On Thursday, 10 January 2008 at 16:31, Les Mikesell wrote:
Olivier Galibert wrote:
On Thu, Jan 10, 2008 at 08:06:53AM -0600, Les Mikesell wrote:
Zfs isn't the only interesting thing about opensolaris and Sun does give you the candy if you take the whole package. It is only the Linux terms that keep you from adding the parts. Solaris has an entirely different attitude about backwards compatibility which makes the mention slightly on topic for this conversation. I can't, for example, imagine them ever changing a device name arbitrarily and breaking a previously working configuration while Linux has no such respect for its users' previous work. Fedora may not be the place for it, but I would seriously like to see a distribution based on the OpenSolaris kernel and the same user programs you'd find in a current Linux or *bsd distro.
Given that it's the user programs that have the lack of respect for previous configurations (Linus considers backwards-compatibility very important), I doubt you'll see any change for the better.
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily
Can you say "filesystem labels"? I thought so.
- or turns what used to be detected as eth0 into eth2 when
a different kernel is booted?
echo -e "alias eth0 module1\nalias eth2 module2\n" >> /etc/modprobe.conf has always worked for me.
Have you filed a bug?
Regards, R.
Dominik 'Rathann' Mierzejewski wrote:
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily
Can you say "filesystem labels"? I thought so.
I can say it won't fix an existing configuration. I can say that filesystem label creation wasn't well thought out for people that move disks around (after you've installed fedora on all your machines, they'll all have the same labels and the system is not happy when you rebuild a machine with a different combination of drives). I can say that the design of solaris seems to take machine management over long intervals of time and large numbers of machines into consideration whereas Linux does not.
- or turns what used to be detected as eth0 into eth2 when
a different kernel is booted?
echo -e "alias eth0 module1\nalias eth2 module2\n" >> /etc/modprobe.conf has always worked for me.
That worked in 2.4 kernels. It doesn't with udev based kernels. And if you managed some number of machines with multiple interfaces you'd probably care - especially if they are remote and you lose access when the network doesn't come up after a reboot.
Have you filed a bug?
Is it a bug or is udev supposed to detect devices in parallel and dynamically (randomly)? It is the same with /dev/sdX devices. How do I know which one is /dev/sdh today? And If I don't know, even If I wanted to use filesystem labels, what would I call the device when I wanted to create the label? (BTW, what I usually do to work around this issue is create an md raid device even if it is a single drive with a missing partner and use the md device name in the fstab entry because at least so far I have been able to count on consistency in detecting the uuids and have always gotten unique ones by default).
Les Mikesell wrote:
Dominik 'Rathann' Mierzejewski wrote:
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily
Can you say "filesystem labels"? I thought so.
I can say it won't fix an existing configuration. I can say that filesystem label creation wasn't well thought out for people that move disks around (after you've installed fedora on all your machines, they'll all have the same labels and the system is not happy when you rebuild a machine with a different combination of drives).
I can answer this one: Require people to name their system at install (like windows, like macosx, e.g. john-pc), perhaps with a default coming from install date (200807110711), and then make the default fslabels be prefixed with that name and an underscore. e.g. john-pc_/usr
problem solved.
-dmc
I can say
that the design of solaris seems to take machine management over long intervals of time and large numbers of machines into consideration whereas Linux does not.
On Thu, 2008-01-10 at 09:31 -0600, Les Mikesell wrote:
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily - or turns what used to be detected as eth0 into eth2 when a different kernel is booted? Admittedly it has been a while since I've used Solaris, but I can't recall anything like that ever happening with it. In a unix-like system where access to everything is through its device/file name, what is more fundamental than that?
This is a flawed example. The problem is that you're relying on names assigned in an irregular fashion and it will happen on Solaris as well if you move disks between controllers etc. The way to do this in the modern world is to rely on persistent names. See /dev/disk/* and the udev rules for stable network interface names. Of course you can argue that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're going to find much sympathy for such a point of view.
David
On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote:
udev rules for stable network interface names.
Btw, that would be
/etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/75-persistent-net-generator.rules
HTH. Follow up with questions on the udev list please.
David
On Jan 10, 2008 10:31 AM, David Zeuthen david@fubar.dk wrote:
On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote:
udev rules for stable network interface names.
Btw, that would be
/etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/75-persistent-net-generator.rules
HTH. Follow up with questions on the udev list please.
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
David
On Jan 10, 2008 10:54 AM, David Zeuthen david@fubar.dk wrote:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
Most people don't need to worry about udev issues like mine, unless MythTV with multiple video cards very popular soon
On Thu, 2008-01-10 at 11:00 -0600, Arthur Pemberton wrote:
On Jan 10, 2008 10:54 AM, David Zeuthen david@fubar.dk wrote:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
Most people don't need to worry about udev issues like mine, unless MythTV with multiple video cards very popular soon
The idea is that not even you should have to worry about it -- they should just work, i.e. if the hardware is present, the modules are loaded, device nodes are created and PolicyKit has a reasonable default policy for that class of hardware (e.g. "active sessions have access to the device"). My guess is that you tweaked the udev files to get access as a non-root user? In an ideal world this shouldn't be necessary, if you have to tweak things, please file a bug as well so when your modifications get overwritten (with an update) your stuff still works (hopefully).
It's unfortunate that the udev rules are in /etc which conveys the (wrong) message that changes would be persistent over upgrades, but reading the thread that might get fixed.
Nils
On Thu, 2008-01-10 at 11:54 -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
There's the bad idea that everything under /etc/ is configurable, but in reality these rules are "program data" and ideally should go into /share if that existed (which would avoid people thinking they're meant to touch that stuff, hopefully).
Nils
On Thu, 2008-01-10 at 18:03 +0100, Nils Philippsen wrote:
There's the bad idea that everything under /etc/ is configurable, but in reality these rules are "program data" and ideally should go into /share if that existed (which would avoid people thinking they're meant to touch that stuff, hopefully).
I agree it's confusing / misleading that udev stores it's rules in /etc. They are, as you point out, really just program data (at least 99% of them). I'll talk to upstream about moving the bulk to /lib[64]/udev instead.
David
David Zeuthen (david@fubar.dk) said:
I agree it's confusing / misleading that udev stores it's rules in /etc. They are, as you point out, really just program data (at least 99% of them). I'll talk to upstream about moving the bulk to /lib[64]/udev instead.
Just /lib, please. I can't imagine why they'd need separate /lib | /lib64 rules (and it already uses /lib/udev...)
(Red bikeshed, dammit!)
Bill
Nils Philippsen wrote:
On Thu, 2008-01-10 at 11:54 -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
There's the bad idea that everything under /etc/ is configurable, but in reality these rules are "program data" and ideally should go into /share if that existed (which would avoid people thinking they're meant to touch that stuff, hopefully).
I'm having trouble parsing that statement. Are you saying that people shouldn't be able to edit their own /etc/xxx files as documented by the upstream programs or that the distribution should move the parts that it modifies with its internal tools elsewhere?
On Thu, 2008-01-10 at 11:20 -0600, Les Mikesell wrote:
Nils Philippsen wrote:
On Thu, 2008-01-10 at 11:54 -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
There's the bad idea that everything under /etc/ is configurable, but in reality these rules are "program data" and ideally should go into /share if that existed (which would avoid people thinking they're meant to touch that stuff, hopefully).
I'm having trouble parsing that statement. Are you saying that people shouldn't be able to edit their own /etc/xxx files as documented by the upstream programs or that the distribution should move the parts that it modifies with its internal tools elsewhere?
Lots of files under /etc are not marked as %config or %config(noreplace) and they are not really configuration files. It's a problem because novice users just assume they can and should edit such files and then they get confused when said file is overwritten on a package upgrade.
Does that make more sense?
David
Hi All,
As the one who has started this thread:
Can we pretty pretty please stop the flamefest and move on to something more productive. I know I have, I'm currently working together with the juju developers to fix my issues, so that in the end we will have only one stack, and one that works well.
I tried to ask a serious question in the top level post, and tried to formulate it in a non inflaming way, well guess I failed there :(
Regards,
Hans
David Zeuthen wrote:
There's the bad idea that everything under /etc/ is configurable, but in reality these rules are "program data" and ideally should go into /share if that existed (which would avoid people thinking they're meant to touch that stuff, hopefully).
I'm having trouble parsing that statement. Are you saying that people shouldn't be able to edit their own /etc/xxx files as documented by the upstream programs or that the distribution should move the parts that it modifies with its internal tools elsewhere?
Lots of files under /etc are not marked as %config or %config(noreplace) and they are not really configuration files. It's a problem because novice users just assume they can and should edit such files and then they get confused when said file is overwritten on a package upgrade.
Does that make more sense?
It doesn't disambiguate the situation unless you are saying that local administrators should not touch any files. How does a (novice or not) user know which files belong to him but are delivered as working defaults and which will be clobbered by subsequent updates? I thought most of the point of splattering stuff under /etc/sysconfig was to have a place to put distribution-tool managed bits without too much impact on standard, documented config files as they would work in other distributions.
On Thu, 2008-01-10 at 12:48 -0600, Les Mikesell wrote:
It doesn't disambiguate the situation unless you are saying that local administrators should not touch any files. How does a (novice or not) user know which files belong to him but are delivered as working defaults and which will be clobbered by subsequent updates? I thought most of the point of splattering stuff under /etc/sysconfig was to have a place to put distribution-tool managed bits without too much impact on standard, documented config files as they would work in other distributions.
The problem is that a lot of software erroneously place files in /etc. Ideally all files (and that should be very few files!) in /etc should be safe to edit by the system administrator.
David
David Zeuthen wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options.
How can it work 'out of the box' when the person who knows which of many possible devices is which is separated from the kernel and device driver by a hidden level of indirection introduced between versions?
On Thu, 2008-01-10 at 11:07 -0600, Les Mikesell wrote:
How can it work 'out of the box' when the person who knows which of many possible devices is which is separated from the kernel and device driver by a hidden level of indirection introduced between versions?
By getting things properly integrated with the kernel and udev. Yes, there's a lot of drivers that needs fixing; mostly because the authors of said drivers thought it was "good enough" to require all sort of weird kernel module parameters and have people edit things like /etc/modprobe.conf and whatnot.
David
Once upon a time, David Zeuthen david@fubar.dk said:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box.
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
On Jan 10, 2008 12:45 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, David Zeuthen david@fubar.dk said:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box.
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
I have no idea myself, and I have spent a few hours pondering the problem. The only solution I have come up with is to keep things as they are, but generate symantic aliases for them.
Example:
/dev/video1 -> /dev/video_hauppauge_iptv
Far from perfect however, but would be adequate for my needs.
On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote:
Once upon a time, David Zeuthen david@fubar.dk said:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box.
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
For the latter, there is going to be some development for F10, F11 and later in merging the hal and udev databases into a common device database that will feature persistent properties (such as classification and device naming) keyed off by-path, by-id and so on to easily make a feature like this available. That's the answer to this (very real) problem, not a silly program that generates udev rules.
David
On Jan 10, 2008 1:02 PM, David Zeuthen david@fubar.dk wrote:
On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote:
Once upon a time, David Zeuthen david@fubar.dk said:
On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Hell no. We are in badly need of this crap just working out of the box.
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
You're wierd dude, this essentially the same thing I suggested and you discouraged.
Arthur Pemberton wrote:
Hell no. We are in badly need of this crap just working out of the box.
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
You're wierd dude, this essentially the same thing I suggested and you discouraged.
The system can't possibly work with multiple choices unless you have an interface to let a human configure which is which. Now the kicker is that most of my machines are in remote locations with swappable drives and I expect to be able to ship a pre-configured drive built locally and have someone pop it in a known controller position and have it come up working - and to be able to copy images that will work across a number of identical machines without individual attention other than setting the hostname and IP addresses.
On Jan 10, 2008 1:57 PM, Les Mikesell lesmikesell@gmail.com wrote:
Arthur Pemberton wrote:
Hell no. We are in badly need of this crap just working out of the box.
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
You're wierd dude, this essentially the same thing I suggested and you discouraged.
The system can't possibly work with multiple choices unless you have an interface to let a human configure which is which. Now the kicker is that most of my machines are in remote locations with swappable drives and I expect to be able to ship a pre-configured drive built locally and have someone pop it in a known controller position and have it come up working - and to be able to copy images that will work across a number of identical machines without individual attention other than setting the hostname and IP addresses.
I would have thought that with dirves you can jsut mount by labels, does this not work for your use case?
Arthur Pemberton wrote:
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
You're wierd dude, this essentially the same thing I suggested and you discouraged.
The system can't possibly work with multiple choices unless you have an interface to let a human configure which is which. Now the kicker is that most of my machines are in remote locations with swappable drives and I expect to be able to ship a pre-configured drive built locally and have someone pop it in a known controller position and have it come up working - and to be able to copy images that will work across a number of identical machines without individual attention other than setting the hostname and IP addresses.
I would have thought that with dirves you can jsut mount by labels, does this not work for your use case?
First, disks aren't born with labels. Second, most of my disks get created by dd'ing an existing raw disk or the equivalent, generally on a different machine and not necessarily under an exactly matching kernel that would know the filesystem or how to label it. Third, you can't use labels for fdisk/mkfs, or even dump and I'd really like to know which physical drive is going to be the target of those commands. I realize it is not an easy question. For example the adaptec SAS raid controller in an ibm 3550 maps drives to volumes internally and remembers them even if you only have one drive in a volume. That is, if you build a master image in the first slot, dd it to the drive in the 2nd slot, take that 2nd disk and put in the first slot of another and attempt to copy again, your disk with contents will be detected as /dev/sdb (remembered) instead of sda from being in the first position. This is fun when you try to repeat the dd command expecting the same thing to happen.
Anyway, the long-winded point is that you do more things with disks than mount the file systems they contain, so a label doesn't solve the identification problem.
On Thu, 2008-01-10 at 13:28 -0600, Arthur Pemberton wrote:
On Jan 10, 2008 1:02 PM, David Zeuthen david@fubar.dk wrote:
On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote:
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
You're wierd dude, this essentially the same thing I suggested and you discouraged.
I guess throwing around terms like "system-config-udev" might have gotten something different across than you meant then (sometimes you just need to spent the time to type out what you mean if you don't want people to guess ;-).
A user interface to e.g. assign different serial ports to different functions are okay. GUI tools to fix broken/outdated udev rules are maybe a workaround, but not a solution. Such tools would possibly delay things getting fixed up for other users.
Nils
Once upon a time, David Zeuthen david@fubar.dk said:
On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote:
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
Since they are all USB-to-RS232 adapters, you can't tell anything by USB info (they are all interfacing to RS232 devices). Two of them use the same driver, and annoyingly, the chip vendor for that USB-to-RS232 doesn't set a serial number, so the only way to distinguish them is via USB port.
Also, some GNOME thing is not a solution, as I'd like my UPS and GPS to be active on boot (the GPS is used by NTP for clock sync), not some time later after a user logs in.
That's the answer to this (very real) problem, not a silly program that generates udev rules.
So then we have to have two things running trying to name devices? I thought udev was supposed to be "the" solution. Using udev rules is easy, it is just that writing them is beyond the point-n-click user.
On Thu, 2008-01-10 at 21:30 -0600, Chris Adams wrote:
Once upon a time, David Zeuthen david@fubar.dk said:
On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote:
And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)?
Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it.
Since they are all USB-to-RS232 adapters, you can't tell anything by USB info (they are all interfacing to RS232 devices). Two of them use the same driver, and annoyingly, the chip vendor for that USB-to-RS232 doesn't set a serial number, so the only way to distinguish them is via USB port.
I guess such a simple interface would tie the custom configuration of such a USB device to its hardware info and the USB path where to device is plugged.
Also, some GNOME thing is not a solution, as I'd like my UPS and GPS to be active on boot (the GPS is used by NTP for clock sync), not some time later after a user logs in.
The resulting policy shouldn't depend on any desktop.
That's the answer to this (very real) problem, not a silly program that generates udev rules.
So then we have to have two things running trying to name devices? I thought udev was supposed to be "the" solution. Using udev rules is easy, it is just that writing them is beyond the point-n-click user.
It might just be that the result of "a simple interface in gnome-device-manager or similar" is a bunch of udev rules (which ironically would belong into /etc instead of /lib/udev as this is the exceptional case where we talk about configuration, not working around omissions in udev rules).
Nils
Arthur Pemberton wrote:
On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote:
udev rules for stable network interface names.
Btw, that would be
/etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/75-persistent-net-generator.rules
HTH. Follow up with questions on the udev list please.
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Is this another work-in-progress? I don't have anything handy newer than FC6 which doesn't have persistent-net.rules and a similar question on the Centos list mentioned that ethX devices can be renamed when the the ifup scripts run.
Les Mikesell (lesmikesell@gmail.com) said:
We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config
Is this another work-in-progress? I don't have anything handy newer than FC6 which doesn't have persistent-net.rules and a similar question on the Centos list mentioned that ethX devices can be renamed when the the ifup scripts run.
persistent-net.rules in Fedora is a F8 and later thing.
Bill
David Zeuthen wrote:
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily - or turns what used to be detected as eth0 into eth2 when a different kernel is booted? Admittedly it has been a while since I've used Solaris, but I can't recall anything like that ever happening with it. In a unix-like system where access to everything is through its device/file name, what is more fundamental than that?
This is a flawed example. The problem is that you're relying on names assigned in an irregular fashion and it will happen on Solaris as well if you move disks between controllers etc.
But the old names were predictable; the new ones aren't - when I move a disk to a new controller/drive position, I know about it.
The way to do this in the modern world is to rely on persistent names. See /dev/disk/* and the udev rules for stable network interface names. Of course you can argue that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're going to find much sympathy for such a point of view.
What I actually would argue is that a distribution making such changes should supply tools to migrate configurations based on old conventions to the new ones. Maybe Fedora doesn't have users with hundreds of machines and data that needs to span years of operation, but a unix-like system should be designed to make that practical.
On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote:
But the old names were predictable; the new ones aren't - when I move a disk to a new controller/drive position, I know about it.
Uhm, no. You were just relying on a) limitations in the Linux kernel to probe devices in a sequential fashion (see big-iron boxes with tens of thousands of disks why this won't work); and b) the order of your controllers on the PCI bus. Trying to argue it was "predictable" when it was a "coincidence" is an interesting spin on reality. It's also wrong; there's a reason that RHL and Fedora been using LABEL= for ages.
A side effect of Fedora and Linux being modernized is that you have stable names so in the future problems like you describe will go away. However, one issue is to make all the stuff in the distro actually take advantage of new shiny stuff; for example Anaconda just recently started to take it's first steps in the brave new world. It's a bit sad that it takes 2-3 years for things like this to happen, maybe someone having been yelling enough at e.g. the Anaconda team ;-)
What I actually would argue is that a distribution making such changes should supply tools to migrate configurations based on old conventions to the new ones. Maybe Fedora doesn't have users with hundreds of machines and data that needs to span years of operation, but a unix-like system should be designed to make that practical.
No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices.
David
David Zeuthen wrote:
On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote:
But the old names were predictable; the new ones aren't - when I move a disk to a new controller/drive position, I know about it.
Uhm, no. You were just relying on a) limitations in the Linux kernel to probe devices in a sequential fashion (see big-iron boxes with tens of thousands of disks why this won't work); and b) the order of your controllers on the PCI bus. Trying to argue it was "predictable" when it was a "coincidence" is an interesting spin on reality. It's also wrong; there's a reason that RHL and Fedora been using LABEL= for ages.
OK, that's at least partly right but you forgot to tell me what to call the device when creating the label for filesystems that support it - or what name to use for access to the raw device for operations like image copies and addition/removal from raid arrays. The underlying problem can't be solved at the filesystem layer.
What I actually would argue is that a distribution making such changes should supply tools to migrate configurations based on old conventions to the new ones. Maybe Fedora doesn't have users with hundreds of machines and data that needs to span years of operation, but a unix-like system should be designed to make that practical.
No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices.
I haven't found that to be the case. And I don't see any reason for today's experimental change to end up being the one that sticks.
On Thu, 2008-01-10 at 11:31 -0600, Les Mikesell wrote:
OK, that's at least partly right but you forgot to tell me what to call the device when creating the label for filesystems that support it - or what name to use for access to the raw device for operations like image copies and addition/removal from raid arrays. The underlying problem can't be solved at the filesystem layer.
Uhm. Did you *even* look at /dev/disk? There's by-path, by-uuid, by-label and so forth. Heck, SUSE/Ubuntu ships udev rules for making the md and dm devices use persistent naming too. Maybe if the distros were better at working together at the plumbing layer (another rant of mine)), this would be all standardized. Eventually it will all be standardized.
No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices.
I haven't found that to be the case. And I don't see any reason for today's experimental change to end up being the one that sticks.
There's nothing experimental about the path modern Linux is going in wrt. to device naming. If you had bothered you will fine that more and more device classes, including the infamous video4linux camp, is moving to persistent device names. It's true, however, that Fedora is super-reluctant on taking advantage of what happens upstream and keep using pre-2000 technology. That's, very slowly, changing though.
David
David Zeuthen wrote:
OK, that's at least partly right but you forgot to tell me what to call the device when creating the label for filesystems that support it - or what name to use for access to the raw device for operations like image copies and addition/removal from raid arrays. The underlying problem can't be solved at the filesystem layer.
Uhm. Did you *even* look at /dev/disk? There's by-path, by-uuid, by-label and so forth.
I'm looking, but I don't see consistency anywhere across linux kernels. by-uuid, by-label seem to only refer to things that have been created by some other access, by-id doen't always appear, and by-path varies across kernels as the device drivers have changed. Where is something better than device driver major/minor numbers would have been?
Heck, SUSE/Ubuntu ships udev rules for making the md and dm devices use persistent naming too. Maybe if the distros were better at working together at the plumbing layer (another rant of mine)), this would be all standardized. Eventually it will all be standardized.
Do you expect this to be standardized only for Linux or is there hope for a Posix specification for device name conventions?
No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices.
I haven't found that to be the case. And I don't see any reason for today's experimental change to end up being the one that sticks.
There's nothing experimental about the path modern Linux is going in wrt. to device naming. If you had bothered you will fine that more and more device classes, including the infamous video4linux camp, is moving to persistent device names.
If I had bothered to what? Is this documented somewhere? Is it version-specific to fedora?
It's true, however, that Fedora is super-reluctant on taking advantage of what happens upstream and keep using pre-2000 technology. That's, very slowly, changing though.
Much of my data is on filesystems created before 2000. Will changing the names used to reference them make them work better?
On Thu, 2008-01-10 at 13:44 -0600, Les Mikesell wrote:
Uhm. Did you *even* look at /dev/disk? There's by-path, by-uuid, by-label and so forth.
I'm looking, but I don't see consistency anywhere across linux kernels. by-uuid, by-label seem to only refer to things that have been created by some other access, by-id doen't always appear, and by-path varies across kernels as the device drivers have changed. Where is something better than device driver major/minor numbers would have been?
You should use by-uuid. If you see other entries change according to what kernel you are using this should be reported on the udev list
linux-hotplug@vger.kernel.org
and please follow up there with other questions too (it's getting off-topic in this thread and even this list). Thanks.
Do you expect this to be standardized only for Linux or is there hope for a Posix specification for device name conventions?
No, I don't expect this to be standardized outside Linux.
There's nothing experimental about the path modern Linux is going in wrt. to device naming. If you had bothered you will fine that more and more device classes, including the infamous video4linux camp, is moving to persistent device names.
If I had bothered to what? Is this documented somewhere? Is it version-specific to fedora?
That's like asking if all the sysfs are documented somewhere and the answer to questions like that are normally "no, it's self-evident" (and I agree it's not always the case) or "look at the source". Anyway, by all means, send patches to the udev list with docs if you think it's required.
It's true, however, that Fedora is super-reluctant on taking advantage of what happens upstream and keep using pre-2000 technology. That's, very slowly, changing though.
Much of my data is on filesystems created before 2000. Will changing the names used to reference them make them work better?
This question doesn't really make sense to me. What I'm telling you is to use persistent device names. That entails having UUID and/or labels on your file systems. So if you don't have that, by all means, go ahead and create them and things will start appearing under /dev/disk.
Anyway, please use the udev list for further questions. This thread is getting too long. Thanks.
David
On Thu, 2008-01-10 at 14:51 -0500, David Zeuthen wrote:
There's nothing experimental about the path modern Linux is going in wrt. to device naming. If you had bothered you will fine that more and more device classes, including the infamous video4linux camp, is moving to persistent device names.
If I had bothered to what? Is this documented somewhere? Is it version-specific to fedora?
That's like asking if all the sysfs are documented somewhere and the answer to questions like that are normally "no, it's self-evident" (and I agree it's not always the case) or "look at the source". Anyway, by all means, send patches to the udev list with docs if you think it's required.
I wasn't really clear here; I meant if you had followed udev and kernel lists you would see a trend that more and more devices will start using udev rules to provide persistent device names. Hope this clarifies.
David
Les Mikesell wrote:
David Zeuthen wrote:
On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote:
But the old names were predictable; the new ones aren't - when I move a disk to a new controller/drive position, I know about it.
Uhm, no. You were just relying on a) limitations in the Linux kernel to probe devices in a sequential fashion (see big-iron boxes with tens of thousands of disks why this won't work); and b) the order of your controllers on the PCI bus. Trying to argue it was "predictable" when it was a "coincidence" is an interesting spin on reality. It's also wrong; there's a reason that RHL and Fedora been using LABEL= for ages.
OK, that's at least partly right but you forgot to tell me what to call the device when creating the label for filesystems that support it - or what name to use for access to the raw device for operations like image copies and addition/removal from raid arrays. The underlying problem can't be solved at the filesystem layer.
Try cat /etc/mtab. The device being used for the particular label is clearly shown after its mounted, even when auto mounted by label in /etc/fstab. I fail to see what is so hidden here. When the device is connected to the machine its also identified in log messages as to which device node it is assigned.
What I actually would argue is that a distribution making such changes should supply tools to migrate configurations based on old conventions to the new ones. Maybe Fedora doesn't have users with hundreds of machines and data that needs to span years of operation, but a unix-like system should be designed to make that practical.
No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices.
I haven't found that to be the case. And I don't see any reason for today's experimental change to end up being the one that sticks.
Anaconda should have handled changing your configuration change in /etc/fstab for you at install if all your partitions were labeled. If they aren't all labeled this doesn't happen, which is a short-coming of anaconda in that it will not apply labels to FAT32 or NTFS disks that do not have them (and maybe other filesystems). There are also bugs against anaconda about this and I think a number of them are closed rawhide so it should be better now.
Andrew Farris wrote:
OK, that's at least partly right but you forgot to tell me what to call the device when creating the label for filesystems that support it - or what name to use for access to the raw device for operations like image copies and addition/removal from raid arrays. The underlying problem can't be solved at the filesystem layer.
Try cat /etc/mtab. The device being used for the particular label is clearly shown after its mounted, even when auto mounted by label in /etc/fstab. I fail to see what is so hidden here. When the device is connected to the machine its also identified in log messages as to which device node it is assigned.
Am I not making it clear that I want to be able to add and move disks that may or may not have a linux filesystem on them? You know, things that a unix-like operating system is supposed to let you do in some deterministic manner. I want the disks to work in dual-boot scenarios with earlier/later versions of linux. I want to be able to duplicate disks by copying the raw device or even raid-mirroring then failing and removing the device.
No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices.
I haven't found that to be the case. And I don't see any reason for today's experimental change to end up being the one that sticks.
Anaconda should have handled changing your configuration change in /etc/fstab for you at install if all your partitions were labeled.
When does anaconda run? I want to be able to install an OS, then add disks or move them. Right now a machine by my desktop has 2 scsi and 8 sata drives in hot-swap bays plus an assortment of pluggable firewire and USB external drives, and only the scsi pair were installed when anaconda ran. I'd much, much prefer that the raw devices for the swappable bays always had fixed device names for the drive inserted by position regardless of insertion order but I realize that's not likely to happen, so I'll settle for a reasonable description of how to figure out the right name for a newly inserted drive with the understanding that it may not have a filesystem lable and I may not want to mount it. At the moment, the most likely thing I'd want to do is add a partition from a newly inserted disk to an existing md array, but at some point in the setup (and not while anaconda is running...) it is necessary to partition and build the arrays out of a bunch of disks that mostly look the same. Is fedora suitable for jobs like this?
If they aren't all labeled this doesn't happen, which is a short-coming of anaconda in that it will not apply labels to FAT32 or NTFS disks that do not have them (and maybe other filesystems). There are also bugs against anaconda about this and I think a number of them are closed rawhide so it should be better now.
Anaconda isn't the solution unless I can run it anytime new unpartitioned devices are added or if I want something on the device other than a typical file system.
Les Mikesell wrote:
Andrew Farris wrote:
Anaconda should have handled changing your configuration change in /etc/fstab for you at install if all your partitions were labeled.
When does anaconda run? I want to be able to install an OS, then add disks or move them. Right now a machine by my desktop has 2 scsi and 8 sata drives in hot-swap bays plus an assortment of pluggable firewire and USB external drives, and only the scsi pair were installed when anaconda ran. I'd much, much prefer that the raw devices for the swappable bays always had fixed device names for the drive inserted by position regardless of insertion order but I realize that's not likely to happen, so I'll settle for a reasonable description of how to figure out the right name for a newly inserted drive with the understanding that it may not have a filesystem lable and I may not want to mount it. At the moment, the most likely thing I'd want to do is add a partition from a newly inserted disk to an existing md array, but at some point in the setup (and not while anaconda is running...) it is necessary to partition and build the arrays out of a bunch of disks that mostly look the same. Is fedora suitable for jobs like this?
Well in that particular situation where you know when the disk is inserted and you can do them one at a time it should be easily determined which device nodes are assigned just by 'tail -F /var/log/messages' prior to the disk insertion. I'd agree thats not exactly as elegant as the assumption that the device will consistently be assigned a certain device node but it works. When the disk is inserted the kernel messages very clearly identify it if a usable disk is found whether it is partitioned or not.
You can also just look into /dev/disk/by-id for links that give you the device if you know which id is which (and if only one of the disks inserted doesn't have partitions you know which it is immediately). /dev/disk/by-path even tells you the controller you're connected to for each device node (with the caviat that it calls them all scsi, but primary controller to secondary controller should still make sense). That gives you all you should need to handle those disk management jobs...
If thats still just not how you want it to be, thats understandable I suppose.
Andrew Farris wrote:
Anaconda should have handled changing your configuration change in /etc/fstab for you at install if all your partitions were labeled.
When does anaconda run? I want to be able to install an OS, then add disks or move them. Right now a machine by my desktop has 2 scsi and 8 sata drives in hot-swap bays plus an assortment of pluggable firewire and USB external drives, and only the scsi pair were installed when anaconda ran. I'd much, much prefer that the raw devices for the swappable bays always had fixed device names for the drive inserted by position regardless of insertion order but I realize that's not likely to happen, so I'll settle for a reasonable description of how to figure out the right name for a newly inserted drive with the understanding that it may not have a filesystem lable and I may not want to mount it. At the moment, the most likely thing I'd want to do is add a partition from a newly inserted disk to an existing md array, but at some point in the setup (and not while anaconda is running...) it is necessary to partition and build the arrays out of a bunch of disks that mostly look the same. Is fedora suitable for jobs like this?
Well in that particular situation where you know when the disk is inserted and you can do them one at a time it should be easily determined which device nodes are assigned just by 'tail -F /var/log/messages' prior to the disk insertion. I'd agree thats not exactly as elegant as the assumption that the device will consistently be assigned a certain device node but it works. When the disk is inserted the kernel messages very clearly identify it if a usable disk is found whether it is partitioned or not.
You can also just look into /dev/disk/by-id for links that give you the device if you know which id is which (and if only one of the disks inserted doesn't have partitions you know which it is immediately). /dev/disk/by-path even tells you the controller you're connected to for each device node (with the caviat that it calls them all scsi, but primary controller to secondary controller should still make sense). That gives you all you should need to handle those disk management jobs...
If thats still just not how you want it to be, thats understandable I suppose.
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which. But I'm not interested in turning this into a helpdesk session about special case procedures. The same scenario happens even more often when I build a disk and ship it to a remote location where someone else (who doesn't know anything about linux...) swaps it into a server with multiple NICs - and now we have to associate the right NIC configuration with the right cable connection. In the old days if it was eth0 yesterday it would still be eth0 today, but that doesn't happen anymore. The servers typically have 4 nics with 2 in use and it can be painful figuring how to assign the addresses and routes so the network connections work on a new box or a replacement OS.
So, the generic question is, now that the system uses essentially random names for devices, is there a way, or a plan for a way, to deal with situations where many choices of new devices appear as a result of hardware changes, disk moves, backup/restores on new hardware, etc. and if so, will it require a GUI to deal with it? So far I've only heard the notion that these things should "just work" and I want to make sure that everybody knows it can't "just work" because the system can't possibly know want I want to do with a newly attached device or a whole bunch of them and I normally don't want anything to happen automatically other than being able to know the device name to access them. Someone mentioned a scenario with usb->serial converters which would be a similar case - no matter how much you want to guess and do something friendly, you aren't going to know what's on the serial side of that thing or what to do with it.
On Jan 11, 2008 2:30 PM, Les Mikesell lesmikesell@gmail.com wrote:
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which.
Frankly i like this idea, but I'm unsure of the practicality of it:
What is the highest level which is even aware of the physical location of said device? I would imagine the BIOS knows, and maybe some really low level kernel modules but anything above that?
Arthur Pemberton wrote:
On Jan 11, 2008 2:30 PM, Les Mikesell lesmikesell@gmail.com wrote:
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which.
Frankly i like this idea, but I'm unsure of the practicality of it:
What is the highest level which is even aware of the physical location of said device? I would imagine the BIOS knows, and maybe some really low level kernel modules but anything above that?
udev is fully aware of the physical location, because it knows the communication bus addressing to the device itself (/dev/disk/by-path). What Les is asking for is a consistent guaranteed device node naming scheme, which makes good sense for machines with few devices (desktops, small servers) and less sense for larger systems. The facts are the older scheme wasn't guaranteed to be deterministic, it just seemed to be because the kernel would probe / name the devices in sequential order, and its no longer guaranteed to do that (that still doesn't mean anything is named randomly).
I suppose someone could have additional udev rules that would follow the older naming scheme at the same time as the new one... just doing the 'magic guesswork' to make sure things always got named in the predictable ordering.
Arthur Pemberton wrote:
On Jan 11, 2008 2:30 PM, Les Mikesell lesmikesell@gmail.com wrote:
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which.
Frankly i like this idea, but I'm unsure of the practicality of it:
What is the highest level which is even aware of the physical location of said device? I would imagine the BIOS knows, and maybe some really low level kernel modules but anything above that?
The bios doesn't necessarily know anything except for the one(s) that it might boot. But I think there may be some extra magic in what the kernel does with the names depending on which drive bios used to boot. The stuff in /dev/disk/by-path might be useful for the versions that have it, but I can't see anything for the empty controller positions where the drives aren't connected so the arrangement doesn't make a lot of sense.
On Jan 11, 2008 3:44 PM, Les Mikesell lesmikesell@gmail.com wrote:
Arthur Pemberton wrote:
On Jan 11, 2008 2:30 PM, Les Mikesell lesmikesell@gmail.com wrote:
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which.
Frankly i like this idea, but I'm unsure of the practicality of it:
What is the highest level which is even aware of the physical location of said device? I would imagine the BIOS knows, and maybe some really low level kernel modules but anything above that?
The bios doesn't necessarily know anything except for the one(s) that it might boot. But I think there may be some extra magic in what the kernel does with the names depending on which drive bios used to boot. The stuff in /dev/disk/by-path might be useful for the versions that have it, but I can't see anything for the empty controller positions where the drives aren't connected so the arrangement doesn't make a lot of sense.
Then it seems to me that what you/i/we want can be accomplished with soem clever udev rules.
Arthur Pemberton wrote:
On Jan 11, 2008 2:30 PM, Les Mikesell lesmikesell@gmail.com wrote:
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which.
Frankly i like this idea, but I'm unsure of the practicality of it:
What is the highest level which is even aware of the physical location of said device? I would imagine the BIOS knows, and maybe some really low level kernel modules but anything above that?
The bios doesn't necessarily know anything except for the one(s) that it might boot. But I think there may be some extra magic in what the kernel does with the names depending on which drive bios used to boot. The stuff in /dev/disk/by-path might be useful for the versions that have it, but I can't see anything for the empty controller positions where the drives aren't connected so the arrangement doesn't make a lot of sense.
Then it seems to me that what you/i/we want can be accomplished with soem clever udev rules.
Yes, maybe, someday... I'm just not getting a warm and fuzzy feeling that there will be a reasonable mechanism for people to interact with this process to get deterministic behavior for the simplest thing, accessing a device by a name related to the hardware in some way. Shouldn't that come before magically attempting some high-level thing with hot-plugged unknowns or browsing that only makes sense in a GUI?
Les Mikesell lesmikesell@gmail.com wrote:
[...]
It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which. But I'm not interested in turning this into a helpdesk session about special case procedures. The same scenario happens even more often when I build a disk and ship it to a remote location where someone else (who doesn't know anything about linux...) swaps it into a server with multiple NICs - and now we have to associate the right NIC configuration with the right cable connection. In the old days if it was eth0 yesterday it would still be eth0 today, but that doesn't happen anymore. The servers typically have 4 nics with 2 in use and it can be painful figuring how to assign the addresses and routes so the network connections work on a new box or a replacement OS.
Get them by MAC, not as ethX. I.e., here I have in /etc/sysconfig/network-scripts/ifcfg-eth0:
# Intel Corporation 82573L Gigabit Ethernet Controller DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp HWADDR=00:a0:d1:78:d7:c5
and the correct name is given to that eth.
So, the generic question is, now that the system uses essentially random names for devices, is there a way, or a plan for a way, to deal with situations where many choices of new devices appear as a result of hardware changes, disk moves, backup/restores on new hardware,
... random hot(un)plugging, ...
etc. and if so, will it require a GUI to deal with it? So far I've only heard the notion that these things should "just work" and I want to make sure that everybody knows it can't "just work" because the system can't possibly know want I want to do with a newly attached device
The systen /can/ tell e.g. this is still the FooLaser printer serial XYZ-ABCDE, even though it is connected through a different USB port today. AFAICS, as things stand, the system is /not/ doing anything funky, it just gives a way of finding out what is where (and the device has a clear ID); and uses this if the device had been configured before. Things do get tricky if you want to dd(1) disk images around, or are fond of serial devices connected through USB-serial dongles, etc. But then you want the system to do non-obvious stuff...
Horst H. von Brand wrote:
In the old days if it was eth0 yesterday it would still be eth0 today, but that doesn't happen anymore. The servers typically have 4 nics with 2 in use and it can be painful figuring how to assign the addresses and routes so the network connections work on a new box or a replacement OS.
Get them by MAC, not as ethX. I.e., here I have in /etc/sysconfig/network-scripts/ifcfg-eth0:
# Intel Corporation 82573L Gigabit Ethernet Controller DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp HWADDR=00:a0:d1:78:d7:c5
and the correct name is given to that eth.
Thanks - that works in the replacement case if I have the foresight to snarf the current MAC addresses before the disk dies. (Is this documented somewhere and is it going to stay this way?) But an equally common case is that new machines are being rolled out and the hardware tech plugging the drive in doesn't know much about linux or what the MAC address is for the machine - and I can't connect to help until he gets at least one of them right.
So, the generic question is, now that the system uses essentially random names for devices, is there a way, or a plan for a way, to deal with situations where many choices of new devices appear as a result of hardware changes, disk moves, backup/restores on new hardware,
... random hot(un)plugging, ...
Of devices that I don't necessarily want mounted.
etc. and if so, will it require a GUI to deal with it? So far I've only heard the notion that these things should "just work" and I want to make sure that everybody knows it can't "just work" because the system can't possibly know want I want to do with a newly attached device
The systen /can/ tell e.g. this is still the FooLaser printer serial XYZ-ABCDE, even though it is connected through a different USB port today. AFAICS, as things stand, the system is /not/ doing anything funky, it just gives a way of finding out what is where (and the device has a clear ID); and uses this if the device had been configured before. Things do get tricky if you want to dd(1) disk images around, or are fond of serial devices connected through USB-serial dongles, etc. But then you want the system to do non-obvious stuff...
I'd say most of what I do is non-obvious, which is why I've always liked unix systems that don't make wrong guesses and do what someone else thought should be the obvious thing. There's a place for the black magic stuff, of course, but how do you turn it off - for example when you are building/copying drive images that will run elsewhere or you just want raw device access for other reasons? And how do you identify the device from a set of choices?
On Thu, Jan 10, 2008 at 11:00:24AM -0600, Les Mikesell wrote:
But the old names were predictable; the new ones aren't - when I move a disk to a new controller/drive position, I know about it.
They were not. If you added a controller they may change.
Old unix naming is based on a fixed structure, modern system naming is based on the reality of hotplug
David Zeuthen wrote:
On Thu, 2008-01-10 at 09:31 -0600, Les Mikesell wrote:
Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily - or turns what used to be detected as eth0 into eth2 when a different kernel is booted? Admittedly it has been a while since I've used Solaris, but I can't recall anything like that ever happening with it. In a unix-like system where access to everything is through its device/file name, what is more fundamental than that?
This is a flawed example. The problem is that you're relying on names assigned in an irregular fashion and it will happen on Solaris as well if you move disks between controllers etc. The way to do this in the modern world is to rely on persistent names. See /dev/disk/* and the udev rules for stable network interface names. Of course you can argue that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're going to find much sympathy for such a point of view.
And the interesting thing is it looks like /dev/sdX will 'stay stable' as the way its done after that change. Change happens. :)
On Thu, 2008-01-10 at 14:17 -0800, Andrew Farris wrote:
And the interesting thing is it looks like /dev/sdX will 'stay stable' as the way its done after that change. Change happens. :)
I wouldn't put my money on it.. maybe it's stable (for some definition of the word) now, probably not in a few years.
(Interestingly enough, one price Fedora pays for this so-called stability is that booting is somewhat slower, e.g. crap like scsi_wait_scan.ko)
David
David Zeuthen wrote:
On Thu, 2008-01-10 at 14:17 -0800, Andrew Farris wrote:
And the interesting thing is it looks like /dev/sdX will 'stay stable' as the way its done after that change. Change happens. :)
I wouldn't put my money on it.. maybe it's stable (for some definition of the word) now, probably not in a few years.
(Interestingly enough, one price Fedora pays for this so-called stability is that booting is somewhat slower, e.g. crap like scsi_wait_scan.ko)
The sdX names never were related to hardware in the same sense as the hdX ones were so 'stay stable' is an odd term. If you know the controller and drive select you knew the hdX name. The sdX names have always been whimsically assigned depending on what else happens to be present. There's nothing you can see to relate the name to a physical device.
On 09.01.2008 21:58, Adam Jackson wrote:
Linux is about choice.
[...] The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once.
I agree with most of the things you said. In a ideal world there would be no reason for some of the choices like juju or not. Juju afaics solves a lot of problems and I agree that it's the way forward.
But we don't live in a ideal world and when we started shipping juju it was not capable to do some things that were possible with the old stack. Some things more then a handful of users wanted to do, so lot of users ran into trouble and had a hard a fight fixing it -- seems some people (including Hans afaics, who's a developer with a lot of skills) got confused/frustrated. That's bad for Fedoras reputing -- thus we should avoid that if we want to be a serious distribution and more than a beta-playground for RHEL (as that's how it feels from my point of view due to things like this).
So that leaves two choices:
- we could have delayed juju until F8 (or even F9) - we could have included juju in F7 (as we did) and made it optional (either enabled or disabled by default)
I think the latter is the better solution and a serious option for one release.
CU knurd
On Wed, 09 Jan 2008 22:18:25 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
- we could have delayed juju until F8 (or even F9)
- we could have included juju in F7 (as we did) and made it optional
(either enabled or disabled by default)
I think the latter is the better solution and a serious option for one release.
And if we had chosen that, it likely still wouldn't be where it is today, because it wouldn't have had the exposure. It was functional for the vast majority of uses and the exposure got more and more things fixed on it. If there was an alternative then everybody would just switch back to the old method, and no bugs would get filed and no corner cases would get discovered.
On Jan 9, 2008 12:27 PM, Jesse Keating jkeating@redhat.com wrote:
And if we had chosen that, it likely still wouldn't be where it is today, because it wouldn't have had the exposure. It was functional for the vast majority of uses and the exposure got more and more things fixed on it. If there was an alternative then everybody would just switch back to the old method, and no bugs would get filed and no corner cases would get discovered.
We need to build an accurate perception as to what we are offering in our releases. When we have the manpower to support it we drive technologies forward aggressively. We need to build the perception that our releases aren't just consumables, but they instead collaborative partnerships will our users to meet the goals of driving long term value into the open source software stack. We need to build the perception that when you choose to use fedora, you are choosing to be a part of the collaboration, and not just taking a product off the shelf giving it a spin.
In areas where we have Fedora contributors who are active upstream developers, we tend to make integration decisions in release N which have the best potential for long term benefit for release N+1, N+2 and out into the future (especially in the area of hardware interaction). We know our process is not regression intolerant. But our process accommodates that fact by having an aggressive update process so people suffering hardware regressions can obtain fixes in a responsive manner. This isn't a policy, or a set of rules, this is how our development culture operates in broad brush strokes. It would be deeply disruptive to the project to attempt to suppress this essential nature.
So how do we fix the perception that this is a bad thing? How do we attract users and contributors who are comfortable with some level of regression, for the sake of long term benefit?
Naively, I would suggest continuing to enhance our Feature-scoping so that it includes known or suspected regression areas. And we need to be able to have our developers who are aggressively driving new technologies into our releases, make public commitments that they will work to address regressions as part of the update process. We can't make guarantees, but we can certainly project a perception that our developers care about hardware regressions and are willing to work with people to fix them.
-jef
2008/1/9, Jesse Keating jkeating@redhat.com:
On Wed, 09 Jan 2008 22:18:25 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
And if we had chosen that, it likely still wouldn't be where it is today, because it wouldn't have had the exposure. It was functional for the vast majority of uses and the exposure got more and more things fixed on it. If there was an alternative then everybody would just switch back to the old method, and no bugs would get filed and no corner cases would get discovered.
Then we might have a fallback method for people that want to test firewire. Because if it does not work for some userland apps, then people will just escape.(to RHEL based or others). If we really want to have valuable testers for firewire, I think they have to be taken with care.
For now i'm building a own kmod-ieee1394 but it is not interesting to have it build that way... instead of within the kernel. then providing a compat-libraw1394 (without juju support) with the appropriate blacklisting for kernel modules, and that's would be all... See experiments here: http://kwizart.free.fr/fedora/testing/8/SRPMS/
I do think the firewire problem is different from others.
Nicolas (kwizart)
-- Jesse Keating Fedora -- All my bits are free, are yours?
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Thorsten Leemhuis (fedora@leemhuis.info) said:
So that leaves two choices:
- we could have delayed juju until F8 (or even F9)
- we could have included juju in F7 (as we did) and made it optional
(either enabled or disabled by default)
I think the latter is the better solution and a serious option for one release.
That way lies madness.
Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we ship two Intel drivers and two kernels until this is resolved?
During the Fedora 8 devel cycle, NetworkManager didn't support WPA for a time. Should we have shipped two versions of NetworkManager and let users choose between them?
If it doesn't work, it's a bug. Fix the bug. Not ship a version for each set of bugs that exists.
Bill
On 09.01.2008 22:37, Bill Nottingham wrote:
Thorsten Leemhuis (fedora@leemhuis.info) said:
So that leaves two choices:
- we could have delayed juju until F8 (or even F9)
- we could have included juju in F7 (as we did) and made it optional
(either enabled or disabled by default)
I think the latter is the better solution and a serious option for one release.
That way lies madness.
I suppose the users that ran into trouble would say the same about what we did.
So both way lie madness here. Then I'm all for giving the users the choice so they can work around something without to much trouble if they run into problems with something new.
Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we ship two Intel drivers and two kernels until this is resolved? [...]
Bugs in a updated package are something totally different (everyone tries to avoid them, but they happen, so we have to live with them) then switching to a new completely firewire stack that doesn't support everything yet what the old stack did.
Jesse said juju "was functional for the vast majority of uses" when we shipped that; I doubt that, as the questions is saw in #fedora-de, the "howto switch to the old firewire stack"-Howtos in the net and the mail from Hans tell a different story.
Cu knurd
Thorsten Leemhuis (fedora@leemhuis.info) said:
Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we ship two Intel drivers and two kernels until this is resolved? [...]
Bugs in a updated package are something totally different (everyone tries to avoid them, but they happen, so we have to live with them) then switching to a new completely firewire stack that doesn't support everything yet what the old stack did.
By this logic, we should have enabled both old IDE and libata and let the users choose between them at runtime as well.
The way to have a reliable core system is to pick a single supported interface and fix it. As far as I can tell, the firewire stack now works, except for an issue with one hardware chipset. While that is not good for users who have that chipset, it's certainly about par for the course with many other drivers we have, and I don't see why that should mean that the whole thing should be switched out.
Bill
On 10.01.2008 05:59, Bill Nottingham wrote:
Thorsten Leemhuis (fedora@leemhuis.info) said:
Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we ship two Intel drivers and two kernels until this is resolved? [...]
Bugs in a updated package are something totally different (everyone tries to avoid them, but they happen, so we have to live with them) then switching to a new completely firewire stack that doesn't support everything yet what the old stack did.
By this logic, we should have enabled both old IDE and libata and let the users choose between them at runtime as well.
Not sure about this one -- Alan afaics did a lot of work to make sure everything crucial worked with the new libata PATA driver on those systems I used. Sure, there were bugs, but there are bug in every software and Alan tried its best to fix them quickly.
But yeah, maybe enabling both old IDE and libata (with defaulting to libata) for one release might have made sense. At least it made for OpenSuse, as that's what they did afaik. Sure, it's more work for one release, but if that is needed to support all systems that were supported earlier then it might be worth the trouble.
The way to have a reliable core system is to pick a single supported interface and fix it.
Totally agreed in general. But sometimes it's not easily possible when switching from foo to bar (be it the old firewire stack and juju or IDE and libata).
As far as I can tell, the firewire stack now works, except for an issue with one hardware chipset.
Now: seems so afaics. But when it was new it was a regression for quite a bunch of people. That's bad and we should avoid regressions as much as possible. Just like the kernel developers do -- Torvalds on lkml yells loudly if there is a regression. He sometimes even reverts patches that made the situation better for a lot of people if it is a regression for a quite small group of existing users. I think we need similar rules, as people will otherwise turn away from Fedora to something that just works for them; otherwise everyone will continue to say "Fedora is a Beta for RHEL" is we don#t take our userbase serious.
CU knurd
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
Now: seems so afaics. But when it was new it was a regression for quite a bunch of people. That's bad and we should avoid regressions as much as possible. Just like the kernel developers do -- Torvalds on lkml yells
While I agree regressions are annoying, and thus perceived as a very bad thing, in practice regressions are less of a problem than unfixed bugs: if there's a regression, you can rollback to a working package, if there are unfixed bugs, you have nothing to upgrade or downgrade to.
Kevin Kofler
On Thu, Jan 10, 2008 at 12:15:37PM +0000, Kevin Kofler wrote:
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
Now: seems so afaics. But when it was new it was a regression for quite a bunch of people. That's bad and we should avoid regressions as much as possible. Just like the kernel developers do -- Torvalds on lkml yells
While I agree regressions are annoying, and thus perceived as a very bad thing, in practice regressions are less of a problem than unfixed bugs: if there's a regression, you can rollback to a working package, if there are unfixed bugs, you have nothing to upgrade or downgrade to.
Kevin Kofler
I don't think so. If there's unfixed bug it means that things don't work, didn't work and won't work for some time. But regression means that thing worked but don't work now. At least for me bugs doesn't matter me. Regression yes. I remember Linus speach that if We fix all regressions and some bugs programs become better. If We neglect regressions it's impossible complain if software is better or worse, people will be annoyed. You were accustomed and you have to switch your habbits - it's pretty harder that you want start using something new and you can't so you will find other solution which works for you. We really should be focused primarily on regressions, not for "common" bugs.
Adam
On 01/09/2008 10:53 PM, Thorsten Leemhuis wrote:
Jesse said juju "was functional for the vast majority of uses" when we shipped that; I doubt that, as the questions is saw in #fedora-de, the "howto switch to the old firewire stack"-Howtos in the net and the mail from Hans tell a different story.
Because people only complain when things don't work. Without data on which devices work with the juju stack that didn't work with the old stack, you can't say this accurately.
Best mail on this list I've ever read.
David
On Wed, 09.01.08 16:28, David Zeuthen (david@fubar.dk) wrote:
Best mail on this list I've ever read.
Me too, but I guess I might be a bit biased on this one. ;-)
Lennart
Adam Jackson wrote:
But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
+1
FWIW, I tend to believe a good distribution is about limiting choice, not proliferating it. Limited choice enhances robustness by reducing the combinatorics of testing. Throwing the entire kitchen sink into the distribution is anarchy with the expected results.
FWIW I liked the idea of Core vs. Extras because if it was in Core it was expected to work, if it was in Extras it was buyer beware.
A good distribution works. Choice is provided by optional add-ons with no guarantees. After an optional package is shown to be robust and well supported it can be promoted from it's optional status, just as a core package can be demoted to optional if it fails to meet the requirements of robustness, security, and support required of the distribution.
John Dennis wrote:
Adam Jackson wrote:
But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
+1
FWIW, I tend to believe a good distribution is about limiting choice, not proliferating it. Limited choice enhances robustness by reducing the combinatorics of testing. Throwing the entire kitchen sink into the distribution is anarchy with the expected results.
FWIW I liked the idea of Core vs. Extras because if it was in Core it was expected to work, if it was in Extras it was buyer beware.
A good distribution works. Choice is provided by optional add-ons with no guarantees.
+42
This is where I think the intensity of this thread is somewhat confusing. I wholeheartedly agree that what you ship in one particular spin/strain of fedora should most often minimize choices for the user (unless the target users of the spin/strain explicitly want the choices).
That is what is great about distro spin tools such as livecd-tools/revisor/VirOS- they make it easy for anyone who doesn't like the official fedora imposed choice, to as easily as possible, put together a 'fork' distro utilizing the alternate choice.
The thing I wish would be come through clearer in this thread is that choices are fine for the massive Fedora Everything collection. Sure having more choices will lead to more bugs, but so what as long as the choices made for the official spin are well tested.
$0.02
-dmc
After an optional package is shown to be robust and well
supported it can be promoted from it's optional status, just as a core package can be demoted to optional if it fails to meet the requirements of robustness, security, and support required of the distribution.
On 09.01.2008 23:00, Douglas McClendon wrote:
John Dennis wrote:
A good distribution works.
+1
But Juju afaics didn't work well for to many people when we shipped it for the first time, thus choice here IMHO is a temporary solution.
This is where I think the intensity of this thread is somewhat confusing. I wholeheartedly agree that what you ship in one particular spin/strain of fedora should most often minimize choices for the user (unless the target users of the spin/strain explicitly want the choices).
+1
That is what is great about distro spin tools such as livecd-tools/revisor/VirOS- they make it easy for anyone who doesn't like the official fedora imposed choice, to as easily as possible, put together a 'fork' distro utilizing the alternate choice.
You might want to look at a idea that came up on the list now and then by different people that Jesse added to the wiki: http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
I like the idea, but the amount of work that might create is likely a lot.
[...]
Cu knurd
On Wed, 09 Jan 2008 23:12:57 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
+1
But Juju afaics didn't work well for to many people when we shipped it for the first time, thus choice here IMHO is a temporary solution.
Some people. Lets not confuse a few vocal folks for whom a part of it didn't work with the large amount of folks who just plain didn't notice that juju was there vs something else because things just kept working (or got better). I mistakenly claimed that it worked for most people, when in reality I have no way of proving that. Instead, most /functionality/ was working, and I extrapolated that into most people.
On 01/09/2008 11:12 PM, Thorsten Leemhuis wrote:
But Juju afaics didn't work well for to many people when we shipped it for the first time, thus choice here IMHO is a temporary solution.
Yes, it didn't work well for some people. It did work well for others, in some cases where the old stack didn't work at all for them. Too bad we have no way of counting them. Those who scream the loudest are not always in the majority.
On Wed, 2008-01-09 at 16:51 -0500, John Dennis wrote:
FWIW I liked the idea of Core vs. Extras because if it was in Core it was expected to work, if it was in Extras it was buyer beware.
The Core/Extras split still exists in the sense of "some packages are more important than others"- it's just now defined as the set of packages included in the Live image kickstart files and comps.
On Wed, 2008-01-09 at 17:17 -0500, Colin Walters wrote:
On Wed, 2008-01-09 at 16:51 -0500, John Dennis wrote:
FWIW I liked the idea of Core vs. Extras because if it was in Core it was expected to work, if it was in Extras it was buyer beware.
The Core/Extras split still exists in the sense of "some packages are more important than others"- it's just now defined as the set of packages included in the Live image kickstart files and comps.
Live and/or the Default Install set. We should probably have a better way of listing of what that set of packages actually is so we can make sure they get extra attention during updates and whatnot.
-w
On Wed, Jan 09, 2008 at 03:58:45PM -0500, Adam Jackson wrote:
Linux is about choice.
The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once. If you try to deliver both at once you have to also deliver a way of switching between the two. Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions). We have essentially already posited that we have insufficient developer effort to have 100%-complete features at ship time, so asking them to take on six times the failure rate when they're already overburdened is just madness. Alternatively, we could say that
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
worse than the old stack. But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
This is right. But care should be taken not to shift from constraining the user to constraining the developper. We should ship everything that a contributor has interest in maintaining. It should not be at the expense of innovating, so breaking some packages some time because they are not ready for changes in other packages is acceptable (in rawhide). In the design of new feature, however existing stuff should be taken into account such that, if possible, previous habits are still possible and there are no regression. Developpers of new features should look at it, even to discard it, in fedora I see too much 'this is old cruft no need to look at it is broken by design' even when it is untrue.
-- Pat
On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote:
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
One issue is that most packagers maintainers in the Fedora Project are not code monkeys. Another issue is that complexity has this funny habit of growing exponentially with the number of moving parts...
David
On Wed, Jan 09, 2008 at 05:54:51PM -0500, David Zeuthen wrote:
On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote:
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
One issue is that most packagers maintainers in the Fedora Project are not code monkeys.
Do you have other words that would say the same, but understandable by a non native speaker...
Another issue is that complexity has this funny habit of growing exponentially with the number of moving parts...
That's possible, and I am not advocating to let everything go in any direction, be it only because some of the burden fails on other packagers (misfiled bugs, complex issues that seems to arise from a package but in fact comes from another temporarily broken) but a middle ground is needed in which developpers, especially from the community can also do what they want in fedora to pursue their own (innovative or simply usefull).
-- Pat
Patrice Dumas wrote:
On Wed, Jan 09, 2008 at 05:54:51PM -0500, David Zeuthen wrote:
One issue is that most packagers maintainers in the Fedora Project are not code monkeys.
Do you have other words that would say the same, but understandable by a non native speaker...
Explanation here: http://en.wikipedia.org/wiki/Code_monkey (often means 'person who only programs' opposed to engineer/designer, but I really think he meant 'programmer' versus 'packager' in a nicer way, in that most packagers can't always fix all the code bugs)
On Thu, 10 Jan 2008 00:06:42 +0100 Patrice Dumas pertusus@free.fr wrote:
One issue is that most packagers maintainers in the Fedora Project are not code monkeys.
Do you have other words that would say the same, but understandable by a non native speaker..
He's saying that most our package maintainers are not actual code developers, but instead folks that know and understand how to package software. A valuable skill set, but not the skill set needed for developing software itself. See other threads recently on this topic.
On Jan 9, 2008 6:06 PM, Patrice Dumas pertusus@free.fr wrote:
Do you have other words that would say the same, but understandable by a non native speaker...
Sure - what's being said is that some or most Fedora package maintainers are not programmers or coders, but rather packager.
Adding my own $0.02 here, I'm not sure that this is a problem. Coders code - they are often not good packagers/release engineering folk. However the packagers need the coding community behind them.
On Thu, 2008-01-10 at 00:06 +0100, Patrice Dumas wrote:
On Wed, Jan 09, 2008 at 05:54:51PM -0500, David Zeuthen wrote:
On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote:
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
One issue is that most packagers maintainers in the Fedora Project are not code monkeys.
Do you have other words that would say the same, but understandable by a non native speaker...
I just meant that most (certainly not all) Fedora package maintainers don't know how to write/debug code, create patches that will be accepted upstream, understand complex interactions involving multiple packages and processes (sometimes even user/kernel boundaries) and so on - you know, what programmers do.
While this is probably fine for the majority of our packages (I mean, it's perfectly fine to package software even if you can't program), it's probably going to be a problem in situations like the proposed ones.
David
On Wed, Jan 09, 2008 at 06:24:08PM -0500, David Zeuthen wrote:
I just meant that most (certainly not all) Fedora package maintainers don't know how to write/debug code, create patches that will be accepted upstream, understand complex interactions involving multiple packages and processes (sometimes even user/kernel boundaries) and so on - you know, what programmers do.
While this is probably fine for the majority of our packages (I mean, it's perfectly fine to package software even if you can't program), it's probably going to be a problem in situations like the proposed ones.
That's sure people should not do things they cannot manage, but I can't see how it is related with the issues above. And notice that it is Hans who started the thread...
-- Pat
On Thu, 2008-01-10 at 00:30 +0100, Patrice Dumas wrote:
On Wed, Jan 09, 2008 at 06:24:08PM -0500, David Zeuthen wrote:
I just meant that most (certainly not all) Fedora package maintainers don't know how to write/debug code, create patches that will be accepted upstream, understand complex interactions involving multiple packages and processes (sometimes even user/kernel boundaries) and so on - you know, what programmers do.
While this is probably fine for the majority of our packages (I mean, it's perfectly fine to package software even if you can't program), it's probably going to be a problem in situations like the proposed ones.
That's sure people should not do things they cannot manage, but I can't see how it is related with the issues above.
You claimed that there was dozens and dozens of people ready to help with such tasks. I submit that is not true. I wish it was.
David
On Wed, Jan 09, 2008 at 06:33:45PM -0500, David Zeuthen wrote:
You claimed that there was dozens and dozens of people ready to help with such tasks. I submit that is not true. I wish it was.
I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that when there are such people those who do the mainstream stuff it should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment.
-- Pat
On Thu, Jan 10, 2008 at 12:48:17AM +0100, Patrice Dumas wrote:
On Wed, Jan 09, 2008 at 06:33:45PM -0500, David Zeuthen wrote:
You claimed that there was dozens and dozens of people ready to help with such tasks. I submit that is not true. I wish it was.
I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that when there are such people those who do the mainstream stuff it should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment.
It should have been:
I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that, when there are such people, those who do the mainstream stuff should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment.
-- Pat
On Thu, 2008-01-10 at 00:57 +0100, Patrice Dumas wrote:
I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that, when there are such people, those who do the mainstream stuff should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment.
Sure, and if I had a pony I'm sure my life would be honky-dory. You're also deliberately ignoring that the issue of qualified man-power is only _one_ aspect of this discussion.
David
On Wed, 2008-01-09 at 18:59 -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 00:57 +0100, Patrice Dumas wrote:
I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that, when there are such people, those who do the mainstream stuff should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment.
Sure, and if I had a pony I'm sure my life would be honky-dory. You're also deliberately ignoring that the issue of qualified man-power is only _one_ aspect of this discussion.
Uh, I meant. Something about that there are more aspects to this discussion that just man power. Such as even if we had people willing to e.g. maintain two firewire stacks we probably wouldn't want to do that because of the added complexity. Hope this clarifies.
David
On Wed, Jan 09, 2008 at 07:02:11PM -0500, David Zeuthen wrote:
Uh, I meant. Something about that there are more aspects to this discussion that just man power. Such as even if we had people willing to e.g. maintain two firewire stacks we probably wouldn't want to do that because of the added complexity. Hope this clarifies.
Hope it is untrue. I mean, maybe we wouldn't want to do that because of the added complexity, but this should be discussed and not just dismissed.
-- Pat
On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote:
On Wed, Jan 09, 2008 at 03:58:45PM -0500, Adam Jackson wrote:
The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once. If you try to deliver both at once you have to also deliver a way of switching between the two. Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions). We have essentially already posited that we have insufficient developer effort to have 100%-complete features at ship time, so asking them to take on six times the failure rate when they're already overburdened is just madness. Alternatively, we could say that
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task?
Partly that's just how software _works_. You don't ever ship anything 100% perfect because it's not an achievable goal. But, partly because it's just observed reality of how the project is staffed. For many of the features that people consider vitally important we have at best a small team of contributors.
Isn't the fedora contributors time used like they want to?
Oh man. If only.
If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
If the moon were made of cheese, would you eat it?
We don't _have_ dozens of contributors willing to fix them. I can count the number of unsolicited X patches I've received from random Fedora people on one hand. Statistically speaking, zero bug reports come with patches attached. Again, this is just a reality of software. Most users are not developers. There is no reason to ever expect this to change.
Go read No Silver Bullet again. Software is hard. Complexity is the essence of the problem. Complexity is a handshake problem, n(n-1)/2. You can not just throw manpower at the problem, because the communication problem between the developers is also a handshake problem. The only solution is radical simplicity.
I would love it if for every compromise problem like firewire we had a team of people ready to step up and own the transition and all the consequent complexity.
We don't. We never will.
- ajax
On Wed, Jan 09, 2008 at 07:19:48PM -0500, Adam Jackson wrote:
Partly that's just how software _works_. You don't ever ship anything 100% perfect because it's not an achievable goal. But, partly because it's just observed reality of how the project is staffed. For many of the features that people consider vitally important we have at best a small team of contributors.
In that case let them do what they think best.
Isn't the fedora contributors time used like they want to?
Oh man. If only.
Not in that sense, of course. What I am saying is that if somebody wants to work on something even if it is not where the main strand of fedora, even if it leads to having parallel stuff he should not be deterred.
If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
We don't _have_ dozens of contributors willing to fix them. I can count the number of unsolicited X patches I've received from random Fedora people on one hand. Statistically speaking, zero bug reports come with patches attached. Again, this is just a reality of software. Most users are not developers. There is no reason to ever expect this to change.
I can't see the connection with patches.
Go read No Silver Bullet again. Software is hard. Complexity is the essence of the problem. Complexity is a handshake problem, n(n-1)/2.
That's just untrue. Not everything interacts in complex ways with everything. Also adding some complexity may some time reduce development costs when some comparisons become possible when similar software coexist.
You can not just throw manpower at the problem, because the communication problem between the developers is also a handshake problem. The only solution is radical simplicity.
It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible.
-- Pat
On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote:
It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible.
Oh nice. Now you're playing the "RH vs. community" card. Priceless. News flash: this is _not_ about RH vs. the community. It's about realizing that software development is _hard_. It's about realizing that throwing options and toggles at the problem very very rarely gives you something good. What it does give you is a lot of confused users (look around; we're getting better but it's still really bad) including e.g. UI crap for selecting the driver stack of the week or whatever.
This essay is more than five years old
http://ometer.com/free-software-ui.html
I suggest you read it. It's not completely related to this topic but if you think about it long enough there's some glaring analogies to be made.
David
On Wed, Jan 09, 2008 at 07:38:42PM -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote:
It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible.
Oh nice. Now you're playing the "RH vs. community" card. Priceless. News flash: this is _not_ about RH vs. the community. It's about realizing that software development is _hard_. It's about realizing that throwing
It is not exactly "RH vs. community". I just want to make sure that things like xdm, initng, fluxbox, compat packages, xpdf or a non linux kernel (all are things that are duplicates of other packages) are still welcomed in fedora. After all it is not necessarily an issue if not, but this should be stated explicitely.
My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case?
In fact there are already guidelines and FESCo rulings that in my opinion went in that direction (precisely, and if I recall well, the fnord and another package of Enrico that were linked statically against uclibc, and even he demonstrated that there was a performance gain and no security issue they were knocked down). I think that it was a wrong decision, but if it is for corner case it is different than if it becomes the rule.
-- Pat
On Thu, 2008-01-10 at 01:57 +0100, Patrice Dumas wrote:
My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case?
Sure, live free or die etc. But you cannot expect maintainers of core packages to simply bend over just because you think it's l33t to e.g. have a non Linux kernel. Moreover, I'm pretty sure, by just reading your mails, that you don't realize what using a non Linux kernel even entails.
In fact there are already guidelines and FESCo rulings that in my opinion went in that direction (precisely, and if I recall well, the fnord and another package of Enrico that were linked statically against uclibc, and even he demonstrated that there was a performance gain and no security issue they were knocked down). I think that it was a wrong decision, but if it is for corner case it is different than if it becomes the rule.
Ooo.. here's the "it's in the guidelines so do as I say" card. Annoying.
Seriously. People. What the hell happened to simplicity and building a free OS for the world that just works? Is the state of Fedora really in such a bad shape that people think it's necessary have craptastic options like "what kernel would you like today?". Seriously, things like that is just masturbation and we in Fedora should be above that. I feel that people wanting this are treating Fedora like it's a playground for their Toy OS ideas. Playing classic cards like "RH vs. community" and "this or that committee says so" to justify their "ideas". It's seriously tiring. Is this what Fedora is becoming? Because if it is, I'll find something else to spend my time on.
David
On 10/01/2008, David Zeuthen david@fubar.dk wrote:
On Thu, 2008-01-10 at 01:57 +0100, Patrice Dumas wrote:
My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case?
Sure, live free or die etc. But you cannot expect maintainers of core packages to simply bend over just because you think it's l33t to e.g. have a non Linux kernel. Moreover, I'm pretty sure, by just reading your mails, that you don't realize what using a non Linux kernel even entails.
In fact there are already guidelines and FESCo rulings that in my opinion went in that direction (precisely, and if I recall well, the fnord and another package of Enrico that were linked statically against uclibc, and even he demonstrated that there was a performance gain and no security issue they were knocked down). I think that it was a wrong decision, but if it is for corner case it is different than if it becomes the rule.
Ooo.. here's the "it's in the guidelines so do as I say" card. Annoying.
Seriously. People. What the hell happened to simplicity and building a free OS for the world that just works? Is the state of Fedora really in such a bad shape that people think it's necessary have craptastic options like "what kernel would you like today?". Seriously, things like that is just masturbation and we in Fedora should be above that. I feel that people wanting this are treating Fedora like it's a playground for their Toy OS ideas. Playing classic cards like "RH vs. community" and "this or that committee says so" to justify their "ideas". It's seriously tiring. Is this what Fedora is becoming? Because if it is, I'll find something else to spend my time on.
Not sure how arguing over kernel builds is akin to wanking but really this is a "My $DEVICE wont work under Linux" thread that should have started as a bz entry and has gotten out of hand so don't get too disheartened.
On Thu, 2008-01-10 at 01:34 +0000, Christopher Brown wrote:
Not sure how arguing over kernel builds is akin to wanking but really this is a "My $DEVICE wont work under Linux" thread that should have started as a bz entry and has gotten out of hand so don't get too disheartened.
Maybe it wasn't clear but with "what kernel would you like today" I meant things like "do you want a FreeBSD or Linux" kernel. The very idea of supporting that kind of thing in Fedora is, at least from my neck of the woods, pure crack.
David
On Wed, Jan 09, 2008 at 08:14:02PM -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 01:57 +0100, Patrice Dumas wrote:
My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case?
Sure, live free or die etc. But you cannot expect maintainers of core packages to simply bend over just because you think it's l33t to e.g.
What do you mean exactly by 'bend over'? I don't expect maintainers of any package (what is a core package?) to do anything, but I don't expect them to block or cause problem to somebody wanting to add a new kernel to fedora (as long as that new kernel addition is done in a sound technical way).
have a non Linux kernel. Moreover, I'm pretty sure, by just reading your mails, that you don't realize what using a non Linux kernel even entails.
Indeed. This was an extreme example to avoid getting in the technical argument, but keep talking on the organisational issues.
In fact there are already guidelines and FESCo rulings that in my opinion went in that direction (precisely, and if I recall well, the fnord and another package of Enrico that were linked statically against uclibc, and even he demonstrated that there was a performance gain and no security issue they were knocked down). I think that it was a wrong decision, but if it is for corner case it is different than if it becomes the rule.
Ooo.. here's the "it's in the guidelines so do as I say" card. Annoying.
Hum, maybe I wasn't clear, but I actually meant that FESCo should have left Enrico link statically his packages. So I said the reverse...
Seriously. People. What the hell happened to simplicity and building a free OS for the world that just works? Is the state of Fedora really in such a bad shape that people think it's necessary have craptastic options like "what kernel would you like today?". Seriously, things like that is just masturbation and we in Fedora should be above that.
It is not masturbation, it is about what is acceptable or not in fedora, from the point of view of a contributor. It is absolutely not related with the shape of fedora.
I feel that people wanting this are treating Fedora like it's a playground for their Toy OS ideas.
You shouldn't make such assumptions. There are many reasons to have diversity and freedom to add anything. I could tell mine, but I don't think it is relevant. Point is do we allow any package to go in, be it for fedora contributors to use fedora as 'a playground for their Toy OS ideas' or for any other reason.
Playing classic cards like "RH vs. community" and "this or that committee says so" to justify their "ideas". It's seriously tiring. Is this what Fedora is becoming? Because if it is, I'll find something else to spend my time on.
Forget the "RH vs. community" stuff, rereading my mail I indeed said that but it was a mistake, and it isn't the issue here. It is mainstream fedora (a simple fedora that just works) versus freedom to add anything that is free software and works (even if not very well integrated).
-- Pat
On Thu, 2008-01-10 at 10:17 +0100, Patrice Dumas wrote:
have a non Linux kernel. Moreover, I'm pretty sure, by just reading your mails, that you don't realize what using a non Linux kernel even entails.
Indeed. This was an extreme example to avoid getting in the technical argument,
Interesting. So this is a concrete example of how your whole line of reasoning is filled with hyperbole. It seems you are using this hyperbole, along with mistaken notions of "freedom" and "diversity", as a platform for trying to argue that we should be more open to "choice".
but keep talking on the organisational issues.
So please take this *elsewhere*. I think we should stick to technical subjects on this list instead of coming up with wacky examples that is beyond ones comprehension. All you have down here, Patrice, is to screw up the SN ratio of this list even more.
(Seriously, I don't even know why I'm on this list anymore. Maybe we need a fedora-codemonkeys-list where we can ban people using hyperbole instead of sticking to technical facts and reality. Perhaps, someone could get even some work done on such a list.)
David
On Thu, Jan 10, 2008 at 10:29:50AM -0500, David Zeuthen wrote:
Indeed. This was an extreme example to avoid getting in the technical argument,
Interesting. So this is a concrete example of how your whole line of reasoning is filled with hyperbole.
It is not an hyperbole (I guess that you mean exageration by this word), it is an example. I used that example because it allows to discuss about choices. Choices that are done in the fedora community, that have technical consequences.
It seems you are using this hyperbole, along with mistaken notions of "freedom" and "diversity", as a platform for trying to argue that we should be more open to "choice".
I personnally favour the openness to choice, but I am clearly not the only one to do such an important choice for fedora. It should be clear, however for fedora contributors what is acceptable.
but keep talking on the organisational issues.
So please take this *elsewhere*. I think we should stick to technical subjects on this list instead of coming up with wacky examples that is beyond ones comprehension.
This is very important, in my opinion, to speak about organizational subjects and not only strictly technical subjects. I think that what kind of packages are accepted in fedora is an important question for the fedora community.
All you have down here, Patrice, is to screw up the SN ratio of this list even more.
That's possible, but not on purpose.
(Seriously, I don't even know why I'm on this list anymore. Maybe we need a fedora-codemonkeys-list where we can ban people using hyperbole instead of sticking to technical facts and reality. Perhaps, someone could get even some work done on such a list.)
If this list is not for discussing which packages should be acceptable in fedora which list should be used for that? In my opinion this is the list where the community members like me and you can voice their concerns.
-- Pat
On Thu, 2008-01-10 at 16:47 +0100, Patrice Dumas wrote:
If this list is not for discussing which packages should be acceptable in fedora which list should be used for that? In my opinion this is the list where the community members like me and you can voice their concerns.
No, that's fedora-list or fedora-advisory-board or whatever list of the week that non-technical discussions happens on. This list is for technical discussions - please do avoid participating unless you know what you are talking about.
David
On 01/10/2008 02:14 AM, David Zeuthen wrote:
Seriously. People. What the hell happened to simplicity and building a free OS for the world that just works? Is the state of Fedora really in such a bad shape that people think it's necessary have craptastic options like "what kernel would you like today?". Seriously, things like that is just masturbation and we in Fedora should be above that. I feel that people wanting this are treating Fedora like it's a playground for their Toy OS ideas. Playing classic cards like "RH vs. community" and "this or that committee says so" to justify their "ideas". It's seriously tiring. Is this what Fedora is becoming? Because if it is, I'll find something else to spend my time on.
The Praeto principle is relevant here. The more software we have, the less time contributors have to spend time on fixing bugs in a random project (let's say the Firewire stack as a random example) if they wanted to because they have to worry about fixing bugs in the packages they maintain.
On Thu, Jan 10, 2008 at 02:45:14PM +0100, Christopher Aillon wrote:
The Praeto principle is relevant here. The more software we have, the less time contributors have to spend time on fixing bugs in a random project (let's say the Firewire stack as a random example) if they wanted to because they have to worry about fixing bugs in the packages they maintain.
It is not right if more softwares come with more contributors. Or if the contributors have do it anyway, but cannot easily share what they did.
-- Pat
On 01/10/2008 03:50 PM, Patrice Dumas wrote:
It is not right if more softwares come with more contributors. Or if the contributors have do it anyway, but cannot easily share what they did.
Sure it does. We're getting contributors to completely new things, not the things we're shipping and definitely not the things people are complaining about being broken. It's great that people are interested in Fedora, and great that they want to see their package in Fedora. But it doesn't help fix your firewire bugs.
One of the reasons projects like Mozilla, GNOME, KDE, etc. are successful is they have clearly defined goals, and people are working with more or less a stable amount of code. Things get re-written all the time, but the old thing gets thrown out in favor of the hot new thing. Any new contributor is _generally_ going to work on fixing existent code, not introducing new code, which is completely opposite from Fedora where the new contributor is adding code, not helping fix the existing code.
Just some random musings...
On Thu, Jan 10, 2008 at 04:22:41PM +0100, Christopher Aillon wrote:
On 01/10/2008 03:50 PM, Patrice Dumas wrote:
It is not right if more softwares come with more contributors. Or if the contributors have do it anyway, but cannot easily share what they did.
Sure it does. We're getting contributors to completely new things, not the things we're shipping and definitely not the things people are complaining about being broken. It's great that people are interested in Fedora, and
Why not? One could imagine that somebody steps up to package the stuff needed by the old firewire stack? I don't know that issue very well, but I can imagine people wanting to fix things in fedora if they are annoying them.
-- Pat
On 01/10/2008 04:31 PM, Patrice Dumas wrote:
On Thu, Jan 10, 2008 at 04:22:41PM +0100, Christopher Aillon wrote:
On 01/10/2008 03:50 PM, Patrice Dumas wrote:
It is not right if more softwares come with more contributors. Or if the contributors have do it anyway, but cannot easily share what they did.
Sure it does. We're getting contributors to completely new things, not the things we're shipping and definitely not the things people are complaining about being broken. It's great that people are interested in Fedora, and
Why not? One could imagine that somebody steps up to package the stuff needed by the old firewire stack? I don't know that issue very well, but I can imagine people wanting to fix things in fedora if they are annoying them.
Because that's not fixing them, as has been echoed many times. That's only reintroducing different code. Which works for some people and breaks for others. Fixing it would mean making it work for everyone. Or do we not care about that?
On Thu, 10 Jan 2008 16:31:56 +0100 Patrice Dumas pertusus@free.fr wrote:
Why not? One could imagine that somebody steps up to package the stuff needed by the old firewire stack? I don't know that issue very well, but I can imagine people wanting to fix things in fedora if they are annoying them.
Also, there is a /huge/ difference between "I can package this!" and "I can be responsible for all the bug reports regarding this, and help to transition folks using this to that, and help improve that along the way."
Jesse Keating wrote:
On Thu, 10 Jan 2008 16:31:56 +0100 Patrice Dumas pertusus@free.fr wrote:
Why not? One could imagine that somebody steps up to package the stuff needed by the old firewire stack? I don't know that issue very well, but I can imagine people wanting to fix things in fedora if they are annoying them.
Also, there is a /huge/ difference between "I can package this!" and "I can be responsible for all the bug reports regarding this, and help to transition folks using this to that, and help improve that along the way."
This is the philosophical issue - but it applies whether you support backwards compatiblity or not. In the now diverged firewire juju thread there is a comment:
"Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now..."
Of course "stuff happens" and things aren't ever going to be perfect, but why does a fundamental change go in at the device driver level without providing a way to revert to the previous version unless there is at least some expectation of having the resources to fix the new problems that will almost certainly show up?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Les Mikesell wrote:
Jesse Keating wrote:
On Thu, 10 Jan 2008 16:31:56 +0100 Patrice Dumas pertusus@free.fr wrote:
Why not? One could imagine that somebody steps up to package the stuff needed by the old firewire stack? I don't know that issue very well, but I can imagine people wanting to fix things in fedora if they are annoying them.
Also, there is a /huge/ difference between "I can package this!" and "I can be responsible for all the bug reports regarding this, and help to transition folks using this to that, and help improve that along the way."
This is the philosophical issue - but it applies whether you support backwards compatiblity or not. In the now diverged firewire juju thread there is a comment:
"Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now..."
Of course "stuff happens" and things aren't ever going to be perfect, but why does a fundamental change go in at the device driver level without providing a way to revert to the previous version unless there is at least some expectation of having the resources to fix the new problems that will almost certainly show up?
Priorities change, unexpected problems crop up, things take much longer than anyone anticipated, etc.
Also, note that a lot of the remaining current issues *might* be resolved by some forthcoming juju firewire patches from the linux1394 git tree, which I'm going to try to get into rawhide this afternoon... David Moore did a lot of excellent work over the holiday break while I was busy not paying much attention... :)
- -- Jarod Wilson jwilson@redhat.com
On 10/01/2008, Patrice Dumas pertusus@free.fr wrote:
On Wed, Jan 09, 2008 at 07:38:42PM -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote:
It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible.
Oh nice. Now you're playing the "RH vs. community" card. Priceless. News flash: this is _not_ about RH vs. the community. It's about realizing that software development is _hard_. It's about realizing that throwing
It is not exactly "RH vs. community". I just want to make sure that things like xdm, initng, fluxbox, compat packages, xpdf or a non linux kernel (all are things that are duplicates of other packages) are still welcomed in fedora. After all it is not necessarily an issue if not, but this should be stated explicitely.
My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case?
Of course but at some point, particularly with something such as separate subsystem stacks in the kernel, someone has to make a technical choice. In this instance JuJu was enabled in 7+ with the intention to work with the maintainers to resolve issues as they arose. Firewire in Linux is a mess but it is improving, thanks largely to the JuJu team and if I may say, the inclusion of said stack in Fedora. One of the maintainers is extremely active on the Fedora bugzilla.
So when those qualified to do so make that choice, they are merely set as defaults. If you want the old firewire stack there are third party repos rolling kernels with it included. If you want xpdf over evince then you can have that as well. Some software such as fluxbox caters for smaller markets so it won't ever be default but as long as it works for what it does it will be there.
That is what a distribution is essentially - a set of software packages deemed to be the best in class. It won't suit everyone but it should suit most. 80/20 rule and all that.
Cheers
Christopher Brown wrote:
On 10/01/2008, Patrice Dumas pertusus@free.fr wrote:
On Wed, Jan 09, 2008 at 07:38:42PM -0500, David Zeuthen wrote:
On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote:
It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible.
Oh nice. Now you're playing the "RH vs. community" card. Priceless. News flash: this is _not_ about RH vs. the community. It's about realizing that software development is _hard_. It's about realizing that throwing
It is not exactly "RH vs. community". I just want to make sure that things like xdm, initng, fluxbox, compat packages, xpdf or a non linux kernel (all are things that are duplicates of other packages) are still welcomed in fedora. After all it is not necessarily an issue if not, but this should be stated explicitely.
My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case?
Of course but at some point, particularly with something such as separate subsystem stacks in the kernel, someone has to make a technical choice. In this instance JuJu was enabled in 7+ with the intention to work with the maintainers to resolve issues as they arose. Firewire in Linux is a mess but it is improving, thanks largely to the JuJu team and if I may say, the inclusion of said stack in Fedora. One of the maintainers is extremely active on the Fedora bugzilla.
I think here (Christopher says it well) is the most salient point on 'is it welcome or not'... the problem that started the thread (JuJu new vs old stack) was simply the primary maintainer choosing to go with new, and if anyone (other than that maintainer who chose not to) had provided the appropriate compatibility/switching/coexistence patches to have both available I am pretty certain that it could have and would have been done. I mean look at the history and how long the simple mta switcher app survives because someone provided it when other options than sendmail were available.
So Patrice I think the answer is and always will be 'its welcome' but the issue is who will do it. When that choice (or any other hard choice of innovation vs current working compatibility) is made it is up to those who need current compatibility to help keep it available. As others have said in the thread to plan on the primary maintainers handling it in a 'keep everything forever' fashion is guaranteed to be madness and a big failure.
On 01/09/2008 11:47 PM, Patrice Dumas wrote:
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
Not trying to slam people, but don't confuse willing with able (for various reasons such as ability, time constraints, lack of specific hardware, etc.)
On Thu, Jan 10, 2008 at 02:02:32PM +0100, Christopher Aillon wrote:
On 01/09/2008 11:47 PM, Patrice Dumas wrote:
Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue?
Not trying to slam people, but don't confuse willing with able (for various reasons such as ability, time constraints, lack of specific hardware, etc.)
This is true for any fedora related activity. And when I say willing, it means more than willing, but also a plan, and even better patches/packages already prepared...
-- Pat
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
See below. But actually I think we here and there are not even cutting edge enough; we for example left users on Firefox2 for FC6 for about 7 months until we shipped F7 -- that looked totally odd for a distribution that is curring edge in most other areas.
I didn't quite understand the rationale there either. At least Remi Collet made a great job making Firefox 2 available for FC6 in his repo.
Another example: hplip is still on 2.7.7 for F8 right now while upstream is at 2.7.12 in between and supports 22 new printers ( http://hplip.sourceforge.net/release_notes.html ). We don't provide any solutions for users that buy those printers right now besides using rawhide. Thus they have to wait/ask for a proper update or wait until F9 or -- the latter means waiting about 6 months for driver. That's IMHO unacceptable -- especially as printer manufacturers release successor models quite often (it feels to me like a new successor model get released in each printer class about once a year, but I didn't check).
With HP printers, usually the successor model works just fine if you pass it off as its predecessor.
Kevin Kofler
On 10.01.2008 02:51, Kevin Kofler wrote:
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
Another example: hplip is still on 2.7.7 for F8 right now while upstream is at 2.7.12 in between and supports 22 new printers ( http://hplip.sourceforge.net/release_notes.html ). We don't provide any solutions for users that buy those printers right now besides using rawhide. Thus they have to wait/ask for a proper update or wait until F9 or -- the latter means waiting about 6 months for driver. That's IMHO unacceptable -- especially as printer manufacturers release successor models quite often (it feels to me like a new successor model get released in each printer class about once a year, but I didn't check).
With HP printers, usually the successor model works just fine if you pass it off as its predecessor.
We might know that. But most random users might not. An it's just "usually" and not "always".
CU knurd
On Jan 9, 2008 1:45 PM, Hans de Goede j.w.r.degoede@hhs.nl wrote:
Does this mean that Fedora should not have shipped the new stack? No it doesn't! Getting code out there early into many hands for testing is a good thing.
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
Supporting two versions of anything, especially on the same system is much harder than it looks. The people in charge have to make sure that the old version still works, even if it's unmaintained upstream, the new version works somewhat, so it doesn't completely suck, the userspace stack surrounding kernel bits has to work equally as well, so that the transition is smooth, the interoperability between the new/old components and the rest of the system is equal, etc...
Then they have to worry about security advisories on both components, managing two packages where there could be one, propagating static materials twice, like documentation and configuration details, writing documentation on how to switch back and forth for those butterflies that are interested in making things work well, etc...
All in all, it takes alot more manpower than what's available right now.
-Yaakov
Yaakov Nemoy wrote:
On Jan 9, 2008 1:45 PM, Hans de Goede j.w.r.degoede@hhs.nl wrote:
Does this mean that Fedora should not have shipped the new stack? No it doesn't! Getting code out there early into many hands for testing is a good thing.
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
Supporting two versions of anything, especially on the same system is much harder than it looks. The people in charge have to make sure that the old version still works, even if it's unmaintained upstream, the new version works somewhat, so it doesn't completely suck, the userspace stack surrounding kernel bits has to work equally as well, so that the transition is smooth, the interoperability between the new/old components and the rest of the system is equal, etc...
Then they have to worry about security advisories on both components, managing two packages where there could be one, propagating static materials twice, like documentation and configuration details, writing documentation on how to switch back and forth for those butterflies that are interested in making things work well, etc...
All in all, it takes alot more manpower than what's available right now.
You are talkin in generivs, where as this are 2 very specific cases, in both cases I gave the alternative is still actively maintained upstream. In the case of firewire, the alternative is even the preferred choice of upstream, in the case of pulseaudio, pa lies on top of alsa, the alternative, so surely we must still maintain that! I'll admit that in the firewire case there would be some extra work, but not a lot.
Regards,
Hans
On Wed, 2008-01-09 at 19:45 +0100, Hans de Goede wrote:
Hi All,
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge. I tried to get an industrial firewire camera to work with the stock Fedora kernel using the juju stack. Long story short, it didn't work.
Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really surprising, quoting that page: "Almost no support for IIDC cameras: Not compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. Improvements are to be expected in Linux 2.6.25-rc1."
Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras). Add to that that the above referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers."
libdc1394 isn't part of Fedora, so that's outside the scope of this discussion.
As for the necessary Juju bits, they're already in Fedora 7 and Fedora 8. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=344851
That fix is included in kernel 2.6.23.9-44.fc7, 2.6.23.9-78.fc8, and rawhide. It'll hit the *upstream* kernel in 2.6.25.
We were able to write that fix *because* the Juju stack was available in Fedora.
-w
Will Woods wrote:
On Wed, 2008-01-09 at 19:45 +0100, Hans de Goede wrote:
Hi All,
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge. I tried to get an industrial firewire camera to work with the stock Fedora kernel using the juju stack. Long story short, it didn't work.
Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really surprising, quoting that page: "Almost no support for IIDC cameras: Not compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. Improvements are to be expected in Linux 2.6.25-rc1."
Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras). Add to that that the above referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers."
libdc1394 isn't part of Fedora, so that's outside the scope of this discussion.
Well actually it has been in review for quite a while, with the juju stack being one of the reasons for it not passing review yet (patents is another, but a patent free version is most likely possible).
I would like to work on getting this into Fedora, and if things could be fixed so as to work with the new stack, I'm all for it. Shipping something which still doesn't work in F-9 makes us look rather bad IMHO, doing new things can cause breakage, but breakage for 3 releases in a row?
As for the necessary Juju bits, they're already in Fedora 7 and Fedora 8. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=344851
That fix is included in kernel 2.6.23.9-44.fc7, 2.6.23.9-78.fc8, and rawhide. It'll hit the *upstream* kernel in 2.6.25.
As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet.
Note that I'm more then willing to help debug this, I've added myself to the CC of: https://bugzilla.redhat.com/show_bug.cgi?id=415841
Anything I van do to help?
Regards,
Hans
Hans de Goede j.w.r.degoede@hhs.nl writes:
As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet.
It should do OHCI 1.1, you may want to take the risk and try the program. Make sure you have a backup (the GUID and possibly whole EEPROM data).
VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just have no VT6306 to test (actually it seems VT6307 is a cheeper version, aimed at motherboard manufacturers).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Krzysztof Halasa wrote:
Hans de Goede j.w.r.degoede@hhs.nl writes:
As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet.
It should do OHCI 1.1, you may want to take the risk and try the program. Make sure you have a backup (the GUID and possibly whole EEPROM data).
VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just have no VT6306 to test (actually it seems VT6307 is a cheeper version, aimed at motherboard manufacturers).
Honestly, I'd rather we just figured out what's wrong with the Via chipsets in OHCI 1.0 mode, rather than relying on people flashing their controllers to 1.1 mode. I've got a few ideas, hoping to get back to juju hacking shortly...
- -- Jarod Wilson jwilson@redhat.com
Jarod Wilson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Krzysztof Halasa wrote:
Hans de Goede j.w.r.degoede@hhs.nl writes:
As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet.
It should do OHCI 1.1, you may want to take the risk and try the program. Make sure you have a backup (the GUID and possibly whole EEPROM data).
VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just have no VT6306 to test (actually it seems VT6307 is a cheeper version, aimed at motherboard manufacturers).
Honestly, I'd rather we just figured out what's wrong with the Via chipsets in OHCI 1.0 mode, rather than relying on people flashing their controllers to 1.1 mode. I've got a few ideas, hoping to get back to juju hacking shortly...
I didn't flash my controller, I wanted too, but it turned out it already was put in 1.1 by the manufacturer of the card I'm using.
I'm willing to flash to 1.0 mode to help test IIDC in 1.0 mode though, but first let get IIDC working with the card in 1.1 mode :)
Regards,
Hans
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans de Goede wrote:
Jarod Wilson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Krzysztof Halasa wrote:
Hans de Goede j.w.r.degoede@hhs.nl writes:
As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet.
It should do OHCI 1.1, you may want to take the risk and try the program. Make sure you have a backup (the GUID and possibly whole EEPROM data).
VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just have no VT6306 to test (actually it seems VT6307 is a cheeper version, aimed at motherboard manufacturers).
Honestly, I'd rather we just figured out what's wrong with the Via chipsets in OHCI 1.0 mode, rather than relying on people flashing their controllers to 1.1 mode. I've got a few ideas, hoping to get back to juju hacking shortly...
I didn't flash my controller, I wanted too, but it turned out it already was put in 1.1 by the manufacturer of the card I'm using.
I'm willing to flash to 1.0 mode to help test IIDC in 1.0 mode though, but first let get IIDC working with the card in 1.1 mode :)
I hope to have a rawhide kernel built soonish with some additional bits from the linux1394 git tree that may solve your iidc problems (and if I'm lucky, a few other items on my todo list).
- -- Jarod Wilson jwilson@redhat.com
Jarod Wilson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans de Goede wrote:
Jarod Wilson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Krzysztof Halasa wrote:
Hans de Goede j.w.r.degoede@hhs.nl writes:
As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet.
It should do OHCI 1.1, you may want to take the risk and try the program. Make sure you have a backup (the GUID and possibly whole EEPROM data).
VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just have no VT6306 to test (actually it seems VT6307 is a cheeper version, aimed at motherboard manufacturers).
Honestly, I'd rather we just figured out what's wrong with the Via chipsets in OHCI 1.0 mode, rather than relying on people flashing their controllers to 1.1 mode. I've got a few ideas, hoping to get back to juju hacking shortly...
I didn't flash my controller, I wanted too, but it turned out it already was put in 1.1 by the manufacturer of the card I'm using.
I'm willing to flash to 1.0 mode to help test IIDC in 1.0 mode though, but first let get IIDC working with the card in 1.1 mode :)
I hope to have a rawhide kernel built soonish with some additional bits from the linux1394 git tree that may solve your iidc problems (and if I'm lucky, a few other items on my todo list).
Sounds good, let me know when koji has something to test for me.
Regards,
Hans
On Wed, Jan 09, 2008 at 07:45:18PM +0100, Hans de Goede wrote:
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge.
This question is worth asking, but I have no good answer.
FWIW, I get criticized for pushing too much brand-new wireless bits into the Fedora kernels. Simultaneously (often the very same days) I get criticized for taking more than a day or two to get new upstream wireless patches merged into the Fedora kernels. There is no winning...
Just my $0.02...
John
On Thu, 10 Jan 2008, Linus Walleij wrote:
On Wed, 9 Jan 2008, John W. Linville wrote:
FWIW, I get criticized for pushing too much brand-new wireless bits into the Fedora kernels.
I, for one, THANK YOU for doing it John, it saved my day and I'm not going to forget that. So keep doing what you're doing.
+10. I thought about replying last night, but I didn't think it'd improve the S:N ratio. :-) I've always found John's work to be beneficial to the distro, including when he breaks support for my hardware. (Hey, he usually tries to fix it pretty quick, too!)
Sometimes you've gotta break some yolks to make scrambled eggs. Does it suck? Sure. Is it for the best in the long run? I think so.
On Wed, 9 Jan 2008, Chuck Anderson wrote:
On Thu, Jan 10, 2008 at 01:57:23AM +0000, Kevin Kofler wrote:
despite Fedora not including proprietary junk like madwifi (what's the state of ath5k by the way?)
ath5k Works for me(TM), NM 0.7 EAP-TLS, with a few issues after suspend/resume.
Oooh, I'll have to try that again. Where'd that Atheros MiniPCI card go...and the PCI one.
Jima
John W. Linville <linville <at> redhat.com> writes:
FWIW, I get criticized for pushing too much brand-new wireless bits into the Fedora kernels. Simultaneously (often the very same days) I get criticized for taking more than a day or two to get new upstream wireless patches merged into the Fedora kernels. There is no winning...
I think you're doing the right thing, these backports are the reason wireless works for much more people on Fedora than on the average other distro. And that despite Fedora not including proprietary junk like madwifi (what's the state of ath5k by the way?) or ndiswrapper (yuck!).
Kevin Kofler
On Wed, 9 Jan 2008, Hans de Goede wrote:
Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras).
That seems like a bold, and IMO, unsubstantiated claim. I managed to get a Firewire camera to work using the new stack a couple weeks ago. I had a bit of trouble, which lead me to discussions that came to the same general conclusion that you outlined in your email, but then I tried chown'ing the /dev/fw-* (or whatever) devices to my user, and things miraculously worked. This was on kernel-2.6.23.1-49.fc8; I hadn't gotten around to rebooting that box in a while (nor have I tried the camera since rebooting to 2.6.23.9-85.fc8). I won't deny, however, getting burned a time or three by Fedora's early-adopter practices. :-)
Jima
Hi All,
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
+1 Likewize.. :>
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge.
I on the other hand think we should be more Cutting edge.. Follow upstream all the way to test3. Release gold with upstream at test3!
Some might say it's to little time for proper testing.. Others might say true but then again our target audience is ?, Certainly not regular Joe because then we would be where Ubuntu is now..
Then it's the issue to get everything to latest upstream and get the ball rolling from there..
Does this mean that Fedora should not have shipped the new stack? No it doesn't! Getting code out there early into many hands for testing is a good thing.
+1
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
I'ts all about giving user a choose ;).. + if things aren't working properly they could fallback on something that does..
Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL: https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&comp...
Again I think its good to be shipping this, and even that its good having it on by default, but we should also provide a small gui utility for easily turning ir off.
I have had no problem with Pulseaudio, rather apps that dont support Pulseaudio or have it enabled by default, but since the choice is out there I just use the ones that do..
Regards,
Hans
Best regards. Johann B.
On Wed, 09.01.08 19:45, Hans de Goede (j.w.r.degoede@hhs.nl) wrote:
Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL:
https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&comp...
I don't think this BZ excerpt is any good as argument for your point. A big share of the bugs listed for PA are duplicates. BZ is very good for burying people in vast amount of emails due to new or updated bug reports. My main job is hacking on PA, not wading through BZ. Which is why I tend to ignore bugzilla as good as I can and clean it up only just before every release.
Also, even if there were no duplicates and bogus bug reports in this list: I still find 47 bugs quite a low number, given that sound is something everyone uses all the time on the desktop these days.
Huge numbers of bugs is more a sign that people are using your software, not necessarily so much that your software is buggy.
Considering the current state of affairs with regards to both features, I would even like to advocate to make them both optional for Fedora 9.
Maybe we should remove the Linux kernel from F9, too. According to your BZ metric it is beyond evil by far. (1611)
Lennart
On Thu, 2008-01-10 at 01:49 +0100, Lennart Poettering wrote: <snip>
I don't think this BZ excerpt is any good as argument for your point. A big share of the bugs listed for PA are duplicates. BZ is very good for burying people in vast amount of emails due to new or updated bug reports. My main job is hacking on PA, not wading through BZ. Which is why I tend to ignore bugzilla as good as I can and clean it up only just before every release.
<snip>
I really appreciate what you do with pulseaudio, but I'm not quite sure what to make of this comment. What do you want us to do if we come across a pulseaudio bug?
For example, when pulseaudio is running as a system-wide daemon, any games using Alsa start to stutter after a few minutes. In single-user mode, they work perfectly. I opened a bug for this a month ago ( https://bugzilla.redhat.com/show_bug.cgi?id=417681 ), and I've not gotten any response yet. Now I realize this is probably a low-priority for you, but I guess I was hoping for at least an ACK.
Will you eventually get around to looking at it or is BZ redirected to /dev/null for you (which is how I read the above excerpt, though it may not be what you meant).
Please understand I'm not trying to jump on you, I just want to know the best way of reporting a bug to you.
Jonathan
On Thu, 10.01.08 09:59, Jonathan Dieter (jdieter@gmail.com) wrote:
On Thu, 2008-01-10 at 01:49 +0100, Lennart Poettering wrote:
<snip> > I don't think this BZ excerpt is any good as argument for your > point. A big share of the bugs listed for PA are duplicates. BZ is > very good for burying people in vast amount of emails due to new or > updated bug reports. My main job is hacking on PA, not wading through > BZ. Which is why I tend to ignore bugzilla as good as I can and clean > it up only just before every release. <snip>
I really appreciate what you do with pulseaudio, but I'm not quite sure what to make of this comment. What do you want us to do if we come across a pulseaudio bug?
Report it via BZ or PA BTS! (Exactly like you did)
I ask everyone to be patient, though. I do fix look at those bug reports and fix them, but only shortly before the next release.
The point of my mail is just that statistics about the "buggyness" of software based on bugzilla data is bogus.
For example, when pulseaudio is running as a system-wide daemon, any games using Alsa start to stutter after a few minutes. In single-user mode, they work perfectly. I opened a bug for this a month ago ( https://bugzilla.redhat.com/show_bug.cgi?id=417681 ), and I've not gotten any response yet. Now I realize this is probably a low-priority for you, but I guess I was hoping for at least an ACK.
Uh, system-wide mode is not really supported anyway. On Fedora I chose to setup PA as a session service, and that's what is supported. But that's a different story.
Will you eventually get around to looking at it or is BZ redirected to /dev/null for you (which is how I read the above excerpt, though it may not be what you meant).
I clean up BZ everytime I do a new release. "Clean up" as in "fix all relevant bugs".
Please understand I'm not trying to jump on you, I just want to know the best way of reporting a bug to you.
Use BZ or the PA BTS -- You did everything right!
Thanks,
Lennart
On Fri, 2008-01-11 at 00:04 +0100, Lennart Poettering wrote:
On Thu, 10.01.08 09:59, Jonathan Dieter (jdieter@gmail.com) wrote:
On Thu, 2008-01-10 at 01:49 +0100, Lennart Poettering wrote:
<snip> > I don't think this BZ excerpt is any good as argument for your > point. A big share of the bugs listed for PA are duplicates. BZ is > very good for burying people in vast amount of emails due to new or > updated bug reports. My main job is hacking on PA, not wading through > BZ. Which is why I tend to ignore bugzilla as good as I can and clean > it up only just before every release. <snip>
I really appreciate what you do with pulseaudio, but I'm not quite sure what to make of this comment. What do you want us to do if we come across a pulseaudio bug?
Report it via BZ or PA BTS! (Exactly like you did)
I ask everyone to be patient, though. I do fix look at those bug reports and fix them, but only shortly before the next release.
Ok, excellent. That's all I wanted to know!
The point of my mail is just that statistics about the "buggyness" of software based on bugzilla data is bogus.
Fair enough. And you did make a compelling argument.
For example, when pulseaudio is running as a system-wide daemon, any games using Alsa start to stutter after a few minutes. In single-user mode, they work perfectly. I opened a bug for this a month ago ( https://bugzilla.redhat.com/show_bug.cgi?id=417681 ), and I've not gotten any response yet. Now I realize this is probably a low-priority for you, but I guess I was hoping for at least an ACK.
Uh, system-wide mode is not really supported anyway. On Fedora I chose to setup PA as a session service, and that's what is supported. But that's a different story.
Yeah, I know it's not really supported, but for my situation (where I don't want pulseaudio being shutdown on logout and I want all users to be able to access it), it fits.
I expect that my bug will be at the bottom of the list, and that's not a problem. I'm just hoping it gets looked at sometime.
Jonathan
Lennart Poettering wrote:
On Wed, 09.01.08 19:45, Hans de Goede (j.w.r.degoede@hhs.nl) wrote:
Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL:
https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&comp...
I don't think this BZ excerpt is any good as argument for your point.
I agree with that to some part, I've recently been working on getting some pulseaudio problems in packages I maintain fixed, and when I ran that query I was a little bit amazed of the results.
Also I've been receiving quite a few bugs for some of my packages related to sound problems, and often these bugs are caused by people turning of pulseaudio (not on my advice!) but only turning it of partially, for example they often still have alsa-plugins-pulseaudio installed and enabled as default alsa sink.
So there are really problems with pulseaudio, or atleast people perceive some problems as being caused by pa, resulting in them turning pa off.
A big share of the bugs listed for PA are duplicates. BZ is very good for burying people in vast amount of emails due to new or updated bug reports. My main job is hacking on PA, not wading through BZ. Which is why I tend to ignore bugzilla as good as I can and clean it up only just before every release.
And I think this is bad, we need to nourish people who provide valuable feedback, not ignore them and let BZ tickets rot. Also see Jonathan Dieter reply for an example of why this is bad.
Why not reserve 30 minutes a day to respond to bug tickets, if you do this every day, keeping on top of things, then keeping BZ spam in track should be manageable.
Anyways after my recent bugfixing surrounding pulseaudio, I've already been thinking about trying to help out with pulseaudio, so as usual I'm willing to put my code where my mouth is and I'm hereby offering to do pulseaudio bug triaging for you. But pulseaudio is a complex beast, so I will be needing help from you. I can do the initial grunt work of filtering duplicates, filtering configuration errors and trying to make problems reproducable, but after that I will need help from you. Does this sound like a deal? And once I'm in a stadium where I need help, how do I reach you in such a way that you do respond in a reasonable time?
Thanks & Regards,
Hans
On Thu, 10.01.08 10:40, Hans de Goede (j.w.r.degoede@hhs.nl) wrote:
A big share of the bugs listed for PA are duplicates. BZ is very good for burying people in vast amount of emails due to new or updated bug reports. My main job is hacking on PA, not wading through BZ. Which is why I tend to ignore bugzilla as good as I can and clean it up only just before every release.
And I think this is bad, we need to nourish people who provide valuable feedback, not ignore them and let BZ tickets rot. Also see Jonathan Dieter reply for an example of why this is bad.
Why not reserve 30 minutes a day to respond to bug tickets, if you do this every day, keeping on top of things, then keeping BZ spam in track should be manageable.
I did that initially, and then I stopped to do it that way. It just didn't work for me. I spent way too much time on BZ that way, And spending time on BZ is not what I am being primarily payed for. (And it's also not where the fun is in my eyes...)
<offtopic>Also, since our BZ is so embarassingly slow the time spent on BZ is twenty times what it could be. Why, oh, why is our BZ just so f**g slow compared to all other BZs? Even SUSE's BZ is a million times faster than ours.</offtopic>
Anyways after my recent bugfixing surrounding pulseaudio, I've already been thinking about trying to help out with pulseaudio, so as usual I'm willing to put my code where my mouth is and I'm hereby offering to do pulseaudio bug triaging for you. But pulseaudio is a complex beast, so I will be needing help from you. I can do the initial grunt work of filtering duplicates, filtering configuration errors and trying to make problems reproducable, but after that I will need help from you. Does this sound like a deal? And once I'm in a stadium where I need help, how do I reach you in such a way that you do respond in a reasonable time?
I am happy for every help! Feel free to merge, close or comment on all BZ bug reports if it seems sensible to you. It would certainly help me to release new PA versions more quickly!
You can always, ping me on #pulseaudio on freenode. Ping me multiple times if I don't react.
Thanks,
Lennart
On Wed, 9 Jan 2008, Hans de Goede wrote:
Hi All,
One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening.
However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge. I tried to get an industrial firewire camera to work with the stock Fedora kernel using the juju stack. Long story short, it didn't work.
Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really surprising, quoting that page: "Almost no support for IIDC cameras: Not compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. Improvements are to be expected in Linux 2.6.25-rc1."
Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras).
_and_ firewire audio interfaces as well.
Which forced me and others to return to the original stack in my realtime tuned kernels for Planet CCRMA. And unpatch the corresponding libraries. And keep track of the whole mess. A royal pain you know where. Planet CCRMA is about audio. Non working interfaces that were working before is not good.
If you ask me, 18 months is way too long. It is/was a failed experiment.
Add to that that the above referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers."
Does this mean that Fedora should not have shipped the new stack? No it doesn't!
Ahem, sorry but no. It should not have in the condition it was.
Getting code out there early into many hands for testing is a good thing.
The balance between cutting edge and usability is subjective.
My opinion is that the new stack was not and still is not ready for inclusion in a mainstream distro. It just breaks too many things that people actually need to do work on the computer running that kernel.
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
Yup. Or wait till the stack actually works. But then a big chorus will probably say if we don't ship it it will not get fixed or whatever. But it has been shipped for a long time and not fixed so I _don't_ buy that argument. Most probably it just makes real users migrate somewhere else. Frankly that kind of stuff makes _me_ wonder about Planet CCRMA and where it should go. The only thing that stops me from moving somewhere else is the realization that migration would be in the short term a lot lot more work than working around the issue. Maybe it would be smarter in the long term, who knows. Sigh.
Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL: https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&comp...
Again I think its good to be shipping this, and even that its good having it on by default, but we should also provide a small gui utility for easily turning ir off.
Considering the current state of affairs with regards to both features, I would even like to advocate to make them both optional for Fedora 9.
Agreed... At least firewire has been broken for too long (IMHO)
-- Fernando
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fernando Pablo Lopez-Lezcano wrote:
On Wed, 9 Jan 2008, Hans de Goede wrote:
Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras).
No, we can add said preliminary fix to the F9 (and earlier) kernels. In fact, I'm inclined to add the OHCI 1.1 iidc fixes from David Moore to rawhide later today, as well as port them to the 1.0 code (which I'd also include).
_and_ firewire audio interfaces as well.
Which forced me and others to return to the original stack in my realtime tuned kernels for Planet CCRMA. And unpatch the corresponding libraries. And keep track of the whole mess. A royal pain you know where. Planet CCRMA is about audio. Non working interfaces that were working before is not good.
If you ask me, 18 months is way too long. It is/was a failed experiment.
Nah, its not failed, its just not complete. It works quite well where it does work -- sbp2 devices and dv capture. In the sbp2 case, it works far better than the old stack ever did. We're just a bit lacking in man power to fix up the broken things. Rather than spend time working on fixing the new stack, people run back to the old stack.
Of course, I understand some people need things to be working NOW, but there's a chicken and egg problem there. I don't do any firewire audio stuff, so offhand, I don't have a clue how to fix the particular problems you're seeing (I'm not even sure *what* the problems are). The things I do (sbp2 storage and dv capture) pretty much Just Work -- and dv capture only does so on (most) OHCI 1.0 controllers, because I sat down and wrote the OCHI 1.0 isochronous receive support code (with lots of help from krh, mind you, since I knew nothing about the code going in).
My opinion is that the new stack was not and still is not ready for inclusion in a mainstream distro. It just breaks too many things that people actually need to do work on the computer running that kernel.
Another chicken and egg problem. How do we know it doesn't work if we don't ship it?
What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching.
Yup. Or wait till the stack actually works. But then a big chorus will probably say if we don't ship it it will not get fixed or whatever.
Yeah, I'm part of the chorus.
But it has been shipped for a long time and not fixed so I _don't_ buy that argument.
Admittedly, we've been rather slow to fix things, so I do understand your not agreeing with the chorus. :)
But things *are* improving, and we *do* intend on continuing to fix things. We're just a bit short on man-power to actually sit down, reproduce problems, debug and fix them. I only recently got familiar with the kernel code myself, and my day job deals mainly with RHEL kernel stuff, but I'm quite happy to try to help out with any Fedora firewire bugs still outstanding (several are already on my plate). If you have any open bugs, or want to file any new ones, please do. Assign them to me (jwilson@redhat.com) and cc Kristian (krh@redhat.com) and Jay (fenlason@redhat.com).
Agreed... At least firewire has been broken for too long (IMHO)
Agreed.
- -- Jarod Wilson jwilson@redhat.com
Jarod Wilson wrote:
Another chicken and egg problem. How do we know it doesn't work if we don't ship it?
Ship it with a way to revert to previous behavior. If people post bugzilla items and revert, you know it didn't work and you will still have someone to test your next experiment.
Agreed... At least firewire has been broken for too long (IMHO)
I gave up on it somewhere around FC3 and switched to the CentOSplus kernel where I needed something that mostly worked. So I'm not a good tester any more.
On Thu, 10 Jan 2008, Les Mikesell wrote:
Jarod Wilson wrote:
Another chicken and egg problem. How do we know it doesn't work if we don't ship it?
Ship it with a way to revert to previous behavior. If people post bugzilla items and revert, you know it didn't work and you will still have someone to test your next experiment.
Are you realistically expecting people to not skip the "post bugzilla items" step? I like to think the best of people (okay, no I don't), but I try to keep my expectations on this planet. ;-) If we shipped that easy of a reversion (wow, that's a word!) technique, I strongly suspect we'd never hear Juju was broken.
Jima
Jima wrote:
Another chicken and egg problem. How do we know it doesn't work if we don't ship it?
Ship it with a way to revert to previous behavior. If people post bugzilla items and revert, you know it didn't work and you will still have someone to test your next experiment.
Are you realistically expecting people to not skip the "post bugzilla items" step? I like to think the best of people (okay, no I don't), but I try to keep my expectations on this planet. ;-) If we shipped that easy of a reversion (wow, that's a word!) technique, I strongly suspect we'd never hear Juju was broken.
Well you won't hear it from me anyway because I gave up on fedora/firewire back when the FC3-era bz entry sat for 6 months or so with no activity and no way to get to the data on my disks under fedora. But the solution is to put the reversion procedure in the bugzilla item in response to the first bug report and subsequently refer to it only by links. If you want bz reports you have to make them lead to quick solutions.
Les Mikesell wrote:
Jarod Wilson wrote:
Another chicken and egg problem. How do we know it doesn't work if we don't ship it?
Ship it with a way to revert to previous behavior. If people post bugzilla items and revert, you know it didn't work and you will still have someone to test your next experiment.
Like jima said... I'm guessing most people simply won't bother with the bug report. Or ever test the new stack again for the life of the release. (Note that the latest F8 kernel has dv capture support for OHCI 1.0 controllers, while the initial release kernel does not).
Agreed... At least firewire has been broken for too long (IMHO)
I gave up on it somewhere around FC3 and switched to the CentOSplus kernel where I needed something that mostly worked. So I'm not a good tester any more.
Uhm... So you gave up on juju three releases before it existed? It didn't show up until F7...
Jarod Wilson wrote:
Les Mikesell wrote:
Ship it with a way to revert to previous behavior. If people post bugzilla items and revert, you know it didn't work and you will still have someone to test your next experiment.
Like jima said... I'm guessing most people simply won't bother with the bug report. Or ever test the new stack again for the life of the release. (Note that the latest F8 kernel has dv capture support for OHCI 1.0 controllers, while the initial release kernel does not).
Agreed... At least firewire has been broken for too long (IMHO)
I gave up on it somewhere around FC3 and switched to the CentOSplus kernel where I needed something that mostly worked. So I'm not a good tester any more.
Uhm... So you gave up on juju three releases before it existed? It didn't show up until F7...
Wow. I can't count. Make that four releases.
Okay, anyhow, enough of this, as Hans said, we're working on fixing things. In the mean time, multiple 3rd-party repositories package up the old stack for those who still need it.
/me goes back to attempting to be productive...
-
"Jóhann B. Guðmundsson" -
Adam Jackson -
Adam Tkac -
Alan Cox -
Andrew Farris -
Arthur Pemberton -
Bill Nottingham -
Casey Dahlin -
Chris Adams -
Christopher Aillon -
Christopher Brown -
Chuck Anderson -
Colin Walters -
David Airlie -
David Zeuthen -
Dominik 'Rathann' Mierzejewski -
Douglas McClendon -
drago01 -
Fernando Lopez-Lezcano -
Hans de Goede -
Horst H. von Brand -
Jarod Wilson -
Jef Spaleta -
Jesse Keating -
Jima -
John Dennis -
John W. Linville -
Jon Stanley -
Jonathan Dieter -
Jos Vos -
Kevin Kofler -
Krzysztof Halasa -
Lennart Poettering -
Les Mikesell -
Linus Walleij -
Matej Cepl -
Nicolas Chauvet -
Nils Philippsen -
Olivier Galibert -
Patrice Dumas -
Rahul Sundaram -
Stephen John Smoogen -
Thorsten Leemhuis -
Will Woods -
Yaakov Nemoy