12:59 p.m.
Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
Extras 5 - what major features are you willing to put effort into?
Best,
-- Elliot
2:42 p.m.
Are people against attempting to move to some kind of enhanced init
system that includes dependencies? Or is that already the plan?
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Best,
-- Elliot
3:58 p.m.
On Wed, 2005-06-01 at 14:42 -0500, Matthew Lenz wrote:
Are people against attempting to move to some kind of enhanced init
system that includes dependencies? Or is that already the plan?
I think this is still a kindof crappy solution. Many of the cases why
"dependencies" sound nice for init, they're just a kludge.
One example would be ntpd. Currently the thought is "ntpd has to go
after networking starts", and that's what would be expressed as a
dependency.
But that sucks for a lot of reasons, especially in a scenario like the
one created by NetworkManager. What would be better is to make things
like ntpd start up, and use dbus to a) discover if there are any
networks available that are suitable for its purpose, and b) wait for
one to become available. So in this case basically NM could discover an
ntp server from the dhcp response, and then advertise it via dbus to
ntpd, which would add it in the pool as appropriate (depending on some
sort of policy or configuration).
I suspect this is the case for a lot of network services, and similar
cases exist for most of the other things you'd want to add dependencies
for. In reality, I think most stuff we run at start up is either:
a) something which really must be run relatively early and in some
particular order (no point in doing a tsort for them, the ordering is
generally pretty obvious). We don't really care about these for this
discussion.
b) stuff where we don't conceptually care the order, but which needs
some event to have occurred either before the script runs or before the
resulting daemon (or whatever) becomes useful.
In our current scenario, "some event" is something done by a different
initscript. In the dependency scenario, it's waiting on some side
affect of a script, and that satisfies the dependency. In most cases I
think it'd be better to have the other program notify things that the
real event we care about has happened, and the programs we're starting
respond accordingly. The initscript itself should be long gone (at
least conceptually) by the time that matters.
--
Peter
8:41 p.m.
Peter Jones (pjones(a)redhat.com) said:
On Wed, 2005-06-01 at 14:42 -0500, Matthew Lenz wrote:
> Are people against attempting to move to some kind of enhanced init
> system that includes dependencies? Or is that already the plan?
I think this is still a kindof crappy solution. Many of the cases why
"dependencies" sound nice for init, they're just a kludge.
One example would be ntpd. Currently the thought is "ntpd has to go
after networking starts", and that's what would be expressed as a
dependency.
But that sucks for a lot of reasons, especially in a scenario like the
one created by NetworkManager. What would be better is to make things
like ntpd start up, and use dbus to a) discover if there are any
networks available that are suitable for its purpose, and b) wait for
one to become available. So in this case basically NM could discover an
ntp server from the dhcp response, and then advertise it via dbus to
ntpd, which would add it in the pool as appropriate (depending on some
sort of policy or configuration).
Well, it's still technically a dependency. In the situation you
describe, there's really no reason for ntpd to start at all until
NM declares there's some network connection available on which to
actually sync to a server.
a) something which really must be run relatively early and in some
particular order (no point in doing a tsort for them, the ordering is
generally pretty obvious). We don't really care about these for this
discussion.
Yeah, this is rc.sysinit at the moment - parallelization & dependencies
here aren't really useful, as it follows pretty much in order:
- load hardware modules
- initialize storage
- check & mount filesystems
- misc boottime cleanups (/var, etc.)
In our current scenario, "some event" is something done by
a different
initscript. In the dependency scenario, it's waiting on some side
affect of a script, and that satisfies the dependency. In most cases I
think it'd be better to have the other program notify things that the
real event we care about has happened, and the programs we're starting
respond accordingly. The initscript itself should be long gone (at
least conceptually) by the time that matters.
The fun part will be rewriting the various apps/servers to sanely
respond to runtime reconfigration like this.
Bill
2:44 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
I'd like to see:
* faster boot and shutdown
* lower memory footprint
* avoid redundant libaries in apps
(for example most gnome apps right now have 2 XML libraries loaded and
in use)
* revamped installer/firstboot (reconsider what needs to go where, how
Xen works eg allow to make a golden image you can clone but customize on
bringing that up first time, hook it into yum to update the system
during firstboot, work with extras nicer, optimize the speed, figure how
to have system-config-packages merged in, do minimal install and let
firstboot finish it etc etc)
* next generation EXT3 features (delalloc, > 8Tb support, extends)
* reduce PLTs in core libraries further.
* library versioning in more core libraries and better symbol export
control
* FORTIFY_SOURCE in the kernel (patch available from me)
* more security features a la ExecShield
3:07 p.m.
On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote:
* avoid redundant libaries in apps
(for example most gnome apps right now have 2 XML libraries loaded and
in use)
Lots of GNOME apps/libraries (and probably many other things as well)
link to libraries that they don't actually use (try "ldd -r -
u /usr/bin/*" some time). It'd be nice to get rid of those.
Also, some libraries/apps don't actually link to libraries that they
need and work purely by luck at the moment.
i.e. appA requires libL. libL requires symbols from libM, but doesn't
link to it. appA also requires libM, so libL happens to work.
Even worse, occasionally appA doesn't actually require libM, but has to
link to it anyway to make libL work.
--
Nicholas Miell <nmiell(a)comcast.net>
3:13 p.m.
On Wed, 2005-06-01 at 13:07 -0700, Nicholas Miell wrote:
On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote:
> * avoid redundant libaries in apps
> (for example most gnome apps right now have 2 XML libraries loaded and
> in use)
Lots of GNOME apps/libraries (and probably many other things as well)
link to libraries that they don't actually use (try "ldd -r -
u /usr/bin/*" some time). It'd be nice to get rid of those.
Also, some libraries/apps don't actually link to libraries that they
need and work purely by luck at the moment.
i.e. appA requires libL. libL requires symbols from libM, but doesn't
link to it. appA also requires libM, so libL happens to work.
Even worse, occasionally appA doesn't actually require libM, but has to
link to it anyway to make libL work.
yep this is exactly what I meant but explained far better ;)
3:26 p.m.
On Wed, 2005-06-01 at 22:13 +0200, Arjan van de Ven wrote:
On Wed, 2005-06-01 at 13:07 -0700, Nicholas Miell wrote:
> On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote:
> > * avoid redundant libaries in apps
> > (for example most gnome apps right now have 2 XML libraries loaded and
> > in use)
>
> Lots of GNOME apps/libraries (and probably many other things as well)
> link to libraries that they don't actually use (try "ldd -r -
> u /usr/bin/*" some time). It'd be nice to get rid of those.
>
> Also, some libraries/apps don't actually link to libraries that they
> need and work purely by luck at the moment.
>
> i.e. appA requires libL. libL requires symbols from libM, but doesn't
> link to it. appA also requires libM, so libL happens to work.
>
> Even worse, occasionally appA doesn't actually require libM, but has to
> link to it anyway to make libL work.
yep this is exactly what I meant but explained far better ;)
Ah. I thought you meant that things were using both libxml2 and SAX in
different parts of the app, or something to that effect.
--
Nicholas Miell <nmiell(a)comcast.net>
3:30 p.m.
On Wed, Jun 01, 2005 at 01:26:56PM -0700, Nicholas Miell wrote:
On Wed, 2005-06-01 at 22:13 +0200, Arjan van de Ven wrote:
> On Wed, 2005-06-01 at 13:07 -0700, Nicholas Miell wrote:
> > On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote:
> > > * avoid redundant libaries in apps
> > > (for example most gnome apps right now have 2 XML libraries loaded and
> > > in use)
> >
> > Lots of GNOME apps/libraries (and probably many other things as well)
> > link to libraries that they don't actually use (try "ldd -r -
> > u /usr/bin/*" some time). It'd be nice to get rid of those.
> >
> > Also, some libraries/apps don't actually link to libraries that they
> > need and work purely by luck at the moment.
> >
> > i.e. appA requires libL. libL requires symbols from libM, but doesn't
> > link to it. appA also requires libM, so libL happens to work.
> >
> > Even worse, occasionally appA doesn't actually require libM, but has to
> > link to it anyway to make libL work.
>
> yep this is exactly what I meant but explained far better ;)
Ah. I thought you meant that things were using both libxml2 and SAX in
different parts of the app, or something to that effect.
well both actually.
3:25 a.m.
On Wed, Jun 01, 2005 at 10:30:05PM +0200, Arjan van de Ven wrote:
On Wed, Jun 01, 2005 at 01:26:56PM -0700, Nicholas Miell wrote:
> Ah. I thought you meant that things were using both libxml2 and SAX in
> different parts of the app, or something to that effect.
well both actually.
You mean libxml2 and expat I assume. SAX is just an API more or less
common to both libraries. Don't forget GMarkup which is also the
non-compliant (and apparently slower if I believe feedback I got) parser
embedded in glib.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:15 p.m.
On Wed, 1 Jun 2005, Nicholas Miell wrote:
On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote:
> * avoid redundant libaries in apps
> (for example most gnome apps right now have 2 XML libraries loaded and
> in use)
Lots of GNOME apps/libraries (and probably many other things as well)
link to libraries that they don't actually use (try "ldd -r -
u /usr/bin/*" some time). It'd be nice to get rid of those.
Those links are there because libtool and pkg-config are stupid. libtool
and pkg-config aren't going to stop being stupid anytime soon, so we live
with the situation as-is :)
-- Elliot
3:21 p.m.
On Wed, Jun 01, 2005 at 04:15:36PM -0400, Elliot Lee wrote:
On Wed, 1 Jun 2005, Nicholas Miell wrote:
> On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote:
> > * avoid redundant libaries in apps
> > (for example most gnome apps right now have 2 XML libraries loaded and
> > in use)
>
> Lots of GNOME apps/libraries (and probably many other things as well)
> link to libraries that they don't actually use (try "ldd -r -
> u /usr/bin/*" some time). It'd be nice to get rid of those.
Those links are there because libtool and pkg-config are stupid. libtool
and pkg-config aren't going to stop being stupid anytime soon, so we live
with the situation as-is :)
this is not correct.
pkg-config is fixable!
We need to teach it about -Wl,as-needed which causes the linker only to add
a lib when the app directly uses it.
libtool.. bigger question. But we can get pkg-config to do this right if we
spend 2 days on it.
5:27 p.m.
On Wed, 01 Jun 2005 22:21:09 +0200, Arjan van de Ven wrote:
pkg-config is fixable!
We need to teach it about -Wl,as-needed which causes the linker only to add
a lib when the app directly uses it.
libtool.. bigger question. But we can get pkg-config to do this right if we
spend 2 days on it.
This was already discussed on xdg-list and by James Henstridge. Pkg-config
and libtool aren't broken, they do this for portability. The GNU linker
doesn't need you to enumerate every library in the image but some
(unbelievably) do.
Pkg-config files can't contain --as-needed directly because it's not
portable also.
Maybe one way to do this would just be to make it the default for the
compiler and start filing bugs upstream with the broken apps that don't
actually have DT_NEEDED entries for all their dependencies.
thanks -mike
7:38 p.m.
Mike Hearn (mike(a)navi.cx) said:
> libtool.. bigger question. But we can get pkg-config to do this
right if we
> spend 2 days on it.
This was already discussed on xdg-list and by James Henstridge. Pkg-config
and libtool aren't broken, they do this for portability. The GNU linker
doesn't need you to enumerate every library in the image but some
(unbelievably) do.
Pkg-config files can't contain --as-needed directly because it's not
portable also.
Whyever on earth not?
The upstream distributed pkg-config files, sure.
But if you have a local pkg-config file for the current linker,
the vagaries of the Solaris linker are completely irrelevant.
Bill
1:16 a.m.
On Wed, 01 Jun 2005 20:38:32 -0400, Bill Nottingham wrote:
Whyever on earth not?
The upstream distributed pkg-config files, sure.
But if you have a local pkg-config file for the current linker,
the vagaries of the Solaris linker are completely irrelevant.
Hmm, are you suggesting patching every .pc file in Fedora to have this
option?
One solution might be to use variables ... I think pkg-config allows stuff
like
Libs: $(foo) -lbar -lbaz
Where foo could be defined internally as either "" in the portable
upstream version or "--as-needed" in the downstream version.
1:37 a.m.
On Thu, Jun 02, 2005 at 07:16:18AM +0100, Mike Hearn wrote:
Libs: $(foo) -lbar -lbaz
Where foo could be defined internally as either "" in the portable
upstream version or "--as-needed" in the downstream version.
Note that it would need to be
Libs: $(foo) -lbar -lbaz $(no_foo)
foo = --as-needed
no_foo = --no-as-needed
as the mere fact that you are linking against pkg-configed library xyz
doesn't imply all libraries must be linked with --as-needed.
Jakub
1:41 a.m.
On Thu, 02 Jun 2005 02:37:33 -0400, Jakub Jelinek wrote:
as the mere fact that you are linking against pkg-configed library
xyz
doesn't imply all libraries must be linked with --as-needed.
True, but how often would you not want un-needed dependencies to be
stripped? Is that a common thing to do?
thanks -mike
2:19 a.m.
On Thu, 2005-06-02 at 02:37 -0400, Jakub Jelinek wrote:
On Thu, Jun 02, 2005 at 07:16:18AM +0100, Mike Hearn wrote:
> Libs: $(foo) -lbar -lbaz
>
> Where foo could be defined internally as either "" in the portable
> upstream version or "--as-needed" in the downstream version.
Note that it would need to be
Libs: $(foo) -lbar -lbaz $(no_foo)
foo = --as-needed
no_foo = --no-as-needed
or better
Libs: -lbar
NeededLibs: -lbaz
where pkg-config collects the various groups together, dedupes and then
either issues --as-needed ... --no-as-needed around them (gnu-ld) or
just put them there (non-gnu-ld).
Not rocket science.. and takes those 2 days ;)
6:11 p.m.
On Wed, 2005-06-01 at 22:21 +0200, Arjan van de Ven wrote:
pkg-config is fixable!
We need to teach it about -Wl,as-needed which causes the linker only to add
a lib when the app directly uses it.
I don't really see why this should go in pkg-config... pkg-config isn't
where we set default link flags for the distribution, it's a way to
learn about specific libs.
Why not just make ld do this by default, or put it in the rpm build
config? Is there something we need to know about specific libraries when
we decide whether we want as-needed?
Havoc
2:01 a.m.
On Thu, 2005-06-02 at 19:11 -0400, Havoc Pennington wrote:
On Wed, 2005-06-01 at 22:21 +0200, Arjan van de Ven wrote:
> pkg-config is fixable!
> We need to teach it about -Wl,as-needed which causes the linker only to add
> a lib when the app directly uses it.
I don't really see why this should go in pkg-config... pkg-config isn't
where we set default link flags for the distribution, it's a way to
learn about specific libs.
Why not just make ld do this by default, or put it in the rpm build
config? Is there something we need to know about specific libraries when
we decide whether we want as-needed?
it can't be default realistically and is a per lib thing:
making it default prevents the situation where an app links to a library
in order to provide this service for plugins.
4:55 a.m.
On Fri, 2005-06-03 at 09:01 +0200, Arjan van de Ven wrote:
On Thu, 2005-06-02 at 19:11 -0400, Havoc Pennington wrote:
> On Wed, 2005-06-01 at 22:21 +0200, Arjan van de Ven wrote:
> > pkg-config is fixable!
> > We need to teach it about -Wl,as-needed which causes the linker only to add
> > a lib when the app directly uses it.
>
> I don't really see why this should go in pkg-config... pkg-config isn't
> where we set default link flags for the distribution, it's a way to
> learn about specific libs.
>
> Why not just make ld do this by default, or put it in the rpm build
> config? Is there something we need to know about specific libraries when
> we decide whether we want as-needed?
it can't be default realistically and is a per lib thing:
making it default prevents the situation where an app links to a library
in order to provide this service for plugins.
Just curious: What is wrong with the idea that the plugins link the
libraries they need?
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
3:45 p.m.
On Fri, 2005-06-03 at 11:55 +0200, Nils Philippsen wrote:
> it can't be default realistically and is a per lib thing:
> making it default prevents the situation where an app links to a library
> in order to provide this service for plugins.
Just curious: What is wrong with the idea that the plugins link the
libraries they need?
The application also provides what amounts to a library to the plugin.
I think the situation Arjan is referring to is when the application
needs another library in order to implement some part of its module API,
but it never needs the library unless it has loaded a plugin which uses
that part of the API provided by the application.
--
Peter
6:50 p.m.
Elliot Lee wrote:
Those links are there because libtool and pkg-config are stupid.
libtool
and pkg-config aren't going to stop being stupid anytime soon, so we live
with the situation as-is :)
There is no reason to not fix libtool et.al for Linux to not do the
stupid things necessary on some other platforms. It'll mostly mean
throwing out unnecessary parts of the libtool/... script.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
3:38 a.m.
Another thing :
I'd like jackd in core now that we have a vanilla kernel that can
support it. That or (if jackd is absolutely impossible to integrate)
something else that will make the audio people happy.
And then a lot of audio apps in extras :)
--
Nicolas Mailhot
4:42 a.m.
Another thing :
I'd like jackd in core now that we have a vanilla kernel that can
support it. That or (if jackd is absolutely impossible to integrate)
something else that will make the audio people happy.
And then a lot of audio apps in extras :)
--
Nicolas Mailhot
6:46 a.m.
On Wed, Jun 01, 2005 at 09:44:40PM +0200, Arjan van de Ven wrote:
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
I'd like to see:
* faster boot and shutdown
And suspend/resume... ACPI is unfortunately quite
laptop-specific in how it
works. Currently you need quite a bit of script-tweaking to get it to work.
hibernate (from swsusp2) eases things quite a bit, even if you don't use
swsusp2.
--
Pekka Pietikainen
2:45 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
I really really really want to see anaconda be able to use yum repos. I
think it's "on the list", but I strongly feel that it's worth
reiterating.
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
3:32 p.m.
On Wed, Jun 01, 2005 at 03:45:12PM -0400, Ignacio Vazquez-Abrams wrote:
I really really really want to see anaconda be able to use yum repos.
I
think it's "on the list", but I strongly feel that it's worth
reiterating.
Yeah, this is the Killer Feature from my point of view, since it brings
Extras into the mainstream.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
4:11 p.m.
On Wed, 2005-06-01 at 15:45 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
I really really really want to see anaconda be able to use yum repos. I
think it's "on the list", but I strongly feel that it's worth
reiterating.
Hear Hear!
-sv
4:11 p.m.
On Wed, 2005-06-01 at 17:11 -0400, seth vidal wrote:
On Wed, 2005-06-01 at 15:45 -0400, Ignacio Vazquez-Abrams wrote:
> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> > Extras 5 - what major features are you willing to put effort into?
>
> I really really really want to see anaconda be able to use yum repos. I
> think it's "on the list", but I strongly feel that it's worth
> reiterating.
>
Hear Hear!
Fourth'd!
josh
9:58 a.m.
On Wed, 2005-06-01 at 15:45 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
I really really really want to see anaconda be able to use yum repos. I
think it's "on the list", but I strongly feel that it's worth
reiterating.
The vague plan at this point is to get all of the depsolving, etc using
yum as its backend, but we're probably not going to have UI for adding
more repositories for FC5, at least not in the default install path.
Doing this is a *BIG* change and it really needs to be staged carefully
to avoid disaster[1]
Jeremy
[1] Disaster being defined as my bugzilla mailbox exploding to the point
that there's no way I can keep up with it :-)
2:53 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Best,
-- Elliot
Now that the directory server is starting to trickle out, I'd love to
see that incorporated with some form of administration tool. I've done
a bunch of LDAP setups in recent months and can now finally manage it
from command line/LDIFs but it really doesn't have to be that tough to
get a simple directory setup. The great part about it is that once it's
setup, it can do quite a bit and even act as an Active Directory domain
controller which is really a beautiful thing.
--
David Hollis <dhollis(a)davehollis.com>
9:36 p.m.
New subject: What next? LDAP
--On Wednesday, June 01, 2005 3:53 PM -0400 David Hollis
<dhollis(a)davehollis.com> wrote:
Now that the directory server is starting to trickle out, I'd
love to
see that incorporated with some form of administration tool. I've done
a bunch of LDAP setups in recent months and can now finally manage it
from command line/LDIFs but it really doesn't have to be that tough to
get a simple directory setup. The great part about it is that once it's
setup, it can do quite a bit and even act as an Active Directory domain
controller which is really a beautiful thing.
Agreed. I'm trying to get up to speed on deploying OpenLDAP together with
the Samba schema to get single sign-on and a global address book, but it's
been tough marshaling all the HOWTO's to figure out what's really required.
I went down a wrong path using the PADL scripts bundled with OpenLDAP
(because I failed to select the "enhanced" schema in the common config
file) and they also fail badly on the /etc/services file due to the
presence of Apple protocols. So far the best information for initial setup
seems to be in the HOWTO's at <http://samba.idealx.org/>;, but I'm still
working through it to understand how to migrate my existing setup.
I'd recommend that anyone starting out get the smbtools from idealx and
also get phpldapadmin set up on Apache to maintain the thing and get a more
visual understanding of how things are organized. Hopefully volunteers will
step forward to bring these into Extras.
1:28 p.m.
New subject: What next? LDAP
Kenneth Porter wrote:
--On Wednesday, June 01, 2005 3:53 PM -0400 David Hollis
<dhollis(a)davehollis.com> wrote:
> Now that the directory server is starting to trickle out, I'd love to
> see that incorporated with some form of administration tool. I've done
> a bunch of LDAP setups in recent months and can now finally manage it
> from command line/LDIFs but it really doesn't have to be that tough to
> get a simple directory setup. The great part about it is that once it's
> setup, it can do quite a bit and even act as an Active Directory domain
> controller which is really a beautiful thing.
Agreed. I'm trying to get up to speed on deploying OpenLDAP together
with the Samba schema to get single sign-on and a global address book,
but it's been tough marshaling all the HOWTO's to figure out what's
really required. I went down a wrong path using the PADL scripts bundled
with OpenLDAP (because I failed to select the "enhanced" schema in the
common config file) and they also fail badly on the /etc/services file
due to the presence of Apple protocols. So far the best information for
initial setup seems to be in the HOWTO's at <http://samba.idealx.org/>;,
but I'm still working through it to understand how to migrate my
existing setup.
I'd recommend that anyone starting out get the smbtools from idealx and
also get phpldapadmin set up on Apache to maintain the thing and get a
more visual understanding of how things are organized. Hopefully
volunteers will step forward to bring these into Extras.
The smbldap-tools scripts are already being distributed with samba
Unfortunately the scripts are being packaged as documentation by Red-Hat:
# rpm -ql samba | grep smbldap-tools
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/CONTRIBUTORS
...
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupadd
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupdel
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupmod
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupshow
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-passwd
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-populate
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-useradd
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-userdel
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-userinfo
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-usermod
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-usershow
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap.conf
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap_bind.conf
/usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap_tools.pm
jpo
--
José Pedro Oliveira
* mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo *
* gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
2:44 a.m.
New subject: What next? LDAP
--On Thursday, June 02, 2005 7:28 PM +0100 José Pedro Oliveira
<jpo(a)di.uminho.pt> wrote:
The smbldap-tools scripts are already being distributed with samba
Unfortunately the scripts are being packaged as documentation by Red-Hat:
# rpm -ql samba | grep smbldap-tools
I stand corrected. Why are they bundled into Samba instead of shipped as a
free-standing package? The upstream source (now at 0.9.1) includes its own
spec file and packages fine on FC2.
3:14 p.m.
Bandwidth friendly yum using binary delta algs.
On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Best,
-- Elliot
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
4:57 a.m.
On Thu, 2005-06-02 at 00:24, Mike Hearn wrote:
On Wed, 01 Jun 2005 16:31:46 -0400, seth vidal wrote:
> > Bandwidth friendly yum using binary delta algs.
> >
>
> HAHAHAHAHAH
> no. :)
Why not? SUSE do this, I think.
Initially I don't see any humongous hurdles here either, but others have
investigated this a lot more than I have and come to rather different
conclusions :) See this post from Warren for instance from a thread
January last year:
http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01494.html
The start of that thread contains some proof of concept scripts that
seems to have passed initial testing, but I'm not sure where it all
ended...? One consideration would be extra server space. Unless a common
"RPM diff/patch API" is developed that can be employed by yum, up2date,
apt etc. then you'll need to provide both the binary patches and the
full updated RPM's which I guess would roughly double the serverspace
needed. I think you would also need more local space, i.e. wouldn't
every RPM that comes with the distribution need to be available so that
they can be copied and patched with updates?
In any case, you're right about SuSE - they've done it for quite some
time I think, but I have no idea how they've implemented it.
To sum up my feelings:
Initial thought: That would be great!
Second thought: That would probably be nice.
Upon further investigation: I have no idea really, but Seth, Warren and
others seem to have deemed it not feasible or at least hard to pull off
successfully.
Regards,
--
Tarjei
5:10 a.m.
On Thu, Jun 02, 2005 at 11:57:26AM +0200, Tarjei Knapstad wrote:
The start of that thread contains some proof of concept scripts that
seems to have passed initial testing, but I'm not sure where it all
ended...? One consideration would be extra server space. Unless a common
"RPM diff/patch API" is developed that can be employed by yum, up2date,
apt etc. then you'll need to provide both the binary patches and the
full updated RPM's which I guess would roughly double the serverspace
needed.
You'll always need the full rpm on the server in case something doesn't
work with the delta. Deltas are normally about 10% of the full rpm, so
that you double the needed space if you keep 10 deltas per package.
I'm just preparing deltarpm v3 which has support for combining deltas.
The point is that a delta is always between two exact rpm versions.
If the client has left out some updates the server can combine the
missing deltas to a single one (combining is quite fast as it doesn't
need full rpms) and send it instead.
I think you would also need more local space, i.e. wouldn't
every RPM that comes with the distribution need to be available so that
they can be copied and patched with updates?
No, deltas can work with filesystem data.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
5:21 a.m.
*snip*
I'm just preparing deltarpm v3 which has support for combining
deltas.
The point is that a delta is always between two exact rpm versions.
If the client has left out some updates the server can combine the
missing deltas to a single one (combining is quite fast as it doesn't
need full rpms) and send it instead.
*snip*
Or the client download two deltas and combine them? Having the server do
processing won't be taken ligthly by mirrors...
5:27 a.m.
On Thu, Jun 02, 2005 at 12:10:12PM +0200, Michael Schroeder wrote:
> I think you would also need more local space, i.e. wouldn't
> every RPM that comes with the distribution need to be available so that
> they can be copied and patched with updates?
No, deltas can work with filesystem data.
What do you do about %config files? They can be legitimately changed
on the filesystem. Also, what about prelinked executables/libraries?
Do you include %config files in all delta rpms and unprelink
executables/libraries to a stream before creating a rpm from that?
Jakub
5:32 a.m.
On Thu, Jun 02, 2005 at 06:27:24AM -0400, Jakub Jelinek wrote:
What do you do about %config files? They can be legitimately
changed
on the filesystem.
All files that have the content verify bit off (i.e. that don't get
checked by rpm -V) are not included in the delta generation.
Also, what about prelinked executables/libraries?
Good point. Prelink support is indeed missing in the current
implementation. It wouldn't be that hard to add, though.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
6:31 a.m.
On 6/2/05, Michael Schroeder <mls(a)suse.de> wrote:
You'll always need the full rpm on the server in case something
doesn't
work with the delta. Deltas are normally about 10% of the full rpm, so
that you double the needed space if you keep 10 deltas per package.
AFAIK, SUSE delta RPMs don´t require the presence of the full,
original, binary RPM.
Instead, the delta RPM can patch the needed files on the fly, directly
onto the filesystem. In fact, they are not exactly deltas between
complete RPM packages/files, but patch RPMs (or deltas for individual
files inside an RPM package).
7:13 a.m.
On Thu, Jun 02, 2005 at 01:31:32PM +0200, Felipe Alfaro Solana wrote:
On 6/2/05, Michael Schroeder <mls(a)suse.de> wrote:
> You'll always need the full rpm on the server in case something doesn't
> work with the delta. Deltas are normally about 10% of the full rpm, so
> that you double the needed space if you keep 10 deltas per package.
AFAIK, SUSE delta RPMs don´t require the presence of the full,
original, binary RPM.
Are you talking about the client or the server side? The server
should always have the full rpm in case the client doesn't understand
deltas or the deltas don't match.
The client can either work with filesystem data or with the old
rpm.
Instead, the delta RPM can patch the needed files on the fly,
directly
onto the filesystem.
No, it doesn't do this. Applydeltarpm creates an rpm that is bitwise
identical to the original. That's the beauty of it, you can still
verify the rpm signature and so on.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
3:40 p.m.
On 6/1/05, Joe Desbonnet <jdesbonnet(a)gmail.com> wrote:
Bandwidth friendly yum using binary delta algs.
As seen in one of the fedora lists in march. A proof-of-concept proxy
server that layers over yum.
http://www.wombat.ie/software/rpmdc/releasenotes-0.1.0.html
If the proxy server approach works, there is no reason why it can't be
used as a general way to provide this functionality to the userbase
that needs it without shoving support for deltas into yum itself.
-jef
4:02 p.m.
I'd be willing to maintain an diff archive for FC4. I need to update
the software to use deltarpm by Michael Schroeder: this is an
excellent piece of software that allows binary patches to be applied
without having to keep the RPMs lying around (it computes deltas on a
file by file basis, ignoring config files which are likely to change).
There is one (minor) thing I don't like about deltarpm: the algorithm
(while good) is hard coded into the format. It would be nice if the
delta format allowed different algorithms to be used. Perhaps using
VCDIFF
(RFC 3284 - The VCDIFF Generic Differencing and Compression Data Format).
Regarding the archive: I don't have a suitable FTP server. I estimate
a max of about 1GB
of storage would be needed.
Joe.
On 6/2/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 6/1/05, Joe Desbonnet <jdesbonnet(a)gmail.com> wrote:
> Bandwidth friendly yum using binary delta algs.
As seen in one of the fedora lists in march. A proof-of-concept proxy
server that layers over yum.
http://www.wombat.ie/software/rpmdc/releasenotes-0.1.0.html
If the proxy server approach works, there is no reason why it can't be
used as a general way to provide this functionality to the userbase
that needs it without shoving support for deltas into yum itself.
-jef
4:09 p.m.
On 6/2/05, Joe Desbonnet <jdesbonnet(a)gmail.com> wrote:
Regarding the archive: I don't have a suitable FTP server. I
estimate
a max of about 1GB
of storage would be needed.
perhaps, some existing fedora mirrors would choose to work with you?
Someone on the mirror list might be gracious enough to forward a brief
proposal from you so individual mirror maintainers could contact you
if they want to help provide support for your deltas. I have no idea
if any of them will choose to help with this or not, but you never
know....
-jef
3:19 p.m.
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Improved Kerberos/Active Directory support?
I asked last week about establishing a standard for keytabs. Noone
replied.
It would be nice to have a way for authconfig/anaconda to make a system
join an AD realm. This is trickier than joining a realm managed by MIT
Kerberos.
The case where you have a domain administrator at the keyboard is more
or less handled by Samba 3's "net ads join", but that's only one of the
possible scenarios. I have been trying to tweak Samba to handle another
scenario: a computer account has already been created in the directory
and you have the account's password. Now you need to create the host
principal (for ssh and the like to work), as well as additional
principals for httpd and other services. For the time being I can see
this done in post-install kickstart scriptlets, because it relies on
Samba's net command. Hopefully with Samba4 things could be made easier to
integrate.
Authconfig would be involved in creating (if needed) the LDAP mappings
necessary to convert the Services for Unix schema to the RFC2037
schema that nss_ldap uses:
http://enterprise.linux.com/enterprise/04/12/09/2318244.shtml?tid=102&...
Something like that should remove yet another barrier to Linux
adoption.
--
Rudi
3:20 p.m.
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
- a window manager which isn't the functional equivalent of
hello_world.c where I cannot even easily grab a window and just
move it to another desktop without fiddling with the pager or some
menus (all only allowing to drag the window to the same relative
position on another desktop... I'd like to just grab the window,
hit the desktop border and can drag along in the next adjacent
desktop - as it is possible with about all other WMs. metacity is
just inferior). Doesn't have to be Enlightenment, but please... :-)
- a network server for Evolution (perhaps based on Directory Server?)
so one can actually use Evolution for time and task management at
home AND on the road (read: from different machines) without having
to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange
clone).
- a window manager which isn't [...]
- tool support to setup X 3D acceleration (OpenGL) stuff. I'm always
having a HARD time getting 3D accel to work.
- a window manager which isn't [...]
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
3:21 p.m.
On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote:
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
Ah, and I forgot:
- integration of some one-time password authentication scheme like S/Key
or OPIE.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
3:25 p.m.
- a window manager which isn't the functional equivalent of
hello_world.c where I cannot even easily grab a window and just
move it to another desktop without fiddling with the pager or some
menus (all only allowing to drag the window to the same relative
position on another desktop... I'd like to just grab the window,
hit the desktop border and can drag along in the next adjacent
desktop - as it is possible with about all other WMs. metacity is
just inferior). Doesn't have to be Enlightenment, but please... :-)
yum install brightside
provides all the things you listed above for metacity.
-sv
3:36 p.m.
On Wed, Jun 01, 2005 at 04:25:12PM -0400, seth vidal wrote:
> - a window manager which isn't the functional equivalent of
> hello_world.c where I cannot even easily grab a window and just
> move it to another desktop without fiddling with the pager or some
> menus (all only allowing to drag the window to the same relative
> position on another desktop... I'd like to just grab the window,
> hit the desktop border and can drag along in the next adjacent
> desktop - as it is possible with about all other WMs. metacity is
> just inferior). Doesn't have to be Enlightenment, but please... :-)
yum install brightside
provides all the things you listed above for metacity.
Thanks, that looks indeed like something that would cure the most pain
for now.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
3:38 p.m.
On Wed, 2005-06-01 at 22:36 +0200, Daniel Roesen wrote:
On Wed, Jun 01, 2005 at 04:25:12PM -0400, seth vidal wrote:
> > - a window manager which isn't the functional equivalent of
> > hello_world.c where I cannot even easily grab a window and just
> > move it to another desktop without fiddling with the pager or some
> > menus (all only allowing to drag the window to the same relative
> > position on another desktop... I'd like to just grab the window,
> > hit the desktop border and can drag along in the next adjacent
> > desktop - as it is possible with about all other WMs. metacity is
> > just inferior). Doesn't have to be Enlightenment, but please... :-)
>
> yum install brightside
>
> provides all the things you listed above for metacity.
Thanks, that looks indeed like something that would cure the most pain
for now.
see how useful fedora extras can be? :)
-sv
3:52 p.m.
Daniel Roesen (dr(a)cluenet.de) said:
- tool support to setup X 3D acceleration (OpenGL) stuff. I'm
always
having a HARD time getting 3D accel to work.
Not sure a tool is useful here. If it's not working, that 99% of
the time means code is broken somewhere, not a config option missing.
Bill
3:58 p.m.
On Wed, 2005-06-01 at 22:20 +0200, Daniel Roesen wrote:
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
- a window manager which isn't the functional equivalent of
hello_world.c where I cannot even easily grab a window and just
move it to another desktop without fiddling with the pager or some
menus (all only allowing to drag the window to the same relative
position on another desktop... I'd like to just grab the window,
hit the desktop border and can drag along in the next adjacent
desktop - as it is possible with about all other WMs. metacity is
just inferior). Doesn't have to be Enlightenment, but please... :-)
You can do this in metacity: grab the window's title bar then hit the
key combination you use to switch to the destination workspace.
Tom
3:59 p.m.
On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote:
desktop - as it is possible with about all other WMs. metacity is
just inferior). Doesn't have to be Enlightenment, but please... :-)
XFCE should be in extras. End of problem
- a window manager which isn't [...]
See above
- tool support to setup X 3D acceleration (OpenGL) stuff. I'm
always
having a HARD time getting 3D accel to work.
This should work out of the box and thats what I'd like to see happen not
more config tools - do you really need tools ?
Alan
--
"Microsoft Office, only used by dinosaurs"
4:05 p.m.
On Wed, Jun 01, 2005 at 04:59:32PM -0400, Alan Cox wrote:
On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote:
> desktop - as it is possible with about all other WMs. metacity is
> just inferior). Doesn't have to be Enlightenment, but please... :-)
XFCE should be in extras. End of problem
So when I install XFCE, do I get the exact same desktop just with some
added functionality, or do I have to spend some hours of integration
work so that things "work together" properly again? I tried to go
down this road with Enlightenment after RH has thrown it out of the
window and it was pain and I gave up finally.
> - tool support to setup X 3D acceleration (OpenGL) stuff.
I'm always
> having a HARD time getting 3D accel to work.
This should work out of the box and thats what I'd like to see happen not
more config tools - do you really need tools ?
My wording wasn't good I guess. What I meant was that when the installer
detects e.g. a Matrox card, it should (by default or optionally) just
set up all the 3D accel stuff like agpgart and DRM module loading,
X.org config like DRI and GLX etc. It should "just work". I've spend
literally hours recently to get my G550 going with 3D accel and only
succeeded half-way (X.org is now saying "rendering enabled" but glxinfo
says "no rendering"). Had my G200 working fine (also after some hours
of googling and mergin all the tips and hints together into a working
setup).
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
4:07 p.m.
On Wed, Jun 01, 2005 at 11:05:19PM +0200, Daniel Roesen wrote:
So when I install XFCE, do I get the exact same desktop just with
some
added functionality, or do I have to spend some hours of integration
work so that things "work together" properly again? I tried to go
down this road with Enlightenment after RH has thrown it out of the
window and it was pain and I gave up finally.
You get a lightweight desktop that honours gnome hints and will run with
nautilus/gnome-panel if you want. It also starts up in about 2 seconds
4:12 p.m.
Daniel Roesen (dr(a)cluenet.de) said:
> This should work out of the box and thats what I'd like to
see happen not
> more config tools - do you really need tools ?
My wording wasn't good I guess. What I meant was that when the installer
detects e.g. a Matrox card, it should (by default or optionally) just
set up all the 3D accel stuff like agpgart and DRM module loading,
agpgart is not a module.
DRM module loading is done by the X server.
DRI and GLX are enabled by default, AFAIK.
Bill
5:35 p.m.
On Wed, Jun 01, 2005 at 05:12:48PM -0400, Bill Nottingham wrote:
Daniel Roesen (dr(a)cluenet.de) said:
> > This should work out of the box and thats what I'd like to see happen not
> > more config tools - do you really need tools ?
>
> My wording wasn't good I guess. What I meant was that when the installer
> detects e.g. a Matrox card, it should (by default or optionally) just
> set up all the 3D accel stuff like agpgart and DRM module loading,
agpgart is not a module.
$ /sbin/lsmod | fgrep agpgart
agpgart 56740 3
DRM module loading is done by the X server.
DRI and GLX are enabled by default, AFAIK.
Uhm.
I think I made a major mistake. I've not verified that the problems
I described are still there in FC4T3 (or anything newer than FC1).
My bad. Perhaps all this IS already a problem of the past...
Please excuse the noise if all that is nowadays a non-issue, but in my
FC1, no DRI stuff was set up at all.
Well, as soon as FC4 is out, I'll upgrade (reinstall actually) my
desktop and notebook systems to FC4 and see how things are, and will
get back if that stuff is still an issue.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
5:48 p.m.
On Thu, Jun 02, 2005 at 12:35:27AM +0200, Daniel Roesen wrote:
I think I made a major mistake. I've not verified that the
problems
I described are still there in FC4T3 (or anything newer than FC1).
My bad. Perhaps all this IS already a problem of the past...
Please excuse the noise if all that is nowadays a non-issue, but in my
FC1, no DRI stuff was set up at all.
Things should be a *lot* better in this regard with current distros.
Dave
4:18 p.m.
On Wed, Jun 01, 2005 at 11:05:19PM +0200, Daniel Roesen wrote:
My wording wasn't good I guess. What I meant was that when the
installer
detects e.g. a Matrox card, it should (by default or optionally) just
set up all the 3D accel stuff like agpgart and DRM module loading,
X.org config like DRI and GLX etc. It should "just work". I've spend
literally hours recently to get my G550 going with 3D accel and only
succeeded half-way (X.org is now saying "rendering enabled" but glxinfo
says "no rendering"). Had my G200 working fine (also after some hours
of googling and mergin all the tips and hints together into a working
setup).
Are you running the G550 in dual-head mode ?
Xinerama usage disables direct rendering. There is a way around
it using the mergedfb option aparently, but I've never tried it.
Dave
5:27 p.m.
On Wed, Jun 01, 2005 at 05:18:16PM -0400, Dave Jones wrote:
> My wording wasn't good I guess. What I meant was that when
the installer
> detects e.g. a Matrox card, it should (by default or optionally) just
> set up all the 3D accel stuff like agpgart and DRM module loading,
> X.org config like DRI and GLX etc. It should "just work". I've spend
> literally hours recently to get my G550 going with 3D accel and only
> succeeded half-way (X.org is now saying "rendering enabled" but glxinfo
> says "no rendering"). Had my G200 working fine (also after some hours
> of googling and mergin all the tips and hints together into a working
> setup).
Are you running the G550 in dual-head mode ?
Nope, I know of this limitation.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
4:24 p.m.
On Wed, 2005-06-01 at 23:05 +0200, Daniel Roesen wrote:
On Wed, Jun 01, 2005 at 04:59:32PM -0400, Alan Cox wrote:
> On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote:
> > desktop - as it is possible with about all other WMs. metacity is
> > just inferior). Doesn't have to be Enlightenment, but please... :-)
>
> XFCE should be in extras. End of problem
Yes! I'm using XFCE from Extras on FC3 and am very happy with it.
So when I install XFCE, do I get the exact same desktop just with
some
added functionality, or do I have to spend some hours of integration
work so that things "work together" properly again? I tried to go
down this road with Enlightenment after RH has thrown it out of the
window and it was pain and I gave up finally.
Whatever customizations you've made for metacity will remain with
metacity. However, its quite easy to configure XFCE to do almost
everything you can do in metacity. And XFCE does a lot of stuff that
you simply cannot do in metacity including, for instance, configurable
window edge resistance, the ability to raise windows above the top of
the screen, etc.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
4:41 p.m.
*snip*
- a network server for Evolution (perhaps based on Directory
Server?)
so one can actually use Evolution for time and task management at
home AND on the road (read: from different machines) without having
to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange
clone).
*snip*
Sounds like Hula to me - not that I've tried it myself
Kyrre
5:45 p.m.
On Wed, Jun 01, 2005 at 11:41:12PM +0200, Kyrre Ness Sjobak wrote:
*snip*
> - a network server for Evolution (perhaps based on Directory Server?)
> so one can actually use Evolution for time and task management at
> home AND on the road (read: from different machines) without having
> to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange
> clone).
*snip*
Sounds like Hula to me - not that I've tried it myself
When I looked for a solution a few weeks ago, I've spend some hours
of googling and reading mailing list archives, and the only thing I've
been able to come up with was
a) use OpenGroupware!
b) use Microsoft Exchange!
c) oh yeah, I'd really like a lightweight server without all the
bloat OpenGroupware needs to just store my stuff somewhere
accessibly from remote locations
The general consensus I found everywhere was "doesn't exist, or use
the big ones".
I didn't stumble over Hula at all... interesting. And Hula doesn't do
contacts stuff. And that's besides calendar stuff what I'd need Evo
most for - but it does other stuff I don't need, e.g. IMAP4 server
and webmail etc.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
9:02 p.m.
[snip]
When I looked for a solution a few weeks ago, I've spend some
hours
of googling and reading mailing list archives, and the only thing I've
been able to come up with was
a) use OpenGroupware!
b) use Microsoft Exchange!
c) oh yeah, I'd really like a lightweight server without all the
bloat OpenGroupware needs to just store my stuff somewhere
accessibly from remote locations
The general consensus I found everywhere was "doesn't exist, or use
the big ones".
I didn't stumble over Hula at all... interesting. And Hula doesn't do
contacts stuff. And that's besides calendar stuff what I'd need Evo
most for - but it does other stuff I don't need, e.g. IMAP4 server
and webmail etc.
Well, if you don't use Evo, you can use egroupware as a
backend server for
kontact(kmail/korganizer/kaddressbook) and it works pretty well. it's not
nearly the PITA to manage that opengroupware or MS Exchange are. I prefer
IMAP4 myself, something about being able to get to my email everywhere(kinda
like you want to do with your calandar and contacts)
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
5:36 a.m.
> > - a network server for Evolution (perhaps based on
Directory Server?)
> > so one can actually use Evolution for time and task management at
> > home AND on the road (read: from different machines) without having
> > to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange
> > clone).
> *snip*
>
> Sounds like Hula to me - not that I've tried it myself
When I looked for a solution a few weeks ago, I've spend some hours
of googling and reading mailing list archives, and the only thing I've
been able to come up with was
a) use OpenGroupware!
b) use Microsoft Exchange!
c) oh yeah, I'd really like a lightweight server without all the
bloat OpenGroupware needs to just store my stuff somewhere
accessibly from remote locations
The general consensus I found everywhere was "doesn't exist, or use
the big ones".
I didn't stumble over Hula at all... interesting. And Hula doesn't do
contacts stuff. And that's besides calendar stuff what I'd need Evo
most for - but it does other stuff I don't need, e.g. IMAP4 server
and webmail etc.
www.hula-project.org
Contacts/address book is coming. The project was originally Novells
Netmail product but they have to scrub the code to get any stuff out
that they can't release as open source for what ever reason and its
taking time but they are getting there. I think the address book code
is one of the next on the list (you can see the remaining list on
their site under scrub list). I think its the most promising open
mail/calender/contacts product out there. Looking forward to the
promised gmail esque webmail/calender interface :-)
Been meaning to try and package this up as an rpm myself.
Pete
6:09 a.m.
On Thu, 2 Jun 2005, Peter Robinson wrote:
www.hula-project.org
Contacts/address book is coming. The project was originally Novells
Netmail product but they have to scrub the code to get any stuff out
that they can't release as open source for what ever reason and its
taking time but they are getting there. I think the address book code
is one of the next on the list (you can see the remaining list on
their site under scrub list). I think its the most promising open
mail/calender/contacts product out there. Looking forward to the
promised gmail esque webmail/calender interface :-)
Been meaning to try and package this up as an rpm myself.
*hint hint* There's a first attempt (since abandoned, I believe) at a
package of hula in the Extras CVS that you might start from
Just as a word of warning: hula's a big, complex, ugly web app from a
packaging perspective. It really wasn't designed with sane packaging (or
sane integration period) in mind ;-)
later,
chris
6:24 a.m.
> Contacts/address book is coming. The project was originally
Novells
> Netmail product but they have to scrub the code to get any stuff out
> that they can't release as open source for what ever reason and its
> taking time but they are getting there. I think the address book code
> is one of the next on the list (you can see the remaining list on
> their site under scrub list). I think its the most promising open
> mail/calender/contacts product out there. Looking forward to the
> promised gmail esque webmail/calender interface :-)
>
> Been meaning to try and package this up as an rpm myself.
*hint hint* There's a first attempt (since abandoned, I believe) at a
package of hula in the Extras CVS that you might start from
Just as a word of warning: hula's a big, complex, ugly web app from a
packaging perspective. It really wasn't designed with sane packaging (or
sane integration period) in mind ;-)
I suspected as much which is why I've not got around to doing it yet :-)
Pete
6:39 a.m.
Hi
>*hint hint* There's a first attempt (since abandoned, I
believe) at a
>package of hula in the Extras CVS that you might start from
>
>Just as a word of warning: hula's a big, complex, ugly web app from a
>packaging perspective. It really wasn't designed with sane packaging (or
>sane integration period) in mind ;-)
>
>
To be fair, people run into this type of problems while working with a
project which has just been open sourced. Exactly the same thing has
happened with the recently open sourced Fedora Directory server. I
expect these kind of wrinkles to be ironed out over a few months of work
http://www.0xdeadbeef.com/html/2005/06/#200506010936
regards
Rahul
8:12 p.m.
On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote:
- tool support to setup X 3D acceleration (OpenGL) stuff. I'm
always
having a HARD time getting 3D accel to work.
If you have an OSS-supported 3D card, there should be no need to set
it up at all. It should "Just Work". If that isn't true, it is a
bug.
If your 3D card requires binary drivers, then having a tool in Core to
configure it is silly.
3:27 a.m.
On Wednesday 01 June 2005 13:20, Daniel Roesen wrote:
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and
> Fedora Extras 5 - what major features are you willing to put effort
> into?
- a window manager which isn't the functional equivalent of
hello_world.c where I cannot even easily grab a window and just
move it to another desktop without fiddling with the pager or some
menus (all only allowing to drag the window to the same relative
position on another desktop... I'd like to just grab the window,
hit the desktop border and can drag along in the next adjacent
desktop - as it is possible with about all other WMs. metacity is
just inferior). Doesn't have to be Enlightenment, but please... :-)
KDE. ;)
I'm using it now on FC4t3.
David
3:31 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
What about stretching out the dev cycle from 3months dev + 3 months of
testing to something more like 6 months of dev + 3 months of testing.
I'd be willing to work toward that feature.
And if we want anaconda with yum repo support, and pup and new yum
doodads, and the new buildsystem, etc, etc, etc, I think we need to
start discussing stretching out the release cycle a bit to get the
infrastructure bits done.
-sv
3:35 p.m.
On Wed, 2005-06-01 at 16:31 -0400, seth vidal wrote:
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
>
What about stretching out the dev cycle from 3months dev + 3 months of
testing to something more like 6 months of dev + 3 months of testing.
agreed in part. Fedora is ready for a bigger cycle so that more
fundamental things can get fixed. I don't like 6+3 per se, I'd like 3+3
+3, 3 devel, 3 devel+test and 3 test
4:16 p.m.
>
> What about stretching out the dev cycle from 3months dev + 3 months of
> testing to something more like 6 months of dev + 3 months of testing.
agreed in part. Fedora is ready for a bigger cycle so that more
fundamental things can get fixed. I don't like 6+3 per se, I'd like 3+3
+3, 3 devel, 3 devel+test and 3 test
Sure - but in total a 9 month release cycle for this rev would take the
strain off of some of us who aren't paid to do this all day.
-sv
1:38 p.m.
On Wednesday 01 June 2005 23:16, seth vidal wrote:
> > What about stretching out the dev cycle from 3months dev +
3 months of
> > testing to something more like 6 months of dev + 3 months of testing.
>
> agreed in part. Fedora is ready for a bigger cycle so that more
> fundamental things can get fixed. I don't like 6+3 per se, I'd like 3+3
> +3, 3 devel, 3 devel+test and 3 test
Sure - but in total a 9 month release cycle for this rev would take the
strain off of some of us who aren't paid to do this all day.
I think we should
do only work on infrastructure for FC5 and basically get
FC5=FC4+FC4updates+infrastructure in the 6 months timeframe we have.
--
http://LinuxWiki.org/RonnyBuchmann
3:35 p.m.
On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote:
What about stretching out the dev cycle from 3months dev + 3 months
of
testing to something more like 6 months of dev + 3 months of testing.
I'd be willing to work toward that feature.
That would be awesome. And it'd take some of the pressure off of Fedora
Legacy.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
3:45 p.m.
On Wed, Jun 01, 2005 at 04:35:51PM -0400, Matthew Miller wrote:
On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote:
> What about stretching out the dev cycle from 3months dev + 3 months of
> testing to something more like 6 months of dev + 3 months of testing.
> I'd be willing to work toward that feature.
That would be awesome. And it'd take some of the pressure off of Fedora
Legacy.
Agreed. And users whould have _some_ more usable lifetime of their
installs, which would make me happy. :-)
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
4:38 p.m.
ons, 01.06.2005 kl. 22.35 skrev Matthew Miller:
On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote:
> What about stretching out the dev cycle from 3months dev + 3 months of
> testing to something more like 6 months of dev + 3 months of testing.
> I'd be willing to work toward that feature.
That would be awesome. And it'd take some of the pressure off of Fedora
Legacy.
Could fedora legacy use the same repourls as fedora core/extras? So that
it would just continue to be "yum update"?
Kyrre
5:30 p.m.
On Wed, 2005-06-01 at 23:38 +0200, Kyrre Ness Sjobak wrote:
ons, 01.06.2005 kl. 22.35 skrev Matthew Miller:
> On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote:
> > What about stretching out the dev cycle from 3months dev + 3 months of
> > testing to something more like 6 months of dev + 3 months of testing.
> > I'd be willing to work toward that feature.
>
> That would be awesome. And it'd take some of the pressure off of Fedora
> Legacy.
>
Could fedora legacy use the same repourls as fedora core/extras? So that
it would just continue to be "yum update"?
I've often wondered why the final update for fedora (before cgoing
legacy) doesn't include a switch to fedora legacy as part of it.
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
9:17 p.m.
On Thu, Jun 02, 2005 at 08:30:24AM +1000, Rodd Clarkson wrote:
> Could fedora legacy use the same repourls as fedora core/extras?
So that
> it would just continue to be "yum update"?
I've often wondered why the final update for fedora (before cgoing
legacy) doesn't include a switch to fedora legacy as part of it.
Because Legacy and Core aren't that coordinated yet, that's why.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
5:58 p.m.
Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
What about stretching out the dev cycle from 3months dev + 3 months
of
testing to something more like 6 months of dev + 3 months of testing.
How about deciding what the major goals of the next release should be
(within reason of course), estimating about how long it should take to
meet those goals, and then add in whatever else seems reasonable in the
given time frame?
Fedora Core is not a marketing driven project like the commercial
distros; releases need not be done on a fixed schedule. Instead, they
should be made when there is something worth making a major release and
based on technology goals.
And if we want anaconda with yum repo support, and pup and new yum
doodads, and the new buildsystem, etc, etc, etc, I think we need to
start discussing stretching out the release cycle a bit to get the
infrastructure bits done.
That would be a big plus; before diving in to the next release, get the
infrastructure done. I think anaconda with repo support should be a
requirement for Extras to be considered "tier 1", but Extras also needs
to be able to operate smoothly (mostly) automatically so you have more
time to work on yum and such.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
6:07 p.m.
On Wed, Jun 01, 2005 at 05:58:23PM -0500, Chris Adams wrote:
Fedora Core is not a marketing driven project like the commercial
distros; releases need not be done on a fixed schedule. Instead, they
should be made when there is something worth making a major release and
based on technology goals.
But Fedora is Red Hat's technology beta platform for RHEL - so they
need somewhat timely feedback on what works and what doesn't "in the
field". So I doubt that RH buys into much longer release cycles...
Personally, I think 9 months is a good compromise.
Best regards,
Daniel (a former RHL beta tester, like you too *g*)
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
6:35 p.m.
On Wed, 1 Jun 2005, Chris Adams wrote:
Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
> What about stretching out the dev cycle from 3months dev + 3 months of
> testing to something more like 6 months of dev + 3 months of testing.
How about deciding what the major goals of the next release should be
(within reason of course), estimating about how long it should take to
meet those goals, and then add in whatever else seems reasonable in the
given time frame?
Because the decision was explicitly made when the Fedora project started
to do releases at regular intervals rather than based on feature-driven
milestones. This is the model Gnome has used with a good bit of success.
It avoids the Debian "work on it for three years until it's perfect"
syndrome, because as this thread is already showing, everyone wants "just
a little bit longer" to get their pet feature just right.
Best,
-- Elliot
6:44 p.m.
To reiterate what Elliot said, the basic principle as I see it is that we
endeavor for the current Fedora release always to have the newest stuff
that is reasonably stable. After some fairly short interval in the 3-6
month ballpark, *something* certainly has a newer and better version that
is reasonably stable. So more or less any time "rawhide has newer stuff",
then it's a good reason to have a Fedora Core release before too long. If
that sensation comes along, and there's something with a bleeding edge
that's still too bloody, then that something can roll back to the stable
version until the next FC release. It won't be too long.
We don't want Fedora Core ever to spend significant periods of time where
there is great new fabulosity out there, in some area or other, that we
aren't representing in the latest release.
6:59 p.m.
On 6/1/05, Roland McGrath <roland(a)redhat.com> wrote:
We don't want Fedora Core ever to spend significant periods of
time where
there is great new fabulosity out there, in some area or other, that we
aren't representing in the latest release.
On the other hand... fedora specific infrastructure.. like a community
facing buildsystem or community facing process/policy needs some
breathing room when the feature set of the actual releases themselves
aren't the primary focus of leadership. Pushing hard to get the
latest bits out... makes it difficult to get our own processes and
tools in working order.. so people can work together effectively. I'd
rather see the next couple of months focused on fedora project
infrastructure and process, then start the clock again for the next
core release development cycle so we can have more mature tools and
processes in place.
-jef
12:12 a.m.
On Wed, 2005-06-01 at 16:44 -0700, Roland McGrath wrote:
To reiterate what Elliot said, the basic principle as I see it is
that we
endeavor for the current Fedora release always to have the newest stuff
that is reasonably stable. After some fairly short interval in the 3-6
month ballpark, *something* certainly has a newer and better version that
is reasonably stable. So more or less any time "rawhide has newer stuff",
then it's a good reason to have a Fedora Core release before too long. If
that sensation comes along, and there's something with a bleeding edge
that's still too bloody, then that something can roll back to the stable
version until the next FC release. It won't be too long.
We don't want Fedora Core ever to spend significant periods of time where
there is great new fabulosity out there, in some area or other, that we
aren't representing in the latest release.
That's easy for you to say. You get paid to work on linux and/or
fedora/rhel for a living. You have all day to work on it. If fedora is
intended to have community involvement you have to remember that there
are many of us who are doing this outside of our real job. Remember,
fedora is for hobbyists.
But if hobbyists cannot participate in development b/c the cycle is just
too fast, well then it's not too terribly useful for us, is it.
-sv
10:37 a.m.
On Thu, 2 Jun 2005, seth vidal wrote:
On Wed, 2005-06-01 at 16:44 -0700, Roland McGrath wrote:
> To reiterate what Elliot said, the basic principle as I see it is that we
> endeavor for the current Fedora release always to have the newest stuff
> that is reasonably stable. After some fairly short interval in the 3-6
> month ballpark, *something* certainly has a newer and better version that
> is reasonably stable. So more or less any time "rawhide has newer
stuff",
> then it's a good reason to have a Fedora Core release before too long. If
> that sensation comes along, and there's something with a bleeding edge
> that's still too bloody, then that something can roll back to the stable
> version until the next FC release. It won't be too long.
>
> We don't want Fedora Core ever to spend significant periods of time where
> there is great new fabulosity out there, in some area or other, that we
> aren't representing in the latest release.
That's easy for you to say. You get paid to work on linux and/or
fedora/rhel for a living. You have all day to work on it. If fedora is
intended to have community involvement you have to remember that there
are many of us who are doing this outside of our real job. Remember,
fedora is for hobbyists.
But if hobbyists cannot participate in development b/c the cycle is just
too fast, well then it's not too terribly useful for us, is it.
So my answer would be "if FC5 deadlines don't give you enough time to
complete a given piece of work, target FC6 instead".
On the other hand, someone was also pointing out that there are some
pieces that really need to be worked on every single release, so it's more
complicated than that. Maybe we need to try to decouple development work
from the release cycle a bit more. What if we could make it so that
hardcore development work could go on throughout all six months of the
development cycle?
Best,
-- Elliot
10:52 a.m.
Hi
On the other hand, someone was also pointing out that there are some
pieces that really need to be worked on every single release, so it's more
complicated than that. Maybe we need to try to decouple development work
from the release cycle a bit more. What if we could make it so that
hardcore development work could go on throughout all six months of the
development cycle?
Best,
-- Elliot
Maybe branch of for FC6 half way during the FC5 development or
variations of it. It might very well be a crazy idea though
regards
Rahul
11:03 a.m.
On 6/2/05, Elliot Lee <sopwith(a)redhat.com> wrote:
On the other hand, someone was also pointing out that there are some
pieces that really need to be worked on every single release, so it's more
complicated than that. Maybe we need to try to decouple development work
from the release cycle a bit more. What if we could make it so that
hardcore development work could go on throughout all six months of the
development cycle?
Except there are fedora specific infrastructure and process peices
that need love so they can be more effective tools during the release
cycle. How about this:
0)FC N comes out
1) Provide short time to make incramental changes to fedora
contributor facing infrastructure, tools and policy, based on feedback
during the FC N release cycle.
2) Put those incramental changes in tools and policy in place for use
in FC N+1 testing/release.
3)Use those updated infrastructure during the release cycle..finding
where they are suboptimal. Avoid the temptation to continually screw
around with infrastructure items during a release cycle, because you
know you'll have some time to make changes post FC N+1 release.
4)N=+N+1
5)goto 0
-jef
2:51 p.m.
On Thu, 2005-06-02 at 11:37 -0400, Elliot Lee wrote:
So my answer would be "if FC5 deadlines don't give you
enough time to
complete a given piece of work, target FC6 instead".
On the other hand, someone was also pointing out that there are some
pieces that really need to be worked on every single release, so it's more
complicated than that. Maybe we need to try to decouple development work
from the release cycle a bit more. What if we could make it so that
hardcore development work could go on throughout all six months of the
development cycle?
Except that I can guarantee there will be things that have to be done
for FC5 as well. And splitting development efforts across branches when
the resources are already at the point of scarcity helps nothing.
Jeremy
1:25 a.m.
So my answer would be "if FC5 deadlines don't give you
enough time to
complete a given piece of work, target FC6 instead".
Not to be rude but why the hard headed attachment to 'WE MUST RELEASE
EVERY 6 MONTHS'. The gnome people have recently said that new and
interesting development has been stymied somewhat by that schedule and
that development for gnome 3.0 is not going to fit into that schedule.
On the other hand, someone was also pointing out that there are some
pieces that really need to be worked on every single release, so it's more
complicated than that. Maybe we need to try to decouple development work
from the release cycle a bit more. What if we could make it so that
hardcore development work could go on throughout all six months of the
development cycle?
I'd love to see how you do that given the available resources. I just
don't see my time being any more available than it is currently.
-sv
2:59 a.m.
On Fri, Jun 03, 2005 at 02:25:26AM -0400, seth vidal wrote:
> So my answer would be "if FC5 deadlines don't give you enough time to
> complete a given piece of work, target FC6 instead".
Not to be rude but why the hard headed attachment to 'WE MUST RELEASE
EVERY 6 MONTHS'. The gnome people have recently said that new and
interesting development has been stymied somewhat by that schedule and
This does not reflect at all un understanding of the GNOME community
There is very strong backing for time based releases. There may be
people with a different viewpoint, but it's certainly not
"The gnome people".
that development for gnome 3.0 is not going to fit into that
schedule.
And most of the people around the GNOME community do not want a 3.0
revolutionary release, all I heard from GUADEC last week indicated
otherwise.
The point is that most people/companies prefer a graceful gradual shift than
big point releases. This does not prevent big change, but it forces to
still release and take into account the evolution. To me the counter example of
Debian stable release shows clearly why a time based release schedule
is very important for the community in general.
You think your change will take too long to implement ? Then plan this over
the time frame of multiple releases, really !
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:09 a.m.
On Fri, 2005-06-03 at 03:59 -0400, Daniel Veillard wrote:
On Fri, Jun 03, 2005 at 02:25:26AM -0400, seth vidal wrote:
>
> > So my answer would be "if FC5 deadlines don't give you enough time to
> > complete a given piece of work, target FC6 instead".
>
> Not to be rude but why the hard headed attachment to 'WE MUST RELEASE
> EVERY 6 MONTHS'. The gnome people have recently said that new and
> interesting development has been stymied somewhat by that schedule and
This does not reflect at all un understanding of the GNOME community
There is very strong backing for time based releases. There may be
people with a different viewpoint, but it's certainly not
"The gnome people".
you're right. I misspoke. I was referring to what I had read in a series
of blog entries on the subject.
The point is that most people/companies prefer a graceful gradual
shift than
big point releases. This does not prevent big change, but it forces to
still release and take into account the evolution. To me the counter example of
Debian stable release shows clearly why a time based release schedule
is very important for the community in general.
You think your change will take too long to implement ? Then plan this over
the time frame of multiple releases, really !
I'm not arguing against a time based release. I'm arguing against the
current time allotted for the release. So I think time based released
are just fine - but not when it only allows about 2-3 months of actual
time allotted to doing any development
Can you see the distinction b/t the two?
-sv
4:26 a.m.
On Fri, Jun 03, 2005 at 04:09:05AM -0400, seth vidal wrote:
I'm not arguing against a time based release. I'm arguing
against the
current time allotted for the release. So I think time based released
are just fine - but not when it only allows about 2-3 months of actual
time allotted to doing any development
Can you see the distinction b/t the two?
Any duration will get people arguing whether it's too long or too short.
To me 6 months is a 80/20 equilibrium point, plus it makes very easy to
memorize and predict releases (one for the Summer, one for the Winter).
Just skip one release, branch and you get 9 months to work without being
disturbed too much. It seems to me that a fair amount of users follow that
pattern too and don't update every 6 months, but every year or so (that would
be an interesting poll to set up on the fedora web site I think).
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
8:20 a.m.
On Fri, Jun 03, 2005 at 05:26:08AM -0400, Daniel Veillard wrote:
Just skip one release, branch and you get 9 months to work without
being
disturbed too much. It seems to me that a fair amount of users follow that
pattern too and don't update every 6 months, but every year or so (that would
be an interesting poll to set up on the fedora web site I think).
So, do you want Seth to contribute all the work he's been doing only to
even-numbered Fedora releases?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
8:27 a.m.
On Fri, Jun 03, 2005 at 09:20:04AM -0400, Matthew Miller wrote:
So, do you want Seth to contribute all the work he's been doing only to
even-numbered Fedora releases?
If the changes are too big to be done in six months (and I seriously
doubt all Seth's work qualifies), sure. Why not?
Emmanuel
10:34 a.m.
On Fri, Jun 03, 2005 at 03:27:33PM +0200, Emmanuel Seyman wrote:
> So, do you want Seth to contribute all the work he's been
doing only to
> even-numbered Fedora releases?
If the changes are too big to be done in six months (and I seriously
doubt all Seth's work qualifies), sure. Why not?
Have you looked at everything Seth's been doing for Extras?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
10:37 a.m.
On Fri, 2005-06-03 at 11:34 -0400, Matthew Miller wrote:
On Fri, Jun 03, 2005 at 03:27:33PM +0200, Emmanuel Seyman wrote:
> > So, do you want Seth to contribute all the work he's been doing only to
> > even-numbered Fedora releases?
> If the changes are too big to be done in six months (and I seriously
> doubt all Seth's work qualifies), sure. Why not?
Have you looked at everything Seth's been doing for Extras?
it's not just me.
But that's the point, isn't it. Even the folks inside rh need more time
to work on things b/c b/t rhel update releases and everything else, the
time is just tight.
-sv
11:03 a.m.
On Fri, Jun 03, 2005 at 11:37:55AM -0400, seth vidal wrote:
> Have you looked at everything Seth's been doing for Extras?
it's not just me.
Right, sorry to pick on you -- you're just a highly-visible example and you
started the subthread. It's pretty much EVERY outside contributor to Fedora.
But that's the point, isn't it. Even the folks inside rh need
more time
to work on things b/c b/t rhel update releases and everything else, the
time is just tight.
And sure, I think it'd help inside people too.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
10:54 a.m.
On Fri, Jun 03, 2005 at 11:34:35AM -0400, Matthew Miller wrote:
Have you looked at everything Seth's been doing for Extras?
He's been doing a lot but I don't see how this relates to the subject.
Some projects will make major releases every six months, some projects
will do them in longer periods of time and some projects will do them
when they feel like it.
How is this a problem?
Emmanuel
12:42 p.m.
On Fri, 2005-06-03 at 17:54 +0200, Emmanuel Seyman wrote:
On Fri, Jun 03, 2005 at 11:34:35AM -0400, Matthew Miller wrote:
>
> Have you looked at everything Seth's been doing for Extras?
He's been doing a lot but I don't see how this relates to the subject.
Some projects will make major releases every six months, some projects
will do them in longer periods of time and some projects will do them
when they feel like it.
How is this a problem?
b/c a fair bit of the stuff I, and others are working on, get tied up in
each other. So if project X takes two release cycles then projects Y and
Z have to wait for project X.
The projects are not islands unto themselves. They have to be taken in
the context of other items.
-sv
8:44 a.m.
On 6/3/05, Daniel Veillard <veillard(a)redhat.com> wrote:
(that would
be an interesting poll to set up on the fedora web site I think).
I'd love a more useful central website!
Red Hat sort of needs to make time between releases though to redo it.
So how about.. 2 extras months... before fc5 testing begins.. to work
on things like the website.. and the community build system. So those
things can be in place for the fc5 cycle.
-jef
8:48 a.m.
Jeff Spaleta wrote:
On 6/3/05, Daniel Veillard <veillard(a)redhat.com> wrote:
>(that would
>be an interesting poll to set up on the fedora web site I think).
>
>
I'd love a more useful central website!
Red Hat sort of needs to make time between releases though to redo it.
So how about.. 2 extras months... before fc5 testing begins.. to work
on things like the website.. and the community build system. So those
things can be in place for the fc5 cycle.
Join the Fedora marketing list and propose your ideas. Expect some good
ideas to pop up in that list pretty soon
regards
Rahul
4:05 p.m.
Any duration will get people arguing whether it's too long or
too short.
To me 6 months is a 80/20 equilibrium point, plus it makes very easy to
memorize and predict releases (one for the Summer, one for the Winter).
Any change requires discussion. That's how change happens. I'm glad you
feel good about a schedule that's twice a year, but I don't think that's
enough time for what we're trying to get done.
Just skip one release, branch and you get 9 months to work without
being
disturbed too much. It seems to me that a fair amount of users follow that
pattern too and don't update every 6 months, but every year or so (that would
be an interesting poll to set up on the fedora web site I think).
it doesn't work that way b/c some of the stuff I want to do would stall
out plans for anaconda and pup, as well, it plays into a lot of doodads
we want to get more time moving on.
these projects are not islands unto themselves, they involve other plans
too. Release coordination should be a discussion otherwise it's not
really an integrated release.
-sv
4:26 a.m.
On Fri, Jun 03, 2005 at 05:05:00PM -0400, seth vidal wrote:
> Just skip one release, branch and you get 9 months to work
without being
> disturbed too much. It seems to me that a fair amount of users follow that
> pattern too and don't update every 6 months, but every year or so (that would
> be an interesting poll to set up on the fedora web site I think).
it doesn't work that way b/c some of the stuff I want to do would stall
out plans for anaconda and pup, as well, it plays into a lot of doodads
we want to get more time moving on.
these projects are not islands unto themselves, they involve other plans
too. Release coordination should be a discussion otherwise it's not
really an integrated release.
Can't you branch all 3 ? differential updates done to head can then
be merged back selectively when the branch is made the main trunk once
ready. In general I don't see why this is not possible, I would need
more specifics to understand. I assume it's about integrating the extras
which I agree may need deep structural change in some of the distro tools,
but I fail to see why this can't be done on a branch.
Are you afraid of not having enough momentum if you branch to
get this done ?
If this is the case maybe this mean the plan must be brought up
more publicly to try to ensure sufficient community support on that
branch effort.
Are you afraid of the cost of merging back the branch as the main trunk ?
Sure this is an annoyance but from a community perspective less
than breaking the release cycle or the loss of momentum due to the
larger gap between releases.
"release early, release often" still rules in my opinion, fedora is not
just a distro it's also the key channel between a community of users and
a community of developers, increasing the time between releases weakens
that link a lot in my opinion, making it less valuable to both communities
which could result in a big loss of users to other reactive distros like
Ubuntu. Even if the ultimate goals of the big changes is to increase usefulness
to those 2 communities, the impact of delaying releases can be negative in
the end. That's why I'm suggesting to branch with a clear plan of what is to
be achieved, and expectation of when this would become the main trunk.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
7:05 p.m.
seth vidal wrote:
But if hobbyists cannot participate in development b/c the cycle is
just
too fast, well then it's not too terribly useful for us, is it.
I don't buy this argument at all. So what if the changes you're working
on don't go in the next release? They can still go into the one after
that. There will always be cutoff points and a more frequent release
cycle is actually the only mean to ensure a feature can get wide
exposure by being part of the distribution.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
7:23 p.m.
On Sat, 2005-06-04 at 17:05 -0700, Ulrich Drepper wrote:
seth vidal wrote:
> But if hobbyists cannot participate in development b/c the cycle is just
> too fast, well then it's not too terribly useful for us, is it.
I don't buy this argument at all.
I'm sorry you don't buy it - but I wasn't stating an opinion, I was
describing the case.
So what if the changes you're working on don't go in the
next release?
Well the changes I'm working on for this next release affect anaconda
and the package updater in use on fedora, so, yah, I think there is a
problem if they don't go in the next release.
-sv
7:31 p.m.
seth vidal wrote:
> So what if the changes you're working on don't go in the
next release?
Well the changes I'm working on for this next release affect anaconda
and the package updater in use on fedora, so, yah, I think there is a
problem if they don't go in the next release.
No, it just means that coordination is needed. Just as it does now but
today this coordination (or lack thereof) manifests itself "only" in
temporarily broken FC trees.
Projects are getting larger and larger and need more time to develop.
Increasing the release cycle every year or two isn't the answer.
Developers simply need to get a bit more sophisticated and have a stable
development tree and one or more blue-sky trees.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
2:08 a.m.
Projects are getting larger and larger and need more time to
develop.
Increasing the release cycle every year or two isn't the answer.
How would you know? Red hat has never had a release cycle of anything
other than 6 months. You seem to be making an assertion you can't
support. I'm suggesting we try something to see if it helps.
Developers simply need to get a bit more sophisticated and have a
stable
development tree and one or more blue-sky trees.
I'll make sure I put that down on my list of things to do for fedora
next week:
'be more sophisticated'
thanks,
-sv
3:27 a.m.
On Sun, Jun 05, 2005 at 03:08:40AM -0400, seth vidal wrote:
> Projects are getting larger and larger and need more time to develop.
> Increasing the release cycle every year or two isn't the answer.
How would you know? Red hat has never had a release cycle of anything
other than 6 months. You seem to be making an assertion you can't
support. I'm suggesting we try something to see if it helps.
Sure we do internally... RHEL so far has had an 18 months cycle
and it does work by branching at some point and doing the work we want
to do on the community base until it is ready to release. Like you we
need more time to integrate changes and stabilize than what the 6month
cycle allows, we also have the need to integrate most of it back into
the main cycle, and not disrupt it. It requires planning, branching,
merging, but it's doable and I think we can support that model from a
technical standpoint since we are over the fourth iteration on that model.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:30 a.m.
On Sun, 2005-06-05 at 04:27 -0400, Daniel Veillard wrote:
On Sun, Jun 05, 2005 at 03:08:40AM -0400, seth vidal wrote:
>
> > Projects are getting larger and larger and need more time to develop.
> > Increasing the release cycle every year or two isn't the answer.
>
> How would you know? Red hat has never had a release cycle of anything
> other than 6 months. You seem to be making an assertion you can't
> support. I'm suggesting we try something to see if it helps.
Sure we do internally... RHEL so far has had an 18 months cycle
Nice of y'all to allow yourself longer release cycles while denying it
to fedora community developers.
and it does work by branching at some point and doing the work we
want
to do on the community base until it is ready to release. Like you we
need more time to integrate changes and stabilize than what the 6month
cycle allows, we also have the need to integrate most of it back into
the main cycle, and not disrupt it. It requires planning, branching,
merging, but it's doable and I think we can support that model from a
technical standpoint since we are over the fourth iteration on that model.
I think we don't have nearly enough volunteers or infrastructure to say
that the fourth iteration of that model is viable. I've watched the
amount of stuff that needs to be done at the fedora extras steering
committee meetings and it's non-trivial and needs to be done ASAP.
-sv
11:42 a.m.
On Sun, 2005-06-05 at 12:30 -0400, seth vidal wrote:
On Sun, 2005-06-05 at 04:27 -0400, Daniel Veillard wrote:
> >
> > How would you know? Red hat has never had a release cycle of anything
> > other than 6 months. You seem to be making an assertion you can't
> > support. I'm suggesting we try something to see if it helps.
>
> Sure we do internally... RHEL so far has had an 18 months cycle
Nice of y'all to allow yourself longer release cycles while denying it
to fedora community developers.
I agree with Seth here. A longer release cycle could prove to be very
beneficial. 18 months would be too long for Fedora, but 9 might work
out very nicely. What's the harm in trying it for a release and seeing
how it goes?
> and it does work by branching at some point and doing the work we want
> to do on the community base until it is ready to release. Like you we
> need more time to integrate changes and stabilize than what the 6month
> cycle allows, we also have the need to integrate most of it back into
> the main cycle, and not disrupt it. It requires planning, branching,
> merging, but it's doable and I think we can support that model from a
> technical standpoint since we are over the fourth iteration on that model.
I think we don't have nearly enough volunteers or infrastructure to say
that the fourth iteration of that model is viable. I've watched the
amount of stuff that needs to be done at the fedora extras steering
committee meetings and it's non-trivial and needs to be done ASAP.
As an aside, perhaps the FESCO meeting agendas/minutes should be
publicly available somewhere. Then people who want to volunteer for
stuff like that would have a place to look. At the very least, it
provides the community with an idea of what's happening and where things
are headed.
josh
12:12 p.m.
As an aside, perhaps the FESCO meeting agendas/minutes should be
publicly available somewhere. Then people who want to volunteer for
stuff like that would have a place to look. At the very least, it
provides the community with an idea of what's happening and where things
are headed.
I thought they were. I'll bring it up at the next meeting for us to post
them prominently.
Thanks,
-sv
12:19 p.m.
On Sun, 2005-06-05 at 13:12 -0400, seth vidal wrote:
> As an aside, perhaps the FESCO meeting agendas/minutes should
be
> publicly available somewhere. Then people who want to volunteer for
> stuff like that would have a place to look. At the very least, it
> provides the community with an idea of what's happening and where things
> are headed.
>
I thought they were. I'll bring it up at the next meeting for us to post
them prominently.
Thanks. I found a few older posts to the mailing list about them, but
nothing recent.
IIRC, the meetings are usually held in an IRC chat. Perhaps even just
posting the log from that would suffice. Although, having nice
summarized action items would be good too :).
josh
12:21 p.m.
On Sun, 2005-06-05 at 12:19 -0500, Josh Boyer wrote:
On Sun, 2005-06-05 at 13:12 -0400, seth vidal wrote:
> > As an aside, perhaps the FESCO meeting agendas/minutes should be
> > publicly available somewhere. Then people who want to volunteer for
> > stuff like that would have a place to look. At the very least, it
> > provides the community with an idea of what's happening and where things
> > are headed.
> >
>
> I thought they were. I'll bring it up at the next meeting for us to post
> them prominently.
Thanks. I found a few older posts to the mailing list about them, but
nothing recent.
IIRC, the meetings are usually held in an IRC chat. Perhaps even just
posting the log from that would suffice. Although, having nice
summarized action items would be good too :).
posting the logs would be a bad idea, if only b/c of the cursing ;)
-sv
9:43 p.m.
On Sun, 2005-06-05 at 11:42 -0500, Josh Boyer wrote:
As an aside, perhaps the FESCO meeting agendas/minutes should be
publicly available somewhere. Then people who want to volunteer for
stuff like that would have a place to look. At the very least, it
provides the community with an idea of what's happening and where things
are headed.
Yes, they should. This is partially my fault as I started writing up
reasonable minutes and then never posted them anywhere. I can't promise
a change for this week as I may not be able to make the FESCO meeting
due to real life concerns, but for next week, I will _commit_ to making
them available to the world at large. At least by mailing to
fedora-extras-list and I'll also try to get them so they can at least be
linked from fedora.redhat.com.
Jeremy
3:07 a.m.
On Sun, Jun 05, 2005 at 10:43:02PM -0400, Jeremy Katz wrote:
On Sun, 2005-06-05 at 11:42 -0500, Josh Boyer wrote:
> As an aside, perhaps the FESCO meeting agendas/minutes should be
> publicly available somewhere. Then people who want to volunteer for
> stuff like that would have a place to look. At the very least, it
> provides the community with an idea of what's happening and where things
> are headed.
Yes, they should. This is partially my fault as I started writing up
reasonable minutes and then never posted them anywhere. I can't promise
a change for this week as I may not be able to make the FESCO meeting
due to real life concerns, but for next week, I will _commit_ to making
them available to the world at large. At least by mailing to
fedora-extras-list and I'll also try to get them so they can at least be
linked from fedora.redhat.com.
Thanks, this is a painful routine, but from my experience as Gnome secretary
it's important for the community and it's better to have not perfect minutes
delivered quickly after the meeting than perfect minutes posted 3 weeks
later (when faced with "I should finish the minutes and post them when I have
more time" I would suggest to just post them as is, then the worse which can
happen is that people will ask more question and raise awareness :-)
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:44 a.m.
On Mon, 2005-06-06 at 04:07 -0400, Daniel Veillard wrote:
On Sun, Jun 05, 2005 at 10:43:02PM -0400, Jeremy Katz wrote:
> On Sun, 2005-06-05 at 11:42 -0500, Josh Boyer wrote:
> > As an aside, perhaps the FESCO meeting agendas/minutes should be
> > publicly available somewhere. Then people who want to volunteer for
> > stuff like that would have a place to look. At the very least, it
> > provides the community with an idea of what's happening and where things
> > are headed.
>
> Yes, they should. This is partially my fault as I started writing up
> reasonable minutes and then never posted them anywhere. I can't promise
> a change for this week as I may not be able to make the FESCO meeting
> due to real life concerns, but for next week, I will _commit_ to making
> them available to the world at large. At least by mailing to
> fedora-extras-list and I'll also try to get them so they can at least be
> linked from fedora.redhat.com.
Thanks, this is a painful routine, but from my experience as Gnome secretary
it's important for the community and it's better to have not perfect minutes
delivered quickly after the meeting than perfect minutes posted 3 weeks
later (when faced with "I should finish the minutes and post them when I have
more time" I would suggest to just post them as is, then the worse which can
happen is that people will ask more question and raise awareness :-)
+1
<governance>
The reason that most board agendas begin with "approval of the minutes
from the last meeting" is specifically so that minutes can be
distributed quickly and corrected later if there's a problem. Buffering
minutes to get them right leads to more trouble than it's worth.
</governance>
M
12:49 p.m.
On Sun, Jun 05, 2005 at 12:30:35PM -0400, seth vidal wrote:
that the fourth iteration of that model is viable. I've watched
the
amount of stuff that needs to be done at the fedora extras steering
committee meetings and it's non-trivial and needs to be done ASAP.
I asked you to give informations about what is giving troubles,
now you reference something I never heard of before.
What is the fedora extras steering committee ? Pointers ? First time I
heard about it.
Maybe I'm just off track, but there is a complete lack of clarity
around all this at least from my perspective.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
12:52 p.m.
On Sun, Jun 05, 2005 at 01:49:02PM -0400, Daniel Veillard wrote:
I asked you to give informations about what is giving troubles,
now you reference something I never heard of before.
What is the fedora extras steering committee ? Pointers ? First time I
heard about it.
<http://www.google.com/search?q=fedora+extras+steering+committee>
Maybe I'm just off track, but there is a complete lack of
clarity
around all this at least from my perspective.
By "all this" do you mean Fedora in general, or Fedora Extras, or what?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
1:08 p.m.
On Sun, Jun 05, 2005 at 01:52:05PM -0400, Matthew Miller wrote:
On Sun, Jun 05, 2005 at 01:49:02PM -0400, Daniel Veillard wrote:
> I asked you to give informations about what is giving troubles,
> now you reference something I never heard of before.
> What is the fedora extras steering committee ? Pointers ? First time I
> heard about it.
<http://www.google.com/search?q=fedora+extras+steering+committee>
> Maybe I'm just off track, but there is a complete lack of clarity
> around all this at least from my perspective.
By "all this" do you mean Fedora in general, or Fedora Extras, or what?
about the technical work which need to be done and which need to change
the Fedora cycle durations. What, who, when, how long, and why this
can't be done in parrallel ? All I'm getting is "we need longuer
cycles"
and still not understanding.
BTW I'm not represnting Red Hat position, just an engineer trying to
understand some engineering plumbing and not getting it.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
1:12 p.m.
about the technical work which need to be done and which need to
change
the Fedora cycle durations. What, who, when, how long, and why this
can't be done in parrallel ? All I'm getting is "we need longuer
cycles"
and still not understanding.
BTW I'm not represnting Red Hat position, just an engineer trying to
understand some engineering plumbing and not getting it.
Who: fedora community people along with some red hat release engineers
What: Fedora extras steering committee
Why: We have to re-engineer EVERYTHING that y'all already have in order
to: 1. support systems which are not inside red hat's network
2. have a buildsystem at all
3. have an errata release mechanism at all
4. have a db to coordinate any of these things.
We're not allowed to use or even see anything already written at rh b/c
either: 1. it sucks or 2. it's part of the 'secret sauce' that some vp
at rh thinks is valuable, somehow.
So we have to start over from scratch on everything and only a handful
of those systems are in place:
1. cvs - only took a year to get it happening and another 6 months to
use it
2. account system - only 18 months
3. build system - once extras got moving it took a mere 4 months to
get time to take care of it - and we still have to throw one away.
4. errata system - not there yet - probably AT LEAST another 6 months
5. db for coordination - just starting
oh and we need all of those things YESTERDAY.
So there you go. - that's the list - now do you understand why we would
like a little more time before the next release?
-sv
4:07 p.m.
On Sun, Jun 05, 2005 at 02:12:09PM -0400, seth vidal wrote:
Who: fedora community people along with some red hat release
engineers
What: Fedora extras steering committee
Why: We have to re-engineer EVERYTHING that y'all already have in order
to: 1. support systems which are not inside red hat's network
2. have a buildsystem at all
3. have an errata release mechanism at all
4. have a db to coordinate any of these things.
We're not allowed to use or even see anything already written at rh b/c
either: 1. it sucks or 2. it's part of the 'secret sauce' that some vp
at rh thinks is valuable, somehow.
So we have to start over from scratch on everything and only a handful
of those systems are in place:
1. cvs - only took a year to get it happening and another 6 months to
use it
2. account system - only 18 months
3. build system - once extras got moving it took a mere 4 months to
get time to take care of it - and we still have to throw one away.
4. errata system - not there yet - probably AT LEAST another 6 months
5. db for coordination - just starting
oh and we need all of those things YESTERDAY.
So there you go. - that's the list -
thanks, I note that
http://fedora.redhat.com/participate/
seems to imply all this background infrastructure will magically happen
and then people will be able to contribute. Maybe making public what need
to be done and building a community around making those and maintaining them
could help the magic disapear.
now do you understand why we would
like a little more time before the next release?
No. There is a lot of work needed to change the machine used to make
the final product called Fedora Core. I don't see why developping
that new machine can't be done in parallel with the current one still
running. I'm only left with the guess that you think doing both in
parallel need more workforce than we have currently, is that right ?
If it's the case it might be worth asking why there isn't more volunteers
to help on the infrastructure.
Again don't consider I'm coming from a Red Hat angle, I'm more trying
to find parallels with other projects I know like GNOME where we had
some similar problems (building a release team, sysadmin maintainance,
etc.) but which were less core to the project itself.
Also I'm perfectly fine being told that I'm just bothering the people
doing the work, in which case I will just return to my dark cave.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
4:44 p.m.
On Sun, 2005-06-05 at 17:07 -0400, Daniel Veillard wrote:
No. There is a lot of work needed to change the machine used to
make
the final product called Fedora Core. I don't see why developping
that new machine can't be done in parallel with the current one still
running.
Mostly because history has shown us that Red Hat et al can work on one
thing at a time. If thats a release, then everything suffers until
release is done. When releases are happening every 6 months, this
leaves very very little time for the Giant to pay attention to
infrastructure. Asking to extend development time so that there is time
to focus on infrastructure, while focusing on the next release could be
possible.
I'm only left with the guess that you think doing both in
parallel need more workforce than we have currently, is that right ?
If it's the case it might be worth asking why there isn't more
volunteers
to help on the infrastructure.
Another problem. Outsiders can't really do much. We're told that
things are being worked on to help us contribute, and so far the only
thing we can contribute is extras packages. Infrastructure is decided
on behind mostly closed doors, and the only thing that has worked for
community contribution is to just build something (like the Extras build
system) and shove it in RH's face, so that they have to take it and use
it.
--
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
6:34 p.m.
> I'm only left with the guess that you think doing both in
> parallel need more workforce than we have currently, is that right ?
> If it's the case it might be worth asking why there isn't more
> volunteers
> to help on the infrastructure.
Another problem. Outsiders can't really do much. We're told that
things are being worked on to help us contribute, and so far the only
thing we can contribute is extras packages. Infrastructure is decided
on behind mostly closed doors, and the only thing that has worked for
community contribution is to just build something (like the Extras build
system) and shove it in RH's face, so that they have to take it and use
it.
I've found that the best way for external folks to make larger changes
is to have their own infrastructure. Hence, fedora extras runs out of
my building. :) We've got to get beyond that or make a nice way of tying
together multiple infrastructures as 'fedora'. I think we're getting
closer to that in some ways. We need to update and renovate
http://fedoraproject.org and try to stop relying on fedora.redhat.com
for the web infrastructure I think, especially in light of the fedora
foundation. Finding fedora as a subdomain off of redhat.com makes less
sense if the goal of the fedora foundation is for fedora to live a
little more on its own.
-sv
6:36 p.m.
On 6/5/05, seth vidal <skvidal(a)phy.duke.edu> wrote:
Finding fedora as a subdomain off of redhat.com makes less
sense if the goal of the fedora foundation is for fedora to live a
little more on its own.
Oh are we making up goals for the foundation now? or did you find out
more about it?
-jef
6:40 p.m.
On Sun, 2005-06-05 at 19:36 -0400, Jeff Spaleta wrote:
On 6/5/05, seth vidal <skvidal(a)phy.duke.edu> wrote:
> Finding fedora as a subdomain off of redhat.com makes less
> sense if the goal of the fedora foundation is for fedora to live a
> little more on its own.
Oh are we making up goals for the foundation now? or did you find out
more about it?
In the absence of goals I prefer to create them.
All the media cruft I've read this week has said:
"Red Hat is freeing the Fedora project to allow it to become a fully
independent entity. Red Hat will continue to support Fedora financially,
but the project will be governed by an independent board of directors."
quoted from:
http://business.newsforge.com/article.pl?sid=05/06/03/1729211&from=rss
That sounds like 'fedora should be more independent from red hat' to me.
-sv
5:16 p.m.
On Sun, Jun 05, 2005 at 05:07:27PM -0400, Daniel Veillard wrote:
If it's the case it might be worth asking why there isn't
more volunteers
to help on the infrastructure.
Because we *can't* run a marathon every six months.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
9:38 p.m.
On Sun, 2005-06-05 at 14:12 -0400, seth vidal wrote:
> about the technical work which need to be done and which need
to change
> the Fedora cycle durations. What, who, when, how long, and why this
> can't be done in parrallel ? All I'm getting is "we need longuer
cycles"
> and still not understanding.
>
> BTW I'm not represnting Red Hat position, just an engineer trying to
> understand some engineering plumbing and not getting it.
>
Who: fedora community people along with some red hat release engineers
What: Fedora extras steering committee
Why: We have to re-engineer EVERYTHING that y'all already have in order
to: 1. support systems which are not inside red hat's network
2. have a buildsystem at all
3. have an errata release mechanism at all
4. have a db to coordinate any of these things.
We're not allowed to use or even see anything already written at rh b/c
either: 1. it sucks or 2. it's part of the 'secret sauce' that some vp
at rh thinks is valuable, somehow.
So we have to start over from scratch on everything and only a handful
of those systems are in place:
1. cvs - only took a year to get it happening and another 6 months to
use it
2. account system - only 18 months
3. build system - once extras got moving it took a mere 4 months to
get time to take care of it - and we still have to throw one away.
4. errata system - not there yet - probably AT LEAST another 6 months
5. db for coordination - just starting
oh and we need all of those things YESTERDAY.
So there you go. - that's the list - now do you understand why we would
like a little more time before the next release?
We don't need all of those things yesterday. If we did, we wouldn't
have FC/FE4 rolling out soon. OTOH, I think you, Jesse, and Miloslav do
a good job of stating the primary goal here: infrastructure has been
taking too long to appear. We need more developer hours to make
everything come together for FC5.
Will changing the amount of time in a release cycle get us to that goal?
I kinda doubt it. I think a longer release cycle will mean developers
will get to spend more time working on their packages and projects. You
might know that nine months will be enough for you to get the build
system out even if no one else helps but what about the rest of the
promised infrastructure gals? What we need is for more developers to
spend time on the projects related to infrastructure.
We need to prioritize and assign tasks.
First: What things have been promised or are otherwise blocker
infrastructure goals for FC5 that we must have adequate developers
working on? What things should they start working on next so we can
meet our goals for FC6? How many man hours will it take to complete
each of the stated infrastructure goals? Are the goals something that
multiple developers can work on or only certain specific developers?
What things are always going to need some maintenance work so we'll have
to permanently allocate some developer time to it?
And then: What developers from within the Red Hat fence can be assigned
to work on this instead of the projects they are working on now? What
is needed to empower developers outside the fenceline to step into the
roles necessary to make meaningful contributions to the infrastructure?
Seth has bandwidth, hardware, information on the things the buildsystem
must do to be acceptable to Red Hat, and a job that gives him time for a
lot of Fedora hacking. What would be needed to (for instance) hack a
new front-end for bugzilla that allows tracking of new packages in
Extras from initial request, through review and fixing, into acceptance?
I don't think we'll have all the infrastructure done simply by giving
you nine months to work on it. I do think we can make progress by
saying Seth is going to have this specific piece of the infrastructure
that we have promised for FC5 done in nine months. While he's working
on that we can have the other tasks promised for FC5 completed if we
assign Developer A, B, and C to work on them. All other goals are
allowed to slip into the FC6 (9 + 6 month time frame) although
developers A and C can work on them if they finish their projects
early.
If people want to commit Fedora to 6 months for FC5, there will also
have to be a commitment of more developers to divide up the necessary
work to make that happen.
-Toshio
6:07 p.m.
On Sun, 2005-06-05 at 12:30 -0400, seth vidal wrote:
On Sun, 2005-06-05 at 04:27 -0400, Daniel Veillard wrote:
> On Sun, Jun 05, 2005 at 03:08:40AM -0400, seth vidal wrote:
> >
> > > Projects are getting larger and larger and need more time to develop.
> > > Increasing the release cycle every year or two isn't the answer.
> >
> > How would you know? Red hat has never had a release cycle of anything
> > other than 6 months. You seem to be making an assertion you can't
> > support. I'm suggesting we try something to see if it helps.
>
> Sure we do internally... RHEL so far has had an 18 months cycle
Nice of y'all to allow yourself longer release cycles while denying it
to fedora community developers.
Not fair--see below.
> and it does work by branching at some point and doing the work
we want
> to do on the community base until it is ready to release. Like you we
> need more time to integrate changes and stabilize than what the 6month
> cycle allows, we also have the need to integrate most of it back into
> the main cycle, and not disrupt it. It requires planning, branching,
> merging, but it's doable and I think we can support that model from a
> technical standpoint since we are over the fourth iteration on that model.
I think we don't have nearly enough volunteers or infrastructure to say
that the fourth iteration of that model is viable. I've watched the
amount of stuff that needs to be done at the fedora extras steering
committee meetings and it's non-trivial and needs to be done ASAP.
Seth, you've actually answered your own question. Based on what I have
seen inside of Red Hat, 6 months is a release cycle that matches well
the challenge of the problem with the nature and resources of the
present community. Even with the surprise 7 day delay, FC4 is great, as
was FC3 vs. the targets we all set. I even think that your suggestion
of a one-time-for-now 9 month cycle could make sense. But the stuff
that's required to hit an 18 month target is just Night And Day
different. It may look easy--copying and criticizing the decisions we
make is pretty easy stuff compared to sorting out the initial plan and
keeping enough of the contingencies viable that the release is relevant
by the time it sees daylight. I'm not saying that Red Hat is the only
one trying to make these guesses and trying to following them through to
their logical conclusion--there are companies and community efforts
alike that try this stuff every day. But I am saying that it's a
sufficiently difficult and resource-intensive task that it's Just Not
Fair to suggest that simple goal-setting will lead to simple goal
attainment. Running a marathon is hard, but running up up Mt. Everest
is a different ballgame, and pretending it's not is reckless.
My $0.02.
M
12:07 a.m.
Am Sonntag, den 05.06.2005, 15:12 -0400 schrieb Jeff Spaleta:
On 6/5/05, Michael Tiemann <tiemann(a)redhat.com> wrote:
> I even think that your suggestion
> of a one-time-for-now 9 month cycle could make sense.
+1
-1
The whole world (and the press also) knows "Suse and Fedora usually ship
in April/May and September/October". Okay, with FC4 we're a bit late.
But it would IMHO be nice if it could stay this way.
And with a 9 Month schedule this time we would have the end of the beta
phase around/after Chrismas. And (if we go back to 6 month after that)
the next one during the summer holidays. I suspect that will decrease
testing (and work spend just before release).
And we'll get a lot of "gnome 2.{12,14} is out since three month --
where are Fedora packages."
Just my 2 cent
CU
thl
2:23 p.m.
>
> Nice of y'all to allow yourself longer release cycles while denying it
> to fedora community developers.
Not fair--see below.
My dad used to say something about things not being fair....
Seth, you've actually answered your own question. Based on what
I have
seen inside of Red Hat, 6 months is a release cycle that matches well
the challenge of the problem with the nature and resources of the
present community.
*boggle*
Where are you getting this?
Even with the surprise 7 day delay, FC4 is great, as
was FC3 vs. the targets we all set.
For fedora CORE maybe - but there is Fedora Extras and there's A LOT of
infrastructure work to keep fedora from being completely manually
managed.
I even think that your suggestion
of a one-time-for-now 9 month cycle could make sense.
good.
But the stuff that's required to hit an 18 month target is just
Night And Day
different.
I wasn't recommending an 18 month target, I was saying that I thought
lengthening the fc devel cycle would help us get some things done that
we just haven't had the time to do.
It may look easy--copying and criticizing the decisions we
make is pretty easy stuff compared to sorting out the initial plan and
keeping enough of the contingencies viable that the release is relevant
by the time it sees daylight. I'm not saying that Red Hat is the only
one trying to make these guesses and trying to following them through to
their logical conclusion--there are companies and community efforts
alike that try this stuff every day. But I am saying that it's a
sufficiently difficult and resource-intensive task that it's Just Not
Fair to suggest that simple goal-setting will lead to simple goal
attainment. Running a marathon is hard, but running up up Mt. Everest
is a different ballgame, and pretending it's not is reckless.
You're damn right. So I guess you can understand why I'm a bit pissed at
being talked down to by you when I sat in a meeting 3 months ago about
the fedora extras buildsystem process and I was the only one who
volunteered to work on it. Why? B/c everyone else was too busy. Hell, I
was too busy, too but I wanted it to happen and it appeared that was the
only way it was GOING to happen.
Someone else set the objectives and I met them.
So get down off your high horse about "copying and criticizing". I don't
when, exactly, I get to stop paying dues but I think it needs to be
soon.
-sv
2:46 p.m.
On Sun, 2005-06-05 at 15:23 -0400, seth vidal wrote:
> But the stuff that's required to hit an 18 month target is
just Night And Day
> different.
I wasn't recommending an 18 month target, I was saying that I thought
lengthening the fc devel cycle would help us get some things done that
we just haven't had the time to do.
I may be totally off base here, but I think you misunderstood what
Michael was talking about.
I *think* he is referring to RHEL being on the 18 month target, which
means Fedora basically does 3 releases to meet the goals they set for
RHEL, which sort of is an 18 month target as well, or 3 *3 month*
targets to get it there?
*shrug*, just trying to help understand. So throw this email out the
window if it's not correct :P
--
Mike Chambers
Madisonville, KY
"Everything is difficult before it's easy!"
2:54 p.m.
I may be totally off base here, but I think you misunderstood what
Michael was talking about.
I *think* he is referring to RHEL being on the 18 month target, which
means Fedora basically does 3 releases to meet the goals they set for
RHEL, which sort of is an 18 month target as well, or 3 *3 month*
targets to get it there?
Last time I checked fedora does not ONLY meet goals that are set for
rhel. For further evidence of that look at fedora extras.
-sv
4:14 p.m.
On Sun, Jun 05, 2005 at 03:23:08PM -0400, seth vidal wrote:
You're damn right. So I guess you can understand why I'm a
bit pissed at
being talked down to by you when I sat in a meeting 3 months ago about
the fedora extras buildsystem process and I was the only one who
volunteered to work on it. Why? B/c everyone else was too busy. Hell, I
was too busy, too but I wanted it to happen and it appeared that was the
only way it was GOING to happen.
<hat color="red" mode="off">
Ahum, so there is a meeting about critical work needed for Fedora,
maybe I'm not in the right lists but I didn't see anything about it.
Is there public minutes from that meeting ? Are you trying to build
a community around this part of the work ? If it's done behind closed
doors, only the people within that meeting can really help getting it
done, and then of course it will take foreever if nobody can.
</hat>
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
4:17 p.m.
On Sun, 2005-06-05 at 17:14 -0400, Daniel Veillard wrote:
On Sun, Jun 05, 2005 at 03:23:08PM -0400, seth vidal wrote:
> You're damn right. So I guess you can understand why I'm a bit pissed at
> being talked down to by you when I sat in a meeting 3 months ago about
> the fedora extras buildsystem process and I was the only one who
> volunteered to work on it. Why? B/c everyone else was too busy. Hell, I
> was too busy, too but I wanted it to happen and it appeared that was the
> only way it was GOING to happen.
<hat color="red" mode="off">
Ahum, so there is a meeting about critical work needed for Fedora,
maybe I'm not in the right lists but I didn't see anything about it.
Is there public minutes from that meeting ? Are you trying to build
a community around this part of the work ? If it's done behind closed
doors, only the people within that meeting can really help getting it
done, and then of course it will take foreever if nobody can.
</hat>
the meeting was at red hat's HQ in raleigh.
-sv
6:48 p.m.
On Sun, 2005-06-05 at 15:23 -0400, seth vidal wrote:
> >
> > Nice of y'all to allow yourself longer release cycles while denying it
> > to fedora community developers.
>
> Not fair--see below.
My dad used to say something about things not being fair....
I get it that life's not fair. But you (and I) can be fair if we want
to.
> I even think that your suggestion
> of a one-time-for-now 9 month cycle could make sense.
good.
Heh--violent agreement.
> But the stuff that's required to hit an 18 month target is
just Night And Day
> different.
I wasn't recommending an 18 month target, I was saying that I thought
lengthening the fc devel cycle would help us get some things done that
we just haven't had the time to do.
OK. I misunderstood your proposal when you chose to quote off of
Daniel's message about 18 month. Had you continued from the 9 month
proposal, I would have continued reading, with interest. I apologize
for misinterpreting your intent.
[...] So I guess you can understand why I'm a bit pissed at
being talked down to by you when I sat in a meeting 3 months ago about
the fedora extras buildsystem process and I was the only one who
volunteered to work on it. Why? B/c everyone else was too busy. Hell, I
was too busy, too but I wanted it to happen and it appeared that was the
only way it was GOING to happen.
Someone else set the objectives and I met them.
You misinterpreted me. I was not talking about any shortcomings of the
work on Fedora Core or Extras. I was talking about the perception that
many people have about what it takes to hit an 18 month target. Since
that wasn't your intent, my point was irrelevant.
M
2:59 p.m.
OK. I misunderstood your proposal when you chose to quote off of
Daniel's message about 18 month. Had you continued from the 9 month
proposal, I would have continued reading, with interest. I apologize
for misinterpreting your intent.
I quoted Daniel's 18 month remark b/c I was feeling pissy and b/c he was
trying to counter my claim of red hat not having anything other than a 6
month release cycle to go on with rhel's release cycle, which I think is
a red herring for the discussion of fedora. I do not advocate an 18month
cycle for fedora, that'd be nuts and would defeat one of the reasons I
like using fedora, which is to know that it will run on recent/newer
hardware. All I'm arguing for is 3 extra months for the time b/t FC4 and
FC5 to give us some time to catch up on some items that need doing.
-sv
3:08 p.m.
On Sun, Jun 05, 2005 at 03:59:42PM -0400, seth vidal wrote:
I quoted Daniel's 18 month remark b/c I was feeling pissy and b/c
he was
trying to counter my claim of red hat not having anything other than a 6
month release cycle to go on with rhel's release cycle, which I think is
a red herring for the discussion of fedora.
Maybe the people really suggest a
branch for the work you are talking
about - without realizing that the work "has to" happen by FC5 because
the promise that it will happen by FC5 ended the one of the previous
rounds of flamewars.
Mirek
3:11 p.m.
On Sun, 2005-06-05 at 22:08 +0200, Miloslav Trmac wrote:
On Sun, Jun 05, 2005 at 03:59:42PM -0400, seth vidal wrote:
> I quoted Daniel's 18 month remark b/c I was feeling pissy and b/c he was
> trying to counter my claim of red hat not having anything other than a 6
> month release cycle to go on with rhel's release cycle, which I think is
> a red herring for the discussion of fedora.
Maybe the people really suggest a branch for the work you are talking
about - without realizing that the work "has to" happen by FC5 because
the promise that it will happen by FC5 ended the one of the previous
rounds of flamewars.
good point. :)
-sv
2:48 p.m.
Michael Tiemann wrote:
attainment. Running a marathon is hard, but running up up Mt.
Everest
is a different ballgame, and pretending it's not is reckless.
What a great analogy. I would suggest walking is safer and has a better
chance of reaching the summit and returning alive... And don't piss off
the Sherpas. :-p
OT: How does one outsider/dabbler know which specific rpm builds are
going into fc4 (or any official release) at any given point in time?
I'm in the middle of uncovering/reverting some unpleasant behaviour
introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2
build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was
in test3.
../C
9:58 p.m.
On Sun, 2005-06-05 at 12:48 -0700, Curtis Doty wrote:
OT: How does one outsider/dabbler know which specific rpm builds are
going into fc4 (or any official release) at any given point in time?
There's not a "good" way at the moment other than ask.
I'm in the middle of uncovering/reverting some unpleasant
behaviour
introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2
build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was
in test3.
3.08 is targeted at FC4. 3.07 was broken for a pretty large number of
laptops and 3.08 resolved those problems.
Jeremy
7:33 p.m.
On Sun, 2005-06-05 at 12:48 -0700, Curtis Doty wrote:
OT: How does one outsider/dabbler know which specific rpm builds are
going into fc4 (or any official release) at any given point in time?
Generally, one looks at rawhide.
I'm in the middle of uncovering/reverting some unpleasant
behaviour
introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2
build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was
in test3.
Have you made sure there's a bug filed in bugzilla? Or does "unpleasant
behaviour" mean it's not actually wrong, merely not what you expect?
--
Peter
3:02 p.m.
On Sun, Jun 05, 2005 at 07:07:21PM -0400, Michael Tiemann wrote:
attainment. Running a marathon is hard, but running up up Mt.
Everest
is a different ballgame, and pretending it's not is reckless.
Cute mixed-metaphor. :)
Seriously, though, assuming you mean Fedora is the marathon and the Mt.
Everest run is RHEL, the question is: do you *really* want outside help with
Fedora? Because the current 6 month schedule feels like running a marathon
every day to those of us not paid to devote all of our time to Fedora.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
6:13 a.m.
On Sun, Jun 05, 2005 at 12:30:35PM -0400, seth vidal wrote:
Nice of y'all to allow yourself longer release cycles while
denying it
to fedora community developers.
Nobody is denying it to anyone. If a project takes 3 years it takes 3 years
and at some point its ready to merge into distributions.
Its also worth remembering large parts of the RHEL release cycle would drive
most developers nuts because they consist of "justify that specific change",
"which bug id", "who signed this off", "you can't import the
current release
backport the change" ... not 'development'.
Alan
8:04 a.m.
On Mon, 2005-06-06 at 07:13 -0400, Alan Cox wrote:
On Sun, Jun 05, 2005 at 12:30:35PM -0400, seth vidal wrote:
> Nice of y'all to allow yourself longer release cycles while denying it
> to fedora community developers.
Nobody is denying it to anyone. If a project takes 3 years it takes 3 years
and at some point its ready to merge into distributions.
read the followup emails from this thread. I think you're
misunderstanding me.
-sv
10:08 a.m.
On Wed, 2005-06-01 at 16:44 -0700, Roland McGrath wrote:
To reiterate what Elliot said, the basic principle as I see it is
that we
endeavor for the current Fedora release always to have the newest stuff
that is reasonably stable. After some fairly short interval in the 3-6
month ballpark, *something* certainly has a newer and better version that
is reasonably stable. So more or less any time "rawhide has newer stuff",
then it's a good reason to have a Fedora Core release before too long. If
that sensation comes along, and there's something with a bleeding edge
that's still too bloody, then that something can roll back to the stable
version until the next FC release. It won't be too long.
The problem is that we have significant amounts of things that *DON'T*
have an upstream other than Fedora, and so if we want to get things done
for them, we have to work within Fedora. And they're components that we
can't just "skip" changing for a release.
Jeremy
7:55 p.m.
Hi,
> Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
> > What about stretching out the dev cycle from 3months dev + 3 months of
> > testing to something more like 6 months of dev + 3 months of testing.
>
> How about deciding what the major goals of the next release should be
> (within reason of course), estimating about how long it should take to
> meet those goals, and then add in whatever else seems reasonable in the
> given time frame?
Because the decision was explicitly made when the Fedora project started
to do releases at regular intervals rather than based on feature-driven
milestones. This is the model Gnome has used with a good bit of success.
I disagree with the request for stretching, and agree with the
comparison with GNOME's model. Look at how Sarge went down.
In contrast, I'd like to propose another idea - keep FC (x-2) alive
until a month after FC (x) comes out. This would make people feel they
don't need to upgrade every six months, but can do it every year, if
they feel it is a real issue. I find it a little silly how currently FC
(x - 2) gets eol'd around the time FC (x) is starting to churn out test
releases.
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Don't shut your eyes just yet
Don't even open your mouth just yet
Because there's things you've got to see
There's things you won't believe of me
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
7:45 a.m.
Am Donnerstag, den 02.06.2005, 02:55 +0200 schrieb Thomas Vander
Stichele:
> > Once upon a time, seth vidal <skvidal(a)phy.duke.edu>
said:
> > > What about stretching out the dev cycle from 3months dev + 3 months of
> > > testing to something more like 6 months of dev + 3 months of testing.
> >
> > How about deciding what the major goals of the next release should be
> > (within reason of course), estimating about how long it should take to
> > meet those goals, and then add in whatever else seems reasonable in the
> > given time frame?
>
> Because the decision was explicitly made when the Fedora project started
> to do releases at regular intervals rather than based on feature-driven
> milestones. This is the model Gnome has used with a good bit of success.
I disagree with the request for stretching, and agree with the
comparison with GNOME's model. Look at how Sarge went down.
In contrast, I'd like to propose another idea - keep FC (x-2) alive
until a month after FC (x) comes out. This would make people feel they
don't need to upgrade every six months, but can do it every year, if
they feel it is a real issue. I find it a little silly how currently FC
(x - 2) gets eol'd around the time FC (x) is starting to churn out test
releases.
++
If fedora-legacy [cw]ould provide updates at the usual place for
fedora-core updates this might not me needed.
8 a.m.
On Thu, Jun 02, 2005 at 02:55:59AM +0200, Thomas Vander Stichele wrote:
I disagree with the request for stretching, and agree with the
comparison with GNOME's model. Look at how Sarge went down.
Seth's not proposing an indefinite "stretching". Just a longer expected
timeframe -- still *very* short.
In contrast, I'd like to propose another idea - keep FC (x-2)
alive
until a month after FC (x) comes out. This would make people feel they
This proposal is approximately the same timeframe per release, except it
requires Fedora developers to support more releases at once.
don't need to upgrade every six months, but can do it every year,
if
they feel it is a real issue. I find it a little silly how currently FC
(x - 2) gets eol'd around the time FC (x) is starting to churn out test
releases.
There's a reason for that -- it lets the developers focus on the new
instead of the much less interesting and exciting drudgery of maintaining
the old releases.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 76 degrees Fahrenheit.
12:33 p.m.
On Thu, Jun 02, 2005 at 02:55:59AM +0200, Thomas Vander Stichele wrote:
Hi,
> > Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
> > > What about stretching out the dev cycle from 3months dev + 3 months of
> > > testing to something more like 6 months of dev + 3 months of testing.
> >
> > How about deciding what the major goals of the next release should be
> > (within reason of course), estimating about how long it should take to
> > meet those goals, and then add in whatever else seems reasonable in the
> > given time frame?
>
> Because the decision was explicitly made when the Fedora project started
> to do releases at regular intervals rather than based on feature-driven
> milestones. This is the model Gnome has used with a good bit of success.
I disagree with the request for stretching, and agree with the
comparison with GNOME's model. Look at how Sarge went down.
In contrast, I'd like to propose another idea - keep FC (x-2) alive
until a month after FC (x) comes out. This would make people feel they
don't need to upgrade every six months, but can do it every year, if
they feel it is a real issue. I find it a little silly how currently FC
(x - 2) gets eol'd around the time FC (x) is starting to churn out test
releases.
Concurrently supporting 3 releases at the same time is already painful
enough. The ability to drop the oldest release once the next test series
is well underway really helps gather momentum to getting that next
release out the door. Being stuck doing errata for older releases kills
you, especially on larger packages.
We decided long ago that keeping all the releases on the same revision
of the kernel was the only way to stay sane and keep on top of bugs
across three releases. However, this adds an additional burden onto
other developers when upstream breaks compatibility with something
or other, and random bits of userspace need updating.
Stretching out the support for older releases means we have to put
more effort into doing this, or spend more effort backporting
cherry-picked patches (hint: at ~4000 changesets a month upstream, this
isn't going to happen).
The only other two alternatives are dropping support for the oldest
release when the time comes, (ie, what we do now) , or just not doing
updates for anything non-critical. This sounds feasible, but still
gets you into the nightmare of having to cherry-pick and backport
patches, and judging from comments in bugzilla when we've done
similar things in the past, users tend not to like having their
bugs closed with 'not critical, upgrade to the next release'.
Dave
12:10 a.m.
Because the decision was explicitly made when the Fedora project
started
to do releases at regular intervals rather than based on feature-driven
milestones. This is the model Gnome has used with a good bit of success.
It avoids the Debian "work on it for three years until it's perfect"
syndrome, because as this thread is already showing, everyone wants "just
a little bit longer" to get their pet feature just right.
You'll note I didn't say drag it on ad infinitum, nor did I say we
should make it stay that length of time permanently. I said for the next
release make it a specifically longer length of time to do development
work in.
That's all. I'm saying that I think there is room to discuss a different
timeline other than the 'every 6 months, release' timeline and I think
that given the tasks set ahead for FC5 that I've heard batted around
over the last N months that it would be worthwhile to lengthen the time
for development for this release.
-sv
7:49 p.m.
On Wed, 2005-06-01 at 16:31 -0400, seth vidal wrote:
What about stretching out the dev cycle from 3months dev + 3 months
of
testing to something more like 6 months of dev + 3 months of testing.
That will remove (or at least alleviate to some degree) one of the major
reasons some people are currently avoiding Fedora.
--
Florin Andrei
http://florin.myip.org/
9:20 p.m.
On Wednesday 01 June 2005 19:49, Florin Andrei wrote:
On Wed, 2005-06-01 at 16:31 -0400, seth vidal wrote:
> What about stretching out the dev cycle from 3months dev + 3 months of
> testing to something more like 6 months of dev + 3 months of testing.
That will remove (or at least alleviate to some degree) one of the major
reasons some people are currently avoiding Fedora.
What would alleviate it more is
if one could upgrade Fedora versions via yum
easily. I understand that's not always possible, but if you've kept to FC and
extras, it would be great for that to be an option
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
12:14 a.m.
On Wed, 2005-06-01 at 21:20 -0500, Richard June wrote:
What would alleviate it more is if one could upgrade Fedora versions
via yum
easily. I understand that's not always possible, but if you've kept to FC and
extras, it would be great for that to be an option
for many cases in the recent past it has been doable, but not
necessarily supported.
the reality is that the number of things changed in a major way make it
difficult.
FC1->FC2 was selinux and the kernel version change
FC2->FC3 was lvm2 and udev
-sv
10:29 a.m.
On Thursday 02 June 2005 12:14 am, seth vidal wrote:
On Wed, 2005-06-01 at 21:20 -0500, Richard June wrote:
> What would alleviate it more is if one could upgrade Fedora versions via
> yum easily. I understand that's not always possible, but if you've kept
> to FC and extras, it would be great for that to be an option
for many cases in the recent past it has been doable, but not
necessarily supported.
It's always doable if you want to put forth that kind of
effort.
the reality is that the number of things changed in a major way make
it
difficult.
FC1->FC2 was selinux and the kernel version change
FC2->FC3 was lvm2 and udev
and rh9 to fc1 was this or that. I understand that
major stuff has changed
with every release, but if, as an end user, I could be reasonably sure that I
could install the latest fedora-release, yum update, reboot, and I have a the
latest version of fedora, that would be a happy thing
Most likely this will *never* be a supported thing. nobody wants to deal with
it, but if we could work towards being able to jump from FC(X - 1) to FC(X)
like that, it would be a nicety even if the requirements are, FC and extras
only. how difficult would it be to enable selinux or udev on a migration? LVM
is an install time option only, I understand that. but some things don't
strike me as being too far outside the realm of reason.
This "reinstall every six months" kinda sucks ya know.
10:50 a.m.
On 6/2/05, Richard June <rjune(a)bravegnuworld.com> wrote:
Most likely this will *never* be a supported thing. nobody wants to
deal with
it, but if we could work towards being able to jump from FC(X - 1) to FC(X)
like that, it would be a nicety even if the requirements are, FC and extras
only. how difficult would it be to enable selinux or udev on a migration?
There are going to always be a class of low level technology changes
that require you to you be using an already updated kernel/library
environment to correctly configure them. You either provide a target
environment to do this in like anaconda's update facility does..or to
make live upgrades work you'd have to do your live upgrade in
stages... with multlple reboots with specialized boottime config
options for some of the reboots. Fragile.
LVM
is an install time option only, I understand that. but some things don't
strike me as being too far outside the realm of reason.
This "reinstall every six months" kinda sucks ya know.
anaconda has an upgrade option.... and from discussion you know there
is a long term goal to make it repository aware. How about we focus
community effort on making the anaconda upgrade process work better..
instead of jumping over to a more fragile live upgrade process that
will still require a reboot or two. For example you can boot into
the anaconda installer environment via grub entry with vnc access
enabled. How about you focus on making it easy for upgraders to set
that up.. instead of re-inventing the live upgrade process that we
know is going to have problems in some situations because of low level
technology shifts.
-jef
3:41 p.m.
On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
I'd like to see a summary of known 'plans' from each of the designated
subprojects listed on fedora's website. Random Feature requests are
nice.... a more general understanding of where each subproject
momentum is headed to provide scope for potential contributors would
be nicer.
Near-term plans, ie "crap I know, you know, that I know, that you know
you are planning on implementing for fc5 as a lead core developer".
that as well as speculative on the horizon items that aren't going to
be completed in time for fc5 but could use some experimental love in
the meantime.
-jef"And i want that summary in a theora video diary format"spaleta
10:09 a.m.
On Wed, 2005-06-01 at 16:41 -0400, Jeff Spaleta wrote:
On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
I'd like to see a summary of known 'plans' from each of the designated
subprojects listed on fedora's website. Random Feature requests are
nice.... a more general understanding of where each subproject
momentum is headed to provide scope for potential contributors would
be nicer.
I'm actually planning on doing this for anaconda... I've already started
doing some writing of things, but the whole pressure of getting a
release out has kept me from getting to it until now ;)
Stay tuned...
Jeremy
10:14 a.m.
Jeremy Katz wrote:
On Wed, 2005-06-01 at 16:41 -0400, Jeff Spaleta wrote:
>On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
>
>
>>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
>>Extras 5 - what major features are you willing to put effort into?
>>
>>
>I'd like to see a summary of known 'plans' from each of the designated
>subprojects listed on fedora's website. Random Feature requests are
>nice.... a more general understanding of where each subproject
>momentum is headed to provide scope for potential contributors would
>be nicer.
>
>
I am working on this too. I still have to gather a few things. I will
post further updates when something substantial is done
regards
Rahul
4:09 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
We should ship a GCC 4.1 preview compiler so we can continue to
demonstrate improvements on the java front.
Most of the improvements of late imply ABI breakage because we're
extending the library in incompatible ways. Restricting ourselves to
non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to
demonstrate innovation.
I also blogged about my personal ideas for java in FC5 recently,
reproduced below.....
Fedora Core 4 is getting close to “done", and I think it’s safe to say
that we hit the Free java trifecta in this release: OpenOffice.org 2,
the Eclipse IDE, and Apache Tomcat. Congratulations to everybody who
made this possible! But what next? FC5 is right around the corner…
My personal wish list is as follows: gcjwebplugin, Azureus and RSSOwl.
Michael Koch’s gcjwebplugin is important for obvious reasons. I’m less
worried about the GUI work here than the security work. I’d rather see
us ship a secure plugin that could only run a handful of applets than
nothing at all. Let’s put security work ahead of AWT/Swing.
Azureus is a wildly popular and innovative cross-platform and extensible
bittorrent client. It seems to be a permanent fixture on the Most Active
and Top Downloaded lists at sourceforge.net (#1 on both this week).
There are lots of plugins for it, including some to let it act as a
powerful podcasting client (which is where my interest lies). It uses
SWT and almost runs out of the box on gcj today. I posted a screenshot
of it stumbling along on gcj about 6 months ago. The current release
fails to run for a number of reasons, including their use of com.sun.*
classes for secure sockets. This is a common problem (witness
OpenOffice.org) and Sven de Marothy has been maintaining a nice page to
help educate people on writing portable code. We need to promote this
better.
Like Azureus, RSSOwl is an SWT based app that almost runs today. It’s a
popular and well reviewed RSS feed reader. Sven de Marothy and Robin
Green (no relation, btw) have both reported some success running on
gcj.
Azureus and RSSOwl are real success stories that complement the current
Fedora Core/Extras offerings. My recent experience with the jogl and
lwjgl communities tells me that project maintainers are willing to put
work into getting their projects working with Free runtimes. We need to
engage the Azureus and RSSOwl developer communities to see if they are
willing to help make this all possible.
I also wonder what the base compiler for FC5 will be. My guess at the FC
and GCC schedules make me think that we could be using GCC 4.1, which
would be nice. But 4.0.x is also possible. We should suss this out ASAP
as it impacts how we go about getting these apps running.
Well, this is all just my personal opinion - but I think it’s all
possible. I hope I can convince everybody else!
AG
4:15 p.m.
Anthony Green (green(a)redhat.com) said:
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
We should ship a GCC 4.1 preview compiler so we can continue to
demonstrate improvements on the java front.
What good is demonstrating improvement if we can't use it any
apps because the ABI is moving too fast and it's not
released yet? (I'm serious.)
Bill
8:36 p.m.
On Wed, 2005-06-01 at 17:15 -0400, Bill Nottingham wrote:
Anthony Green (green(a)redhat.com) said:
> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> > Extras 5 - what major features are you willing to put effort into?
>
> We should ship a GCC 4.1 preview compiler so we can continue to
> demonstrate improvements on the java front.
What good is demonstrating improvement if we can't use it any
apps because the ABI is moving too fast and it's not
released yet? (I'm serious.)
But we would use it in apps. I'm suggesting that java-gcj-compat refer
to gij41 and friends (like it used to refer to gij4 in the early days of
FC4 development).
AG
5:21 p.m.
On Wed, 01 Jun 2005 14:09:06 -0700, Anthony Green wrote:
Most of the improvements of late imply ABI breakage because
we're
extending the library in incompatible ways. Restricting ourselves to
non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to
demonstrate innovation.
Could you elaborate on that? In a private email exchange recently Tom
Tromey suggested that the ABI was stable (or very nearly stable) in that
apps compiled with GCJ 4.0 would run against a 4.1 system (but not
vice-versa unfortunately).
I'm afraid I'm also really convinced that breaking ABI constitutes
innovation, or even is required for it ... it's a clone of Java so at most
you would be adding new APIs which hopefully the ABI design allows for?
I'm interested in this because I'm working with a guy who wishes to
distribute GCJ compiled binaries across multiple Linux distributions.
Obviously if you guys are chomping at the bit to break backwards
compatibility as soon as possible, I'll have to tell him to give it up (or
figure out some cunning hack where everything including libgcj is
statically linked/private).
thanks -mike
8:01 p.m.
>>>> "Mike" == Mike Hearn <mike(a)navi.cx>
writes:
> On Wed, 01 Jun 2005 14:09:06 -0700, Anthony Green wrote:
> Most of the improvements of late imply ABI breakage because we're
> extending the library in incompatible ways. Restricting ourselves to
> non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to
> demonstrate innovation.
Mike> Could you elaborate on that? In a private email exchange recently Tom
Mike> Tromey suggested that the ABI was stable (or very nearly stable) in that
Mike> apps compiled with GCJ 4.0 would run against a 4.1 system (but not
Mike> vice-versa unfortunately).
Yes. There are 2 ABIs, and you are talking about one (the binary
compatibility ABI, aka BC ABI) while Anthony is talking about the
other one (the "C++" ABI).
Our current rule for hacking libgcj in the GCC tree is that we don't
break the C++ ABI in a minor release. This is a very strict rule, it
means we can't do things like add new non-static methods (we can add
new classes and other things like that though).
While the new BC ABI is fairly solid, we put off really promising
long-term binary compatibility until GCC 4.1, on the theory that we
might have overlooked something. And sure enough we found a couple of
bugs after shipping; but it turns out we can fix these without
breaking existing (4.0-compiled) binaries.
Mike> I'm afraid I'm also really convinced that breaking ABI
Mike> constitutes innovation, or even is required for it ... it's a
Mike> clone of Java so at most you would be adding new APIs which
Mike> hopefully the ABI design allows for?
Yeah, the new ABI was made precisely so we could make all the changes
to libgcj that we might need to make, while not breaking any existing
binaries. The idea being that at some point (4.1 is our target) we
can just make the BC ABI the default one and only promise that we
won't break it, and let the C++ ABI break constantly.
One option for FC5 would be to go ahead and update libgcj.
All the BC-compiled code would still work.
Mike> I'm interested in this because I'm working with a guy who wishes to
Mike> distribute GCJ compiled binaries across multiple Linux distributions.
Should be ok as long as you pick a consistent required base version,
and compile everything BC.
Tom
1:13 a.m.
On Wed, 01 Jun 2005 19:01:58 -0600, Tom Tromey wrote:
Yes. There are 2 ABIs, and you are talking about one (the binary
compatibility ABI, aka BC ABI) while Anthony is talking about the
other one (the "C++" ABI).
Hmm, interesting! OK, so you can choose which ABI your binary uses at
compile time? When would you ever *not* want the BC ABI?
Oh, wait, or is this for using the libgcj objects from actual C++ code
using CNI?
thanks -mike
11:27 a.m.
>>>> "Mike" == Mike Hearn <mike(a)navi.cx>
writes:
> Yes. There are 2 ABIs, and you are talking about one (the
binary
> compatibility ABI, aka BC ABI) while Anthony is talking about the
> other one (the "C++" ABI).
Mike> Hmm, interesting! OK, so you can choose which ABI your binary uses at
Mike> compile time? When would you ever *not* want the BC ABI?
Mike> Oh, wait, or is this for using the libgcj objects from actual C++ code
Mike> using CNI?
The C++ ABI has better performance. And, at the moment, CNI only
works with the C++ ABI. The tradeoff is that the C++ ABI is not
perfectly "java like", and so in general you have to modify your
application to work properly with it.
The reason we haven't yet made the BC ABI the default is that it is
new, and also you can't yet compile directly from .java using this
ABI; you must go via .class, which is a bit too broken for a default.
Tom
4:11 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
I think continuing the migration of misc items to extras and making core
truly core is good.
I'd be willing to work toward:
- extras organization into package groups or even sub-repos
- stripping of core of any program that provides duplicate
functionality to another program.
- making the barrier to use of extras VERY low.
-sv
4:15 p.m.
seth vidal (skvidal(a)phy.duke.edu) said:
I think continuing the migration of misc items to extras and making
core
truly core is good.
I'd be willing to work toward:
- extras organization into package groups or even sub-repos
Including extending this to CD grouping? (I should write up
the strawman proposal for this.)
Bill
4:20 p.m.
On Wed, 2005-06-01 at 17:15 -0400, Bill Nottingham wrote:
seth vidal (skvidal(a)phy.duke.edu) said:
> I think continuing the migration of misc items to extras and making core
> truly core is good.
>
> I'd be willing to work toward:
> - extras organization into package groups or even sub-repos
Including extending this to CD grouping? (I should write up
the strawman proposal for this.)
Yah - I think it should. Although I tell you what I'd like - I think
making it easy for users to make their own 'extras' cds that include the
stuff they want + deps would make the most sense.
you tell a program a list of packages you want and it compiles a list of
that package + all its deps from extras and puts them in cd-sized
subdirs.
that would take some sorting work but it's not outside the realm of
possibility.
-sv
4:44 p.m.
ons, 01.06.2005 kl. 23.11 skrev seth vidal:
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
>
I think continuing the migration of misc items to extras and making core
truly core is good.
I'd be willing to work toward:
- extras organization into package groups or even sub-repos
- stripping of core of any program that provides duplicate
functionality to another program.
- making the barrier to use of extras VERY low.
-sv
What about making it possible for non-text users to use yum? They
shouldn't be kept out of such a great tool :)
BTW., how does osx do installs (just bringing up the meta-file installer
thingy again. Feel free not to answer)?
4:46 p.m.
>
What about making it possible for non-text users to use yum? They
shouldn't be kept out of such a great tool :)
it's a work-in-progress.
BTW., how does osx do installs (just bringing up the meta-file
installer
thingy again. Feel free not to answer)?
their package system, umm, err, sucks.
a lot.
-sv
5:15 p.m.
On Wed, 01 Jun 2005 17:46:33 -0400, seth vidal wrote:
> BTW., how does osx do installs (just bringing up the meta-file
> installer thingy again. Feel free not to answer)?
their package system, umm, err, sucks.
99.9% of users seem to disagree with you, judging by how often "Linux
should use appfolders like Macs do" is heard on various forums and mailing
lists.
MacOS X packaging works reliably for end users, 100% of the time, and
from that perspective it doesn't matter how many features it has or
doesn't have, it's better than yum/rpm/any Linux packaging system.
I don't mean any offence to you by the way, yum is a nice piece of work
and I'd agree that the way Apple did appfolders is pretty awful
(launchservices? hello obscure bugs and security holes!) but we shouldn't
use that poor implementation to ignore users experiences.
thanks -mike
7:51 p.m.
99.9% of users seem to disagree with you, judging by how often
"Linux
should use appfolders like Macs do" is heard on various forums and mailing
lists.
Probably because seem to think that the appfolder way is the thing that
would automatically solve people's install problems on Linux, but ...
MacOS X packaging works reliably for end users, 100% of the time,
and
from that perspective it doesn't matter how many features it has or
doesn't have, it's better than yum/rpm/any Linux packaging system.
... in reality the problem is not because of rpm/... vs. appfolders, the
"problem" is that there is only ONE MacOSX and there are several linux
distro's. People need to learn to treat, say, Fedora + extras as ONE
distro, and only install from there, and their problem is solved.
If they don't, then appfolders won't help them either - they will end up
installing appfolders that conflict with their distro and were actually
intended for another distro.
In short, what people who say "linux should use appfolders like ..."
mean is "please solve my install problems" which in practice would
translate to "please have only 1 linux".
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Please put me somewhere near the sea
With one carrion angel waiting for me
who'll be holding my heart in it's hand
But most of all I'd like to go with a friend
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
1:17 p.m.
On Thu, 02 Jun 2005 02:51:34 +0200, Thomas Vander Stichele wrote:
In short, what people who say "linux should use appfolders like
..."
mean is "please solve my install problems" which in practice would
translate to "please have only 1 linux".
Sounds good to me. Too bad the LSB sort of wandered off into the haze,
what we really need is some freedesktop.org equivalent for distributions.
There's no fundamental reason why packages have to be incompatible, a lot
of times the differences are different merely through being apart.
But yeah, I agree that people translate "I want things to be easy" into "I
want it to be like on the Mac" internally. That's not necessarily a faulty
line of thinking though.
thanks -mike
1:24 p.m.
Hi
But yeah, I agree that people translate "I want things to be easy" into "I
want it to be like on the Mac" internally. That's not necessarily a faulty
line of thinking though.
No. its not a faulty line of thinking but the Mac solution is based on
the assumption of a monolithic platform. We can produce something
similar with a integrated release structure. we have bits and pieces of
that in GNOME and elsewhere. More bits like a freedesktop.org platform
and packaging guidelines and naming conventions shared across
distributions would help get similar functionality in Fedora but its a
big process and not everyone is very keen on seeing that happen
unfortunately
regards
Rahul
2 p.m.
Le jeudi 02 juin 2005 à 19:17 +0100, Mike Hearn a écrit :
On Thu, 02 Jun 2005 02:51:34 +0200, Thomas Vander Stichele wrote:
> In short, what people who say "linux should use appfolders like ..."
> mean is "please solve my install problems" which in practice would
> translate to "please have only 1 linux".
Sounds good to me. Too bad the LSB sort of wandered off into the haze,
what we really need is some freedesktop.org equivalent for distributions.
There's no fundamental reason why packages have to be incompatible, a lot
of times the differences are different merely through being apart.
We don't have the ressources for the "one linux model"
The linux progress rate is so high because a lot of stuff is loosely
coupled, so people can work on what they care about in parallel, syncing
only now and then.
Hell, even Microsoft does not have the ressources for the "one windows"
model. And they have lots of $$$, and scale a lot less in all
directions.
--
Nicolas Mailhot
3:02 p.m.
On Thu, 02 Jun 2005 21:00:42 +0200, Nicolas Mailhot wrote:
We don't have the ressources for the "one linux model"
Given that reducing duplication would increase resources, I don't see why
not.
Look at it like this. Before the freedesktop.org efforts, KDE and GNOME
didn't play so well together. There were two choices ahead of the
community:
1) Tell users not to use KDE apps in GNOME or GNOME apps in KDE. If stuff
breaks, it's their own fault, in other words
2) Standardise
Fortunately, the desktop developers did 2 and now users benefit. Even
better, the whole community benefits because people aren't pointlessly
cloning each others apps anymore (well, not as much). Useful bits of code
like the GtkQt theming engine fill in the bits that are easier to code
than standardise.
Right now for packaging you guys are choosing path (1). But it's worse
than with desktops: there it was only really KDE vs GNOME, but here it's
Fedora vs Ubuntu vs Gentoo vs Mandrake vs SUSE and so on. So the
duplication of effort and cloning of each others work is much worse.
In other words, Thomas is right, we need "1 Linux". Not one distro, but
one set of standards people can write packages and installers to.
thanks -mike
3:20 p.m.
On Thu, 2005-06-02 at 21:02 +0100, Mike Hearn wrote:
On Thu, 02 Jun 2005 21:00:42 +0200, Nicolas Mailhot wrote:
> We don't have the ressources for the "one linux model"
Given that reducing duplication would increase resources, I don't see why
not.
Right now for packaging you guys are choosing path (1). But it's
worse
than with desktops: there it was only really KDE vs GNOME, but here it's
Fedora vs Ubuntu vs Gentoo vs Mandrake vs SUSE and so on. So the
duplication of effort and cloning of each others work is much worse.
Getting people to the table for packaging architecture stack is going to
be hard. I'm certainly happy to talk to people, but there has to be
serious enough interest on all sides.
As far as the packaging cf freedesktop stuff goes, I spoke with some
people a while back on this front. With fd.o
a) the wheel was getting reinvented
b) each party's implementation had something the other lacked and vice
versa
c) doing it within each project was causing integration issues
Certainly you could argue similarly for packaging.
In other words, Thomas is right, we need "1 Linux". Not one
distro, but
one set of standards people can write packages and installers to.
Theoretically we have that with LSB packages but that's not the reality.
If you are arguing for get people talking fine - point me at the list.
The metadata list had some cross distribution interest and it's still
ticking along, but keeping people co-operating is the hard one.
The main obstacles are going to be convincing people that having shared
components makes their life better. Some parts of the packaging fit
into this, but it'll take some time.
So point me at the list.
Paul
6:20 p.m.
On Thu, 02 Jun 2005 16:20:09 -0400, Paul Nasrat wrote:
Getting people to the table for packaging architecture stack is going
to
be hard. I'm certainly happy to talk to people, but there has to be
serious enough interest on all sides.
OK, I'm really glad to hear that.
Right now there is no such freedistro.org list. The idea has been kicked
around before, but nobody seriously stepped up to do it.
Rather than focus purely on packaging standards, I think it'd be better
for such a group to eliminate pointless differences between distributions
by producing a series of informal RFC type documents. I am meaning
differences like some distros supporting /etc/profile.d and others not, or
using different locations for LinuxThreads, or different ways of parallel
installing libpng.
That makes it easier to build packages that install anywhere reliably.
Attempting to de-jure standardise some packaging technology probably won't
go anywhere, the LSB tried that and it didn't work out too well. But by
smoothing out distro differences, making "standard" packages becomes a lot
simpler.
If there is genuine interest in this, I'll bump it much nearer the top of
my priority list. I don't mind trying to kick start such a forum, though
I'd appreciate the thoughts of Havoc Pennington on this though. I think
freedesktop.org just kind of grew out of the EWMH effort, but I wasn't
around at that time.
thanks -mike
6:32 p.m.
On Fri, 2005-06-03 at 00:20 +0100, Mike Hearn wrote:
Rather than focus purely on packaging standards, I think it'd be better
for such a group to eliminate pointless differences between distributions
by producing a series of informal RFC type documents. I am meaning
differences like some distros supporting /etc/profile.d and others not, or
using different locations for LinuxThreads, or different ways of parallel
installing libpng.
Well, I did spend a lot of sweat trying to just get the libpng
maintainers to eliminate that particular problem back when the problem
appeared ;-) which would have been easier!
If there is genuine interest in this, I'll bump it much nearer
the top of
my priority list. I don't mind trying to kick start such a forum, though
I'd appreciate the thoughts of Havoc Pennington on this though. I think
freedesktop.org just kind of grew out of the EWMH effort, but I wasn't
around at that time.
What do you want my thinking on? freedesktop.org was not really based on
EWMH, that I can remember. I started it by writing the mission
statement:
http://freedesktop.org/wiki/MissionStatement
well, maybe it's been edited a bit over the years, I don't know. But it
was roughly like that always.
Havoc
7:52 p.m.
On Thu, 02 Jun 2005 19:32:15 -0400, Havoc Pennington wrote:
What do you want my thinking on? freedesktop.org was not really based
on
EWMH, that I can remember. I started it by writing the mission
statement:
http://freedesktop.org/wiki/MissionStatement
well, maybe it's been edited a bit over the years, I don't know. But it
was roughly like that always.
Well, to be honest, I'm not sure how to start. A website and a mailing
list is fine, but you have to get the right people involved and sometimes
they aren't so visible. I guess for KDE/GNOME that wasn't an issue but
distro developers, especially for SUSE, can be quite hard to track down.
And obviously there has to be something to work on ... some simple things
that can be agreed on easily to get it up and running. I threw out some
ideas there but there might be others that are more important. For one I'd
love everyone to standardise on using pam_xauth, as then ISVs could just
assume su works with X correctly instead of having tons of crappy hacks
like now. But that may be asking a bit much.
There's also the issue of being seen to be competing with the LSB. But I'm
not sure anybody would really care about that.
thanks -mike
3:34 p.m.
Le jeudi 02 juin 2005 à 21:02 +0100, Mike Hearn a écrit :
On Thu, 02 Jun 2005 21:00:42 +0200, Nicolas Mailhot wrote:
> We don't have the ressources for the "one linux model"
Given that reducing duplication would increase resources, I don't see why
not.
Reducing duplication will increase the synchronisation burden. Even the
Linux kernel uses the parallel tree development model, and it has almost
no dependencies to speak of.
--
Nicolas Mailhot
3:57 a.m.
Hi,
In other words, Thomas is right, we need "1 Linux". Not one
distro, but
one set of standards people can write packages and installers to.
Just to clarify - I do not actually feel that we need "1 linux". I'm
just saying that the reason things aren't as easy as on mac is because
there is not just "1 linux". Personally, I'm completely fine with linux
being a thriving ecosystem, and for daily use I stick to using Fedora +
extras, knowing that this is a window on the larger ecosystem that Just
Works.
So what I'm saying is that user should choose their own "1 linux", be it
fedora, ubuntu, suse, .... and live within the boundaries of that. I
personally feel that homogenizing distros to the point where they're
pretty much the same is a bad thing - I like how stuff gets fed back
between distros and how some distros have different focus points and the
good approaches tend to end up in all of them.
In reality, Mac is not just "1 os" either, there's still plenty of
people working on macos8, 9, ...
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
"Two million women and only one Flasheart..."
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
4:20 p.m.
On Fri, 03 Jun 2005 10:57:46 +0200, Thomas Vander Stichele wrote:
So what I'm saying is that user should choose their own "1
linux", be it
fedora, ubuntu, suse, .... and live within the boundaries of that.
Well, I don't really mind a thriving ecosystem of distros, but I feel
that this is like saying users should live within the boundaries of their
desktop and never run apps that don't use their preferred toolkit. That's
needlessly limiting and hurts developers and end users alike.
I don't think standardisation would seriously modify most distros. KDE is
still KDE and GNOME is still GNOME even though they share some
infrastructure these days. Most of the things that were standardised
weren't obviously better or worse in either desktop. It'd be the same for
distributions.
thanks -mike
6:35 p.m.
On Fri, 2005-06-03 at 10:57 +0200, Thomas Vander Stichele wrote:
Hi,
> In other words, Thomas is right, we need "1 Linux". Not one distro, but
> one set of standards people can write packages and installers to.
Just to clarify - I do not actually feel that we need "1 linux". I'm
just saying that the reason things aren't as easy as on mac is because
there is not just "1 linux". Personally, I'm completely fine with linux
being a thriving ecosystem, and for daily use I stick to using Fedora +
extras, knowing that this is a window on the larger ecosystem that Just
Works.
Yes, and this is exactly the thing that makes Linux being Linux.
Otherwise there are plenty of other operating systems which do it the
"one way" style.
So please, if you want to have only one Linux, choose another operating
system and don't take the choice from us.
P.S. I don't think there shouldn't be more standards here or there, but
generaly the idea of only one Linux takes the essential point of Linux
existence away.
--
Tomas Mraz <tmraz(a)redhat.com>
7:46 a.m.
On Wed, 01 Jun 2005 23:15:54 +0100, Mike Hearn <mike(a)navi.cx> wrote:
On Wed, 01 Jun 2005 17:46:33 -0400, seth vidal wrote:
> > BTW., how does osx do installs (just bringing up the meta-file
> > installer thingy again. Feel free not to answer)?
>
> their package system, umm, err, sucks.
99.9% of users seem to disagree with you, judging by how often "Linux
should use appfolders like Macs do" is heard on various forums and
mailing
lists.
MacOS X packaging works reliably for end users, 100% of the time, and
from that perspective it doesn't matter how many features it has or
doesn't have, it's better than yum/rpm/any Linux packaging system.
This is something I've thought about: how much would the shell slow down
if we had a very long $PATH, so that we can give applications independent
bin directories?
I love my Mac Mini but I find the 'Applications' item in the finder to be
a painful way to find and run applications: I find myself using the dock
very little, and I greatly prefer the 'Start' button on Windows and the
imitations thereof under Unix.
A downside to giving each app a directory is that it's harder to use
partitions to isolate different kind of things, an art that I've been
learning over time (and particular inspired by the Solaris shop I work
with that uses something much like LVM, allocate a minimal amount of
space for each partition, leave a large free pool, and grow the
partitions online over tine)
4:34 p.m.
On Thu, 2005-06-02 at 08:46 -0400, Paul A. Houle wrote:
> MacOS X packaging works reliably for end users, 100% of the
time, and
> from that perspective it doesn't matter how many features it has or
> doesn't have, it's better than yum/rpm/any Linux packaging system.
>
This is something I've thought about: how much would the shell slow down
if we had a very long $PATH, so that we can give applications independent
bin directories?
The bigger issue is likely to be limited size in which to store the
data. ISTR you get a page or something like that to put environmental
data in during exec(). Kernel guys correct me, I'm sure it's bigger
than that but totally fuzzy on the details.
Anyway, you might do better by making some way to marking "this file
here needs to be made into program named 'foo' in the (user/admin)
default path" in the package, or in a file at a well known location.
Sort of like how pkg-config tells you how to link against a library.
Then you can separate out the responsibility of how to make it
executable, and have something that knows about the distro's policy do
the work of making it available (whether by symlink, copy, hardlink,
etc). This could be during package install, or at boot time, or in an
initscript when starting some particular service.
[...]
A downside to giving each app a directory is that it's harder to use
partitions to isolate different kind of things, an art that I've been
learning over time (and particular inspired by the Solaris shop I work
with that uses something much like LVM, allocate a minimal amount of
space for each partition, leave a large free pool, and grow the
partitions online over tine)
You could, uh, use lvm for that...
--
Peter
4 p.m.
On Wed, 2005-06-01 at 23:15 +0100, Mike Hearn wrote:
On Wed, 01 Jun 2005 17:46:33 -0400, seth vidal wrote:
> > BTW., how does osx do installs (just bringing up the meta-file
> > installer thingy again. Feel free not to answer)?
>
> their package system, umm, err, sucks.
99.9% of users seem to disagree with you, judging by how often "Linux
should use appfolders like Macs do" is heard on various forums and mailing
lists.
One hears "Macs should do packaging $FOO way instead of their crap"
pretty often, too. I think everybody hates both ways, and which
complaints you see just depends on which lists you read.
--
Peter
1:22 a.m.
On 6/1/05, seth vidal <skvidal(a)phy.duke.edu> wrote:
> BTW., how does osx do installs (just bringing up the meta-file
installer
> thingy again. Feel free not to answer)?
their package system, umm, err, sucks.
Yeah! But many applications come packaged in such a way that the user
simply needs to drag'n'drop them to the /Applications directory.
That's really simple.
2:16 p.m.
Le jeudi 02 juin 2005 à 08:22 +0200, Felipe Alfaro Solana a écrit :
On 6/1/05, seth vidal <skvidal(a)phy.duke.edu> wrote:
> > BTW., how does osx do installs (just bringing up the meta-file installer
> > thingy again. Feel free not to answer)?
>
> their package system, umm, err, sucks.
Yeah! But many applications come packaged in such a way that the user
simply needs to drag'n'drop them to the /Applications directory.
That's really simple.
But the technical price for this is awful.
We may soon be able to do something similar from an end-user perspective
(dropping a metadatafile in a directory that's monitored by the system
and triggers an install) but that won't be in spite of rpm/yum but
thanks to them.
There is at least the same gap in underlying infrastructure as there
were between true and false transparency in X.
Moreover all the closed app vendors that would benefit the most from it
went the LSB/Mac way, turned their back on linux packaging principles,
and will be quite unable to exploit the system once it's in place.
They're still learning what a dependency is today!
--
Nicolas Mailhot
4:43 a.m.
ons, 01.06.2005 kl. 23.46 skrev seth vidal:
> >
>
> What about making it possible for non-text users to use yum? They
> shouldn't be kept out of such a great tool :)
it's a work-in-progress.
> BTW., how does osx do installs (just bringing up the meta-file installer
> thingy again. Feel free not to answer)?
their package system, umm, err, sucks.
a lot.
I was more referring to the little dialog that popped up when you
installed it. Not the appfolders (which suck, at least technically).
10 a.m.
On Wed, 2005-06-01 at 17:46 -0400, seth vidal wrote:
> >
>
> What about making it possible for non-text users to use yum? They
> shouldn't be kept out of such a great tool :)
it's a work-in-progress.
Speaking of which, is there a project page or hacking guide for pup? (or
maybe a feature reqs doc)
--
Jeff Pound <jpound(a)redhat.com>
6:10 p.m.
On Thu, 2005-06-02 at 11:00 -0400, Jeff Pound wrote:
> > What about making it possible for non-text users to use
yum? They
> > shouldn't be kept out of such a great tool :)
>
> it's a work-in-progress.
Speaking of which, is there a project page or hacking guide for pup?
(or
maybe a feature reqs doc)
Besides whats in CVS (at elvis), and Paul's talk from FUDCon 1 (at
fedoraproject.org), none that I know of
--
Colin Charles, http://www.bytebot.net/
10:29 a.m.
On Tue, Jun 07, 2005 at 04:10:25PM -0700, Colin Charles wrote:
> Speaking of which, is there a project page or hacking guide for
pup? (or
> maybe a feature reqs doc)
Besides whats in CVS (at elvis), and Paul's talk from FUDCon 1 (at
fedoraproject.org), none that I know of
There was a document on <http://fedora.redhat.com/>;, but it's gone now. (Not
for pup, but for some system-config-packages replacement.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
5:48 p.m.
On Wed, 01 Jun 2005 23:44:08 +0200, Kyrre Ness Sjobak wrote:
BTW., how does osx do installs (just bringing up the meta-file
installer
thingy again. Feel free not to answer)?
http://arstechnica.com/reviews/apps/delicious-library.ars/2
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/c...
That shows you pretty much how it works. In short:
- Packages are contained entirely within a relocatable directory,
which has a magic marker so the finder treats it as a file
- Packages have no dependencies outside the operating system. They
can embed libraries within themselves easily.
- Package installation is a matter of clicking a URL to a "DMG" file
which is a self mounting disk image, and dragging the appfolder
inside to the /Applications directory.
- There is no auto update system. Apple also provide a traditional
Installer service, which some things use.
- Nearly every app is packaged in this way. Mac users never have to
compile from source or wait while an app [update] is packaged.
Look at the screenshots in the Ars Technica article to get a feel for it.
Most users consider it easier than what Linux has, in my experience
(judging by how often I'm asked for it!)
thanks -mike
6:28 p.m.
On 6/1/05, Mike Hearn <mike(a)navi.cx> wrote:
- Packages are contained entirely within a relocatable directory,
which has a magic marker so the finder treats it as a file
- Packages have no dependencies outside the operating system. They
can embed libraries within themselves easily.
Yep its always fun having 23 different versions of gtk installed, one
for each gtk based app you want to run. All with a different patch
level... with no clear way to update any of them.
- There is no auto update system. Apple also provide a traditional
Installer service, which some things use.
a lack of update notification. Oh yeah.. thats absolutely wonderful.
Let's take for example
something based on gaim... you know something like... http://www.adiumx.com
Now gaim is actively development and like all networked software its
going to have issues.... http://gaim.sourceforge.net/security/
Users of adiumx, who rely on mac osx's installer have no way of
knowing that a new adiumx which incorporates a new libgaim to fix
vulnerabilities is available unless they proactively watch for it.
Extrapolate that out to 'all' applications including network facing
services.. and that's a horrible position place users in. I don't
think the complete lack of an update mechanism is an equitable
trade-off at all.
- Nearly every app is packaged in this way. Mac users never have to
compile from source or wait while an app [update] is packaged.
So no one uses fink anymore to get applications? I guess i should go
tell them to close the project down.
-jef"i think its time for someone to build their own distro using the
packaging paradigm they like the best"spaleta
10:01 p.m.
New subject: Packaging idea (Re: What next?)
-jef"i think its time for someone to build their own distro
using the
packaging paradigm they like the best"spaleta
So, check this out. I'm going to brainstorm outloud, so feel free to
shoot me down at any point.
We have:
1. People seem to like Apple's idea of dragging and dropping a
self-contained application folder into their Applications window, and
see it magically work. Of course, this is a horrible idea, since it
leads to the wonderful situation of a gajillion versions of libz and
libxml being installed, all in different levels of (un)patching. The
appeal, however, seems to be related to drag-and-dropping and seeing
it magically work.
2. Yum has leet magic powers to install software, tracking all
necessary dependencies via RPM libs, as long as the packages are a)
not broken and b) not built for another distro.
3. Yum has leet magic powers to update installed software via various
repositories that anyone around the world can create and maintain,
above exceptions a) and b) nonwithstanding.
What if:
We create a "super-package" that is effectively a yum .repo file with
a little extra information, and which can additionally contain a set
of packages. Let's call this Fedora Active Package (FAP). Let's say I
want to package my FlyingCows screensaver for Fedora, and I don't
actually want to bother with Extras, since that's way too much
trouble. So, I create a FlyingCows.fap, which is a zip archive
containing the following files:
1. A manifest describing the software I am packaging, which would
include a brief description with licensing information, which
distribution(s), which arch(es), and which version it is for (Fedora
Core 4 i386), maybe some other stuff like packager info. The manifest
would also link each distribution information with the .repo file for
that distribution.
2. FlyingCows.png to use for representing the package in, say, Nautilus.
3. A FlyingCows.repo file for yum. There may be more than one if more
than one distribution is handled
4. Optionally, FlyingCows-1.0.0-1.fc4.i386.rpm and any additional
libraries it depends on, all packaged snugly, which is useful for
giving out CDs, for example. FAP packages containing actual binaries
can be called .fab.
So, I package FlyingCows.fap and put it on my site. A user, wanting to
install my l33t screensaver, comes to my site and downloads
FlyingCows.fap onto their desktop. Then, they open the apps://
pseudo-folder in Nautilus (similar to, say, fonts://), and drag the
FlyingCows.fap there (or just double-click the package, which is the
same). Once this happens, the following things would occur:
1. A package information screen would pop up, containing
pre-installation information for the FlyingCows screensaver, like the
license, packaging info, etc. At this step a very basic distro sanity
comparison would be done, with a warning and a refusal if the user's
distribution is not packaged for: "You are trying to install
FlyingCows on a distribution that is not handled by this package
(Fedora Core 1). This package can only be installed on the following
systems: Fedora Core 3, Fedora Core 4, RHEL 4, CentOS 4). Install
cannot proceed." If Distribution does check out (a .repo file exists
for it), then installation goes on.
2. A user clicks "YES" on the license agreement.
3. The FAP handler installs the .repo file and, if there are any
binary files in the package, installs them into
/var/cache/yum/[repoid]: in other words, pre-populates the yum
download directory.
4. At this point yum is invoked, which handles the actual installation
-- including key download and verification, library dependencies, etc.
If there are newer versions available in my FlyingCows remote
repository, it downloads the latest versions and installs them instead
of the bundled binary files (optionally asking the user if they want
to do that).
5. If everything succeeds, a "FlyingCows is installed" is presented to
the happy user.
When the user gets tired of the Flying Cows, they can go to their
apps:/// pseudo-folder and drag the FlyingCows.png into the trash.
This would fire up the FAP handler and do a yum erase on the packages
installed by the FlyingCows.fap, which happens completely
transparently.
What do you think? Xingbuxing? There are drawbacks to this, of course,
but I can't think of any ones that we don't already have, like
generally broken packages and whacky packagers. Having a super-package
like a .fap or a .fab would allow vendors to package things for
multiple distributions by simply providing multiple .repo files, with
yum receiving the appropriate one.
Comments, please. :)
Cheers,
--
Konstantin Ryabitsev
Zlotniks, INC
"Выслухаў мядзьведзь казку і адарваў сабе хвост."
10:10 p.m.
New subject: Packaging idea (Re: What next?)
On 6/1/05, Konstantin Ryabitsev <mricon(a)gmail.com> wrote:
Let's say I
want to package my FlyingCows screensaver for Fedora, and I don't
actually want to bother with Extras, since that's way too much
trouble. So, I create a FlyingCows.fap, which is a zip archive
containing the following files:
Are you honestly saying... that working with other people.. inside the
Extras policy space is MORE trouble.. then creating yet another layer
of technical complexity.. that other people will have to help you
completely implement in other user-facing parts of the operating
system?
-jef"And I thought I was anti-social"spaleta
11:16 p.m.
New subject: Packaging idea (Re: What next?)
On 6/1/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
Are you honestly saying... that working with other people.. inside
the
Extras policy space is MORE trouble.. then creating yet another layer
of technical complexity.. that other people will have to help you
completely implement in other user-facing parts of the operating
system?
(correcting gmail's moronic reply handling)
Well, there isn't much added technical complexity here. This is more
or less a glorified "download a .repo file for your distribution and
put it in your /etc/yum.repos.d" directory with a Nautilus plugin. And
yes, I'm pretty sure a lot of people will not bother with Extras, if
only because:
a. They don't care to jump through all the hoops involved.
b. They don't want to bind themselves with any sort of a contract with Red Hat.
c. Their software is licensed so that it cannot be put in Extras.
--
Konstantin Ryabitsev
Zlotniks, INC
"Выслухаў мядзьведзь казку і адарваў сабе хвост."
11:27 p.m.
New subject: Packaging idea (Re: What next?)
Well, there isn't much added technical complexity here. This is
more
or less a glorified "download a .repo file for your distribution and
put it in your /etc/yum.repos.d" directory with a Nautilus plugin. And
yes, I'm pretty sure a lot of people will not bother with Extras, if
only because:
a. They don't care to jump through all the hoops involved.
the hoops are
getting lower and easier to overcome.
b. They don't want to bind themselves with any sort of a contract
with Red Hat.
the cla is very much like the asf's licensing agreement - nothing really
special in it at all.
c. Their software is licensed so that it cannot be put in Extras.
yep. that's the use case I figured from the .fap file you were
describing before.
-sv
11:35 p.m.
New subject: Packaging idea (Re: What next?)
On 6/2/05, seth vidal <skvidal(a)phy.duke.edu> wrote:
> c. Their software is licensed so that it cannot be put in
Extras.
yep. that's the use case I figured from the .fap file you were
describing before.
Yes, I cannot deny that the last 2 weeks spent packaging nonfree
software has greatly influenced this post. :) That, plus the sad fact
that even though several vendors provide .rpm files, they are utterly
unusable because they try to be installable on as many things as
possible, and always end up sucking on all.
--
Konstantin Ryabitsev
Zlotniks, INC
"Выслухаў мядзьведзь казку і адарваў сабе хвост."
11:41 p.m.
New subject: Packaging idea (Re: What next?)
On 6/2/05, Konstantin Ryabitsev <mricon(a)gmail.com> wrote:
Yes, I cannot deny that the last 2 weeks spent packaging nonfree
software has greatly influenced this post. :) That, plus the sad fact
that even though several vendors provide .rpm files, they are utterly
unusable because they try to be installable on as many things as
possible, and always end up sucking on all.
so basically the fap layer is only really a target for nonfree
software... but clearly
its doomed to fail because the pre-existing conditions for it to be
used successfully are not going to be met
if proprietary vendors can't package rpms correctly.. the fap layer
doesn't help.
if proprietary vendors can't create repos correctly.. the fap layer
doesn't help.
I have very little faith in proprietary vendors doing either correctly.
-jef
12:03 a.m.
New subject: Packaging idea (Re: What next?)
On 6/2/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> Yes, I cannot deny that the last 2 weeks spent packaging
nonfree
> software has greatly influenced this post. :) That, plus the sad fact
> that even though several vendors provide .rpm files, they are utterly
> unusable because they try to be installable on as many things as
> possible, and always end up sucking on all.
so basically the fap layer is only really a target for nonfree
software... but clearly
its doomed to fail because the pre-existing conditions for it to be
used successfully are not going to be met
if proprietary vendors can't package rpms correctly.. the fap layer
doesn't help.
if proprietary vendors can't create repos correctly.. the fap layer
doesn't help.
I have very little faith in proprietary vendors doing either correctly.
Well, not exactly. The problem currently is that the only relatively
standard packaging format available to vendors is .rpm, which works
great when there is one distro, and not so great when there are many
(the famous "rpms just create dependency hell" complaint). So, vendors
have several ways out:
1. Don't bother and ship tarballs with a #!/bin/sh installer. Have
some sort of an asinine custom updating mechanism, or none at all.
2. Create a long list for user to choose from:
* download this if you are running Suse 8
* download this if you are running Suse 9
* download this if you are running Fedora Core 2
* download this if you are running Fedora Core 3
* ...
...which they rarely do, since they think it confuses users, and
because some users only have a vague idea what distribution/version
they are running. If the vendor ships kernel modules, then this list
grows exponentially (see NVidia download page for examples). No
updating mechanism available.
3. Create one RPM that statically links most things, and tries to work
on anything by having horrendous staircases of %if-%endif, and by
installing everything in /usr/local and hoping things still work. No
updating mechanisms available.
A super-package mechanism would help create a framework that would
allow addressing the problems listed above. I'm not saying that
vendors are guaranteed to use it (and not abuse it, or use poorly as
they are wont to do with anything NIH), but if a mechanism is in place
that makes things for them easier and convenient, then at least there
would be a compelling reason for them to at least do something about
the pitiful state things are in at the moment.
Regards,
--
Konstantin Ryabitsev
Zlotniks, INC
"Выслухаў мядзьведзь казку і адарваў сабе хвост."
7:18 a.m.
New subject: Packaging idea (Re: What next?)
On 6/2/05, Konstantin Ryabitsev <mricon(a)gmail.com> wrote:
1. Don't bother and ship tarballs with a #!/bin/sh installer.
Have
some sort of an asinine custom updating mechanism, or none at all.
2. Create a long list for user to choose from:
* download this if you are running Suse 8
* download this if you are running Suse 9
* download this if you are running Fedora Core 2
* download this if you are running Fedora Core 3
* ...
...which they rarely do, since they think it confuses users,
So instead... you'd have every user download one fab that contained
ALL distro version specific packages? So instead of downloading 10
megs... i have to download 50 megs.. so i can have the suse and the
other fedora payloads shoved over the wire never to be used...
pointless. I can't wait to see openoffice.org's single upstream
fap.. yippie for T3 connections!
They still need to create the distro specific repos for faps to work!
How about we focus on that first.. how about we get package venders to
start using repositories at all and providing .repo files at all.
because some users only have a vague idea what distribution/version
they are running. If the vendor ships kernel modules, then this list
grows exponentially (see NVidia download page for examples). No
updating mechanism available.
kernel modules.. are special.. dkms... hopefully in extras soon. Can
we stick to ONE example please?
3. Create one RPM that statically links most things, and tries to
work
on anything by having horrendous staircases of %if-%endif, and by
installing everything in /usr/local and hoping things still work. No
updating mechanisms available.
And I dont think proprietary vendors are going to move away from this
at all. The could be using .repo definitiosn right now ... they
aren't.
-jef
2:31 p.m.
New subject: Packaging idea (Re: What next?)
Le jeudi 02 juin 2005 à 01:03 -0400, Konstantin Ryabitsev a écrit :
A super-package mechanism would help create a framework that would
allow addressing the problems listed above.
A super-package mechanism would add yet another layer of vendor mess
over the existing layers of vendor mess.
Sometimes less is more.
--
Nicolas Mailhot
3:21 p.m.
New subject: Packaging idea (Re: What next?)
This is probably science fiction from FC's perspective, but I came
across this interesting paper when researching software updates via
binary patches recently:
http://www.cs.uu.nl/people/eelco/pubs/eupfcdm-cbse2005-final.pdf
Abstract. Safe and efficient deployment of software components is an
important aspect of CBSE. The Nix deployment system enables side-by-side
deployment of different versions and variants of components, complete
installation, safe upgrades, and safe uninstalls through garbage
collection. It accomplishes this through a purely functional deployment
model, meaning that the file system content of a component only depends
on the inputs used to build it, and never changes afterwards. An apparent
downside to this model is that upgrading "fundamental" components
used as build inputs by many other components becomes expensive, since
all of these must be rebuilt and redeployed. In this paper we show that
binary patching between sets of components enables efficient deployment
of upgrades in the purely functional model, transparently to users.
Sequences of patches can be combined automatically to enable upgrading
between arbitrary versions. The approach was empirically validated.
On 6/2/05, Nicolas Mailhot <Nicolas.Mailhot(a)laposte.net> wrote:
Le jeudi 02 juin 2005 à 01:03 -0400, Konstantin Ryabitsev a écrit :
> A super-package mechanism would help create a framework that would
> allow addressing the problems listed above.
A super-package mechanism would add yet another layer of vendor mess
over the existing layers of vendor mess.
Sometimes less is more.
--
Nicolas Mailhot
BodyID:264713259.2.n.logpart (stored separately)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
4:46 a.m.
New subject: RPM guidelines for vendors (was: Packaging idea)
Jeff Spaleta wrote:
>Yes, I cannot deny that the last 2 weeks spent packaging nonfree
>software has greatly influenced this post. :) That, plus the sad fact
>that even though several vendors provide .rpm files, they are utterly
>unusable because they try to be installable on as many things as
>possible, and always end up sucking on all.
so basically the fap layer is only really a target for nonfree
software... but clearly
its doomed to fail because the pre-existing conditions for it to be
used successfully are not going to be met
if proprietary vendors can't package rpms correctly.. the fap layer
doesn't help.
if proprietary vendors can't create repos correctly.. the fap layer
doesn't help.
I have very little faith in proprietary vendors doing either correctly.
Are there guidelines for proprietary vendors to follow beyond the
fedora.us Wiki and Mandrake's Howto (neither of which addresses yum
repositories, unless my memory fails me) ?
Maybe it's just a problem of the relevant information being too
fragmented over too many mailing lists - in my own little corner of the
universe, this is equivalent to "there is no documentation" for the
proprietary software developer.
Furthermore, but maybe it's just me, I've found that proprietary
developers working under silly time constraints tend to skip "good
practices" in the rush to finish *but* pay attention to avoiding
known "bad practices", so maybe guidelines geared for vendor
packaging should be in the form of "horror stories" - if you
have suppressed the urge to rant about a glaring packaging blunder till
now, I just gave you a justification :-)
Thank you for your consideration,
Davide Bolcioni
6:49 a.m.
New subject: RPM guidelines for vendors (was: Packaging idea)
On Ven 3 juin 2005 11:46, Davide Bolcioni a écrit :
Maybe it's just a problem of the relevant information being too
fragmented over too many mailing lists - in my own little corner of the
universe, this is equivalent to "there is no documentation" for the
proprietary software developer.
It's a problem of closed vendors treating Linux as a better windows than
windows, or a better unix as solaris. Therefore they constantly bitch
about the things they're used to and are not 100% identical, and
completely ignore the genuinly different and innovative parts that evolved
in Linux. Of which packaging is on the forefront.
Vendors that genuinely believe Linux is here to stay and they need to be a
player there fare on the whole better than the others. They're approaching
the non-destructive rpm stage and will probably start releasing fine
packages in two to three years.
The others just need to be hit with the cluestick of people moving to
other products, and they'll adapt (at a time they pushed motif - most of
them have gotten over it now). All the proposed changes designed to have
the core infrastructure behave like something it isn't only slow down this
evolution while putting the burden of their mistakes on the rest of the
system.
Linux didn't get where it is now just because of the happy penguin. To
take advantage of it you need to actually look at what's in the box.
--
Nicolas Mailhot
11:52 p.m.
New subject: Packaging idea (Re: What next?)
On Thu, 2005-06-02 at 00:35 -0400, Konstantin Ryabitsev wrote:
On 6/2/05, seth vidal <skvidal(a)phy.duke.edu> wrote:
> > c. Their software is licensed so that it cannot be put in Extras.
>
> yep. that's the use case I figured from the .fap file you were
> describing before.
Yes, I cannot deny that the last 2 weeks spent packaging nonfree
software has greatly influenced this post. :) That, plus the sad fact
that even though several vendors provide .rpm files, they are utterly
unusable because they try to be installable on as many things as
possible, and always end up sucking on all.
Yes, very true. And what could be done to help fix that?
I propose: reviews, feedback, & iterative improvement
In my opinion, your original "thinking-out-loud" post overlooked perhaps
the biggest benefit of projects like Fedora Extras which is the
*reviews*. Folks seem to be very focused on tools but I'm not convinced
that better versions of yum, rpm, rpmlint, etc. will solve everything.
The tools can help a *lot* but, ultimately, its best to have a few
people review your junk and offer feedback. Even the sexiest and most
modern of automated tools still do a lousy job of discerning intent and
suggesting better approaches.
And if the 3rd-party or commercial packagers that you mention joined the
conversation, accepted feedback, and then used it to improve things
their packages would probably suck a lot less.
But then perhaps they wouldn't be "3rd-party" any more... ;-)
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
2:25 p.m.
New subject: Packaging idea (Re: What next?)
Le jeudi 02 juin 2005 à 00:16 -0400, Konstantin Ryabitsev a écrit :
And
yes, I'm pretty sure a lot of people will not bother with Extras, if
only because:
a. They don't care to jump through all the hoops involved.
b. They don't want to bind themselves with any sort of a contract with Red Hat.
c. Their software is licensed so that it cannot be put in Extras.
d. They don't want to QA their stuff on FC/RHEL. Yay drop statically-compiled horror
in /usr/local/bin
Nothing prevents them from creating an overlay repository today. You can
even solve the closed license part by adding authenticated https support
to yum today.
--
Nicolas Mailhot
1:30 a.m.
New subject: Packaging idea (Re: What next?)
On Wed, 01 Jun 2005 23:01:14 -0400, Konstantin Ryabitsev wrote:
Having a super-package like a .fap or a .fab would allow vendors to
package things for multiple distributions by simply providing multiple
.repo files, with yum receiving the appropriate one.
Well, distros other than Fedora don't use yum. But apart from that you
very nearly described autopackage, except that autopackage exists and is
being used right now:
http://autopackage.org/gallery.html
FlyingCows is very much the sort of thing it was built for.
thanks -mike
4:39 a.m.
New subject: Packaging idea (Re: What next?)
tor, 02.06.2005 kl. 08.30 skrev Mike Hearn:
On Wed, 01 Jun 2005 23:01:14 -0400, Konstantin Ryabitsev wrote:
> Having a super-package like a .fap or a .fab would allow vendors to
> package things for multiple distributions by simply providing multiple
> .repo files, with yum receiving the appropriate one.
Well, distros other than Fedora don't use yum. But apart from that you
very nearly described autopackage, except that autopackage exists and is
being used right now:
http://autopackage.org/gallery.html
No, its more similar to my .install idea a few weeks back, which
everyone killed because "it sounds like Windows installer. GO AWAY!".
Never metion GUI ideas in such a proposal...
BTW, would this format be capable of providing multiple repos for
multiple distros/distro versions?
Kyrre
1:12 p.m.
New subject: Packaging idea (Re: What next?)
On Thu, 02 Jun 2005 11:39:19 +0200, Kyrre Ness Sjobak wrote:
BTW, would this format be capable of providing multiple repos for
multiple distros/distro versions?
I'd suggest reading the website. Autopackage isn't based on multiple
repositories for each distro, that doesn't scale and never will.
thanks -mike
7:58 a.m.
New subject: Packaging idea (Re: What next?)
On Thu, 2005-06-02 at 07:30 +0100, Mike Hearn wrote:
On Wed, 01 Jun 2005 23:01:14 -0400, Konstantin Ryabitsev wrote:
> Having a super-package like a .fap or a .fab would allow vendors to
> package things for multiple distributions by simply providing multiple
> .repo files, with yum receiving the appropriate one.
Well, distros other than Fedora don't use yum.
umm. they don't?
CentOS
Yellowdog Linux
Tao Linux
Whitebox
-sv
8 a.m.
New subject: Packaging idea (Re: What next?)
On Thu, Jun 02, 2005 at 08:58:34AM -0400, seth vidal wrote:
> > Having a super-package like a .fap or a .fab would allow
vendors to
> > package things for multiple distributions by simply providing multiple
> > .repo files, with yum receiving the appropriate one.
> Well, distros other than Fedora don't use yum.
umm. they don't?
CentOS
Yellowdog Linux
Tao Linux
Whitebox
BU Linux. :)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 76 degrees Fahrenheit.
2:22 p.m.
New subject: Packaging idea (Re: What next?)
Le mercredi 01 juin 2005 à 23:01 -0400, Konstantin Ryabitsev a écrit :
> -jef"i think its time for someone to build their own distro
using the
> packaging paradigm they like the best"spaleta
So, check this out. I'm going to brainstorm outloud, so feel free to
shoot me down at any point.
Apart from the "drop a metadata file somewhere" all the rest is pretty
irrelevant to users. FC is not in the "let's be problem-compatible with
windows" space.
--
Nicolas Mailhot
1:10 a.m.
On Wed, 01 Jun 2005 19:28:22 -0400, Jeff Spaleta wrote:
Yep its always fun having 23 different versions of gtk installed,
one
for each gtk based app you want to run. All with a different patch
level... with no clear way to update any of them.
Word on the street is that it's traditional for operating systems to ship
with a widget toolkit and lots of other things too. Mac apps usually have
few (if any) dependencies because they depend on the OS itself. By saying
"This app requires MacOS X 10.3 or higher" apps get a massive chunk of
functionality for free, that would on Linux require about 70 dependencies
in order to express.
a lack of update notification. Oh yeah.. thats absolutely wonderful.
That's why Gaim has an auto-update plugin that will pop up a message when
there is an update.
In fact, given that the little Fedora/Red Hat tray thing has *never*
actually been able to stick in my session for more than about a week, I'm
not sure why you think Fedora has user-friendly auto update either.
Remembering to run a magic command every few weeks isn't user friendly.
> - Nearly every app is packaged in this way. Mac users never have
to
> compile from source or wait while an app [update] is packaged.
So no one uses fink anymore to get applications? I guess i should go
tell them to close the project down.
No, Apples target audience are not UNIX heads using lots of trivially
"ported" software so nobody in their target audience uses fink. Apps that
are actually designed and built for the Mac as opposed to simply being
compilable on it never have to be compiled from the source. Ever.
thanks -mike
8:48 a.m.
On 6/2/05, Mike Hearn <mike(a)navi.cx> wrote:
Word on the street is that it's traditional for operating systems
to ship
with a widget toolkit and lots of other things too.
So basically what you are saying is... you believe that an operating
system.. like Fedora Core.. should include ONE widget toolkit and then
demand all applications use that ONE widget toolkit? Please... please
go build a linux distro that is toolkit pure. And even if you do,
neither gtk or qt are going to disappear.. you will still have vendors
creating apps in both that your precious software management system
will have to deal with as an addon toolkit.
But hey.. prove me wrong. Build the distro that is qt pure or gtk
pure... and watch how much fun it is to drag in either toolkit in with
every application you install with your cool include the kitchen-sink
application installation process.
Mac apps usually have
few (if any) dependencies because they depend on the OS itself.
As long as we
aren't talking about any application that tries to be
cross-platform sure... but then of course you are talking about a
distinctly different pre-condition than what exists for any linux
distributor.
By saying
"This app requires MacOS X 10.3 or higher" apps get a massive chunk of
functionality for free, that would on Linux require about 70 dependencies
in order to express.
Because the collection of pieces that make up a linux distribution is
far more organic process. Fedora as a distributor of individual
project components can not dictate overall structure in the same way
that Apple can do with their operating system. You can't make a linux
distribution be a mockery of what macosx is... simply because of the
way the development is structured.
> a lack of update notification. Oh yeah.. thats absolutely
wonderful.
That's why Gaim has an auto-update plugin that will pop up a message when
there is an update.
i wasnt talking about 'gaim' the application i was talking about a
native macosx application that uses libgaim as a backend and uses
apples gorgeously braindead application installer method. You know..
native macosx toolkit and all that jazz. since gaim itself requires
gtk, a toolkit that apple doesnt provide as part of the OS.. to get
gaim installed you either compile it.. or most likely fink it. And we
aren't talking about applications like that.
In fact, given that the little Fedora/Red Hat tray thing has *never*
actually been able to stick in my session for more than about a week, I'm
not sure why you think Fedora has user-friendly auto update either.
Remembering to run a magic command every few weeks isn't user friendly.
I didn't say it was friendly. I said it existed. Evolving the
process we have now to make it user-friendly doesn't require stripping
out the package management system we have and starting over with mac
osx's concept. You are of course, free to experiment with doing
that... by building your own rpm-less or dpkg-less linux distro. I'd
absolutely LOVE to see someone, create a toy distro that re-implements
apple's application installer as a proof-of-concept inside the linux
landscape.. sanely dealing with all the fun issues like competing
toolkits that linux distributors have to deal with.
I've already related in this list how in my most unexpert opinion an
in-distro application that mimics the gnome menu structure could be
use as an intuitive way to interact with configured repository
collections as an install and removal tool.
No, Apples target audience are not UNIX heads using lots of
trivially
"ported" software so nobody in their target audience uses fink. Apps that
are actually designed and built for the Mac as opposed to simply being
compilable on it never have to be compiled from the source. Ever.
Right with one quick comment you summarily dismiss any application
that uses gtk or qt as being outside the boundary of discussion,
leaving precious few comparable applications. You need to face
reality. The landscape in which a linux distributor works is vastly
different than the landscape Apple creates.This is exactly what you
get when you compare Apples to Linuxes. Apple's development model is
starkly different than what ANY Linux distributor is going to be able
to do....especially a Linux distributor that is attempting to work
with upstream component projects as closely as possible. Top down
design versus diverse/competitive component development. If a Linux
distributor wants to
fork upstream projects into a mockery of mac osx.. more power to them.
But Fedora isn't that distributor.
-jef
11:35 a.m.
On Thu, 2005-06-02 at 07:10 +0100, Mike Hearn wrote:
On Wed, 01 Jun 2005 19:28:22 -0400, Jeff Spaleta wrote:
> a lack of update notification. Oh yeah.. thats absolutely wonderful.
That's why Gaim has an auto-update plugin that will pop up a message when
there is an update.
Oh, having every application do it's own auto-update checking is just
wonderful. Wait.. no it's not.
In fact, given that the little Fedora/Red Hat tray thing has *never*
actually been able to stick in my session for more than about a week,
No such luck here, it sits there quite happily eating gobs of memory
until cowboys come home on all of my systems.
- Panu -
11:21 p.m.
Panu Matilainen wrote:
No such luck here, it sits there quite happily eating gobs of memory
until cowboys come home on all of my systems.
- Panu -
"chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my
installations. :-)
Only root gets it then. Crude but effective.
(Thanks, Alan!)
-Steve Bergman
11:36 p.m.
On Thu, Jun 02, 2005 at 11:21:35PM -0500, Steve Bergman wrote:
"chmod 700 /usr/bin/rhn-applet-gui" is standard procedure
after *all* my
installations. :-)
Only root gets it then. Crude but effective.
Ow -- you're logging in to the GUI as root?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
1:28 a.m.
On Thu, 2005-06-02 at 23:21 -0500, Steve Bergman wrote:
Panu Matilainen wrote:
>No such luck here, it sits there quite happily eating gobs of memory
>until cowboys come home on all of my systems.
>
> - Panu -
>
>
>
>
"chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my
installations. :-)
Only root gets it then. Crude but effective.
yum remove rhn-applet
problem solved.
-sv
9:34 a.m.
On Fri, 2005-06-03 at 02:28 -0400, seth vidal wrote:
On Thu, 2005-06-02 at 23:21 -0500, Steve Bergman wrote:
> Panu Matilainen wrote:
>
> >No such luck here, it sits there quite happily eating gobs of memory
> >until cowboys come home on all of my systems.
> >
> > - Panu -
> >
> >
> >
> >
> "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my
> installations. :-)
>
> Only root gets it then. Crude but effective.
>
yum remove rhn-applet
problem solved.
I hate to admit it but I remove all the redhat update stuff as well and
use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile
(but ultimately found fedora to be superior) and found their update
functionality much more usable.
-sv
12:43 p.m.
I hate to admit it but I remove all the redhat update stuff as well
and
use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile
(but ultimately found fedora to be superior) and found their update
functionality much more usable.
when fc4 comes out with yum 2.3.X in it - I'd like to hear your take on
if yum is still coming out slower than apt for your use.
some very smart people have made it faster in many different ways.
-sv
12:12 p.m.
On Fri, 2005-06-03 at 13:43 -0400, seth vidal wrote:
> I hate to admit it but I remove all the redhat update stuff as
well and
> use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile
> (but ultimately found fedora to be superior) and found their update
> functionality much more usable.
when fc4 comes out with yum 2.3.X in it - I'd like to hear your take on
if yum is still coming out slower than apt for your use.
some very smart people have made it faster in many different ways.
-sv
Seth, took me a bit to find this post again but I wanted to let you know
that the newest yum is in fact much faster even the 'yum search' which
used to be considerably slower than apt. Thanks! :)
3:17 p.m.
>
Seth, took me a bit to find this post again but I wanted to let you know
that the newest yum is in fact much faster even the 'yum search' which
used to be considerably slower than apt. Thanks! :)
As was pointed out to me - I need to mark down today on my calendar:
June 14th - someone on fedora-devel-list said something positive about
yum.
:)
thanks,
-sv
3:57 p.m.
On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote:
As was pointed out to me - I need to mark down today on my calendar:
June 14th - someone on fedora-devel-list said something positive about
yum.
:)
thanks,
-sv
I must say that yum has been working magnificently around here lately and
on the odd occasion where there was a hickup/operator error, a solution
was posted almost immediately. There is no question in my mind that if
Fedora is to be the success we all hope it will be, it will be in large
part due to the blood, sweat and tears Seth has poured into Yum.
Thanks Seth,
Karen
4:06 p.m.
On Tue, 2005-06-14 at 16:57 -0400, kas wrote:
On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote:
>
> As was pointed out to me - I need to mark down today on my calendar:
> June 14th - someone on fedora-devel-list said something positive about
> yum.
> :)
>
> thanks,
>
> -sv
>
I must say that yum has been working magnificently around here lately and
on the odd occasion where there was a hickup/operator error, a solution
was posted almost immediately. There is no question in my mind that if
Fedora is to be the success we all hope it will be, it will be in large
part due to the blood, sweat and tears Seth has poured into Yum.
There lots of folks beyond me working on this now.
Take a look at the AUTHORS file in the docs of yum.
All of those folks deserve credit.
-sv
5:57 p.m.
seth vidal wrote:
On Tue, 2005-06-14 at 16:57 -0400, kas wrote:
>On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote:
>
>
>
>>As was pointed out to me - I need to mark down today on my calendar:
>>June 14th - someone on fedora-devel-list said something positive about
>>yum.
>>:)
>>
>>thanks,
>>
>>-sv
>>
>>
>>
>I must say that yum has been working magnificently around here lately and
>on the odd occasion where there was a hickup/operator error, a solution
>was posted almost immediately. There is no question in my mind that if
>Fedora is to be the success we all hope it will be, it will be in large
>part due to the blood, sweat and tears Seth has poured into Yum.
>
>
There lots of folks beyond me working on this now.
Take a look at the AUTHORS file in the docs of yum.
All of those folks deserve credit.
-sv
Cheer *3 for the yum authors (and the FOSS developers in general).
While these lists always seem so negative since they are typically used
for hashing out problems, I suspect there is a silent happy majority out
there very appreciative of all the work contributed for the greater good.
Keep up the great work.
/Mike
6:09 p.m.
seth vidal wrote:
On Tue, 2005-06-14 at 16:57 -0400, kas wrote:
>On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote:
>
>
>
>>As was pointed out to me - I need to mark down today on my calendar:
>>June 14th - someone on fedora-devel-list said something positive about
>>yum.
>>:)
>>
>>thanks,
>>
>>-sv
>>
>>
>>
>I must say that yum has been working magnificently around here lately and
>on the odd occasion where there was a hickup/operator error, a solution
>was posted almost immediately. There is no question in my mind that if
>Fedora is to be the success we all hope it will be, it will be in large
>part due to the blood, sweat and tears Seth has poured into Yum.
>
>
There lots of folks beyond me working on this now.
Take a look at the AUTHORS file in the docs of yum.
All of those folks deserve credit.
-sv
I'm using yum in a bi-arch environment and I have no complaints. Well
indeed it works like a charm.
--
Manuel Moreno
manolo(a)miconexion.com
9:20 p.m.
New subject: Making update functionality more usable (Was: Re: What next?)
On Fri, 2005-06-03 at 09:34 -0500, Matthew Lenz wrote:
I hate to admit it but I remove all the redhat update stuff as well
and
use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile
(but ultimately found fedora to be superior) and found their update
functionality much more usable.
Since one of the goals of FC5 is to have pup in place to handle updates
from a graphical point of view, I'd be interested in hearing what sorts
of things made the Ubuntu stuff more usable. Or the same for other
distros as well.
Jeremy
3:53 a.m.
New subject: Making update functionality more usable (Was: Re: What next?)
On Sun, 2005-06-05 at 22:20 -0400, Jeremy Katz wrote:
On Fri, 2005-06-03 at 09:34 -0500, Matthew Lenz wrote:
> I hate to admit it but I remove all the redhat update stuff as well and
> use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile
> (but ultimately found fedora to be superior) and found their update
> functionality much more usable.
Since one of the goals of FC5 is to have pup in place to handle updates
from a graphical point of view, I'd be interested in hearing what sorts
of things made the Ubuntu stuff more usable. Or the same for other
distros as well.
The update-notifier is wonderfull.
I have a translator using Ubuntu, and the way the icon *only* shows it
self when there are updates was enough to make her go check it out.
When she was trying Fedora, that didn't happen. The icon was always
there, and making it flash wasn't appealing enough.
Also, the way it was just click... click... now it's updating, was so
easy that I've found she's updating without ever having to tell her to
do it :)
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
7:34 a.m.
New subject: Making update functionality more usable (Was: Re: What next?)
On Mon, 2005-06-06 at 09:53 +0100, Rui Miguel Seabra wrote:
> > I hate to admit it but I remove all the redhat update stuff
as well and
> > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile
> > (but ultimately found fedora to be superior) and found their update
> > functionality much more usable.
>
> Since one of the goals of FC5 is to have pup in place to handle updates
> from a graphical point of view, I'd be interested in hearing what sorts
> of things made the Ubuntu stuff more usable. Or the same for other
> distros as well.
Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and
update-notifier, right?
We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's
update-notifier
The update-notifier is wonderfull.
IIRC, pup is to have an update-notifier as well (it will suck less
memory than rhn-applet, I'm assured)
I have a translator using Ubuntu, and the way the icon *only* shows
it
self when there are updates was enough to make her go check it out.
When she was trying Fedora, that didn't happen. The icon was always
there, and making it flash wasn't appealing enough.
Ah, icons. We should keep this in mind during FC-5 then
--
Colin Charles, http://www.bytebot.net/
7:42 a.m.
New subject: Making update functionality more usable (Was: Re: What next?)
On Wed, 2005-06-08 at 05:34 -0700, Colin Charles wrote:
On Mon, 2005-06-06 at 09:53 +0100, Rui Miguel Seabra wrote:
> > > I hate to admit it but I remove all the redhat update stuff as well and
> > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for
awhile
> > > (but ultimately found fedora to be superior) and found their update
> > > functionality much more usable.
> >
> > Since one of the goals of FC5 is to have pup in place to handle updates
> > from a graphical point of view, I'd be interested in hearing what sorts
> > of things made the Ubuntu stuff more usable. Or the same for other
> > distros as well.
Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and
update-notifier, right?
We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's
update-notifier
They have a graphical update manager that's very fancy. Probably the
update-notifier icon is part of that update manager.
Another very interesting thing is that every single one of those apps
around packaging use the same repo settings (besides other settings), so
they feel integrated.
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
3:55 p.m.
New subject: Making update functionality more usable (Was: Re: What next?)
tor, 09.06.2005 kl. 14.42 skrev Rui Miguel Seabra:
On Wed, 2005-06-08 at 05:34 -0700, Colin Charles wrote:
> On Mon, 2005-06-06 at 09:53 +0100, Rui Miguel Seabra wrote:
> > > > I hate to admit it but I remove all the redhat update stuff as well
and
> > > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for
awhile
> > > > (but ultimately found fedora to be superior) and found their update
> > > > functionality much more usable.
> > >
> > > Since one of the goals of FC5 is to have pup in place to handle updates
> > > from a graphical point of view, I'd be interested in hearing what
sorts
> > > of things made the Ubuntu stuff more usable. Or the same for other
> > > distros as well.
>
> Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and
> update-notifier, right?
>
> We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's
> update-notifier
They have a graphical update manager that's very fancy. Probably the
update-notifier icon is part of that update manager.
Another very interesting thing is that every single one of those apps
around packaging use the same repo settings (besides other settings), so
they feel integrated.
Rui
They all use apt, so apt sources is always used.
I think Fedora is also heading that way (yum).
5:29 a.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Colin Charles wrote:
Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and
update-notifier, right?
We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's
update-notifier
1. I'd like to add smart install to Extras.
- It's written by the author of Synaptic and principal maintainer of
apt-get for RPM
- Its a replacement for yum / apt-get / up2date / synaptic / etc.
- It has both a CLI and GUI interface.
- The GUI version is GTK2, and looks exactly like Synaptic (oddly enough
being written by the same author).
- It works with Yum metadata repositories.
- Its faster than yum and apt-get as it downloads from multiple sources
simultaneously.
I've been using it on Rawhide for months and it's fast, simple, and
reliable.
2. What's pup? Where can I find out more about it? What's it's
relationship to s-c-p?
Mike
7:45 a.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On Fri, Jun 10, 2005 at 08:29:13PM +1000, Mike MacCana wrote:
1. I'd like to add smart install to Extras.
Okay.
2. What's pup? Where can I find out more about it? What's
it's
relationship to s-c-p?
A GUI front end to updating packages via yum. In the archives; also, short
FUDCon1 presentation. "Better than, for what it does."
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
10:31 a.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Hmm.
On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote:
1. I'd like to add smart install to Extras.
- It's written by the author of Synaptic and principal maintainer of
apt-get for RPM
- Its a replacement for yum / apt-get / up2date / synaptic / etc.
- It has both a CLI and GUI interface.
- The GUI version is GTK2, and looks exactly like Synaptic (oddly enough
being written by the same author).
- It works with Yum metadata repositories.
- Its faster than yum and apt-get as it downloads from multiple sources
simultaneously.
It's written in Python, too! Very nice. Thanks for the tip...
I've been using it on Rawhide for months and it's fast,
simple, and
reliable.
2. What's pup? Where can I find out more about it? What's it's
relationship to s-c-p?
Pup is a project that has as a goal replacing the functionality of
rhn-applet-gui + up2date. It is not now within its' scope to do ad-hoc
package management like Synaptic. I know because I asked yesterday on
the fedora config list.
- C
2:51 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Chris McDonough wrote:
Hmm.
On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote:
>1. I'd like to add smart install to Extras.
>
>- It's written by the author of Synaptic and principal maintainer of
>apt-get for RPM
>- Its a replacement for yum / apt-get / up2date / synaptic / etc.
>- It has both a CLI and GUI interface.
>- The GUI version is GTK2, and looks exactly like Synaptic (oddly enough
>being written by the same author).
>- It works with Yum metadata repositories.
>- Its faster than yum and apt-get as it downloads from multiple sources
>simultaneously.
It's written in Python, too! Very nice. Thanks for the tip...
Does smartpm support multilib yet?
Warren Togami
wtogami(a)redhat.com
4:42 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Hard to say, as I don't have a machine on which to test that multilib
actually works, but the docs indicate that some thought has been put
into it:
- There's a special RPMNameProvides class that must be used
to provide the package name itself together with the package
version and the architecture appended. We must use a special
class here to be able to match RPMObsoletes against
package names only, since that's the way RPM expects it to
happen. Appending the architecture is necessary for
multilib handling of upgrades. Notice that RPM packages
already provide the name/version explicitly, so instead
of just adding a new provides, it's usually necessary
to catch the existent provides and change the class/append
the arch when matching the package name/version.
On Fri, 2005-06-10 at 09:51 -1000, Warren Togami wrote:
Chris McDonough wrote:
> Hmm.
>
> On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote:
>
>>1. I'd like to add smart install to Extras.
>>
>>- It's written by the author of Synaptic and principal maintainer of
>>apt-get for RPM
>>- Its a replacement for yum / apt-get / up2date / synaptic / etc.
>>- It has both a CLI and GUI interface.
>>- The GUI version is GTK2, and looks exactly like Synaptic (oddly enough
>>being written by the same author).
>>- It works with Yum metadata repositories.
>>- Its faster than yum and apt-get as it downloads from multiple sources
>>simultaneously.
>
>
> It's written in Python, too! Very nice. Thanks for the tip...
Does smartpm support multilib yet?
Warren Togami
wtogami(a)redhat.com
4:59 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Warren Togami (wtogami(a)redhat.com) said:
>It's written in Python, too! Very nice. Thanks for the
tip...
Does smartpm support multilib yet?
IIRC, apt doesn't, and it's in Extras. So, not sure that that's
a blocking issue.
Bill
5:04 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Bill Nottingham wrote:
Warren Togami (wtogami(a)redhat.com) said:
>>It's written in Python, too! Very nice. Thanks for the tip...
>
>Does smartpm support multilib yet?
IIRC, apt doesn't, and it's in Extras. So, not sure that that's
a blocking issue.
Bill
Huh? apt and smartpm have nothing in common.
Warren Togami
wtogami(a)redhat.com
5:06 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On 6/10/05, Warren Togami <wtogami(a)redhat.com> wrote:
Huh? apt and smartpm have nothing in common.
i think the point of notting's point was the fact that multilib
support isn't a requirement for inclusion into Extras for any new
alternative tool
-jef"i could make a joke about packaging grab but I'll go home and
drink instead"spaleta
5:42 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
FWIW, it does appear to handle multilib OK, as I see both i686 and i386
versions of the same packages independently.
On Fri, 2005-06-10 at 18:06 -0400, Jeff Spaleta wrote:
On 6/10/05, Warren Togami <wtogami(a)redhat.com> wrote:
> Huh? apt and smartpm have nothing in common.
i think the point of notting's point was the fact that multilib
support isn't a requirement for inclusion into Extras for any new
alternative tool
-jef"i could make a joke about packaging grab but I'll go home and
drink instead"spaleta
6:48 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On 6/10/05, Chris McDonough <chrism(a)plope.com> wrote:
FWIW, it does appear to handle multilib OK, as I see both i686 and
i386
versions of the same packages independently.
I think you are a little confused. You need to check to see if it can
handle parallel installation of both 64bit and 32bit packages while on
64bit hardware.
-jef
8:15 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On Fri, 2005-06-10 at 19:48 -0400, Jeff Spaleta wrote:
On 6/10/05, Chris McDonough <chrism(a)plope.com> wrote:
> FWIW, it does appear to handle multilib OK, as I see both i686 and i386
> versions of the same packages independently.
I think you are a little confused. You need to check to see if it can
handle parallel installation of both 64bit and 32bit packages while on
64bit hardware.
Yep, probably I am. I don't have a machine on which I can test that
simultaneous installation of 32-bit and 64-bit binaries actually works.
But if "multilib" means "the capability to distinguish between multiple
architecture packages for the same component and have the ability to
install each simultaneously or independently", smart seems to be able to
do that just fine. It takes the architecture into account when
presenting the package listing.
- C
9:29 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
Once upon a time, Chris McDonough <chrism(a)plope.com> said:
But if "multilib" means "the capability to distinguish
between multiple
architecture packages for the same component and have the ability to
install each simultaneously or independently", smart seems to be able to
do that just fine.
That's not what multilib means. It means the ability to take into
account 32 and 64 bit libs and apps, and properly satisfy dependencies
as appropriate. For example, if on a 64 bit arch I want to install a 32
bit app, the package management tool has to know that if the app
requires libabc, it needs to find a 32 bit libabc to satisfy the dep
(whether or not the 64 bit libabc is install or available has no
relevance).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:56 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On Fri, 2005-06-10 at 21:29 -0500, Chris Adams wrote:
That's not what multilib means. It means the ability to take
into
account 32 and 64 bit libs and apps, and properly satisfy dependencies
as appropriate. For example, if on a 64 bit arch I want to install a 32
bit app, the package management tool has to know that if the app
requires libabc, it needs to find a 32 bit libabc to satisfy the dep
(whether or not the 64 bit libabc is install or available has no
relevance).
Gotcha. Thanks, I understand now. Maybe somebody with a 64-bit machine
can try it out and let us know for sure?
- C
4:24 a.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On Saturday 11 June 2005 11:56, Chris McDonough wrote:
On Fri, 2005-06-10 at 21:29 -0500, Chris Adams wrote:
> That's not what multilib means. It means the ability to take into
> account 32 and 64 bit libs and apps, and properly satisfy
> dependencies as appropriate. For example, if on a 64 bit arch I
> want to install a 32 bit app, the package management tool has to
> know that if the app requires libabc, it needs to find a 32 bit
> libabc to satisfy the dep (whether or not the 64 bit libabc is
> install or available has no relevance).
Gotcha. Thanks, I understand now. Maybe somebody with a 64-bit
machine can try it out and let us know for sure?
Or, you could ask gustavo:
smart(a)linux-mandrake.com
I've already forwarded a part of the thread over there.
take care,
--
-jeff
8:25 a.m.
New subject: Smart package manager
On Fri, Jun 10, 2005 at 12:04:05PM -1000, Warren Togami wrote:
Bill Nottingham wrote:
> Warren Togami (wtogami(a)redhat.com) said:
> > > It's written in Python, too! Very nice. Thanks for the tip...
> > Does smartpm support multilib yet?
Yes, it does.
Try for yourself: http://atrpms.net/name/smart/
Works for all FCs, RHEL4, RHL7.3-9. Does not work yet for RHEL3 due to
promoteepoch necessities.
Also rhn backend support would be very nice to have for RHEL3/4 (but
officially probably out of Fedora's scope). It is said to be easy to
add, but it would probably be done best by an rhn expert (Adrian?
misa?).
> IIRC, apt doesn't, and it's in Extras. So, not sure that
that's a
> blocking issue.
>
> Bill
>
Huh? apt and smartpm have nothing in common.
Other than the author? ;)
--
Axel.Thimm at ATrpms.net
7:40 p.m.
New subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?))
On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote:
1. I'd like to add smart install to Extras.
Please go thru the Fedora Extras new maintainer process, and package
away!
- Its a replacement for yum / apt-get / up2date / synaptic / etc.
It must /work alongside/ and can't *replace* Core tools. We've done away
with the idea of Fedora Alternatives, in where a core replacement could
sit (in theory)
2. What's pup? Where can I find out more about it? What's
it's
relationship to s-c-p?
Mailing list archives, fedora-config-list will be helpful.
--
Colin Charles, http://www.bytebot.net/
FUDCon II @ LinuxTag
June 24-25, 2005 in Karlsruhe, Germany
http://fedoraproject.com/fudcon/
11:03 p.m.
On Fri, 2005-06-03 at 02:28 -0400, seth vidal wrote:
On Thu, 2005-06-02 at 23:21 -0500, Steve Bergman wrote:
> Panu Matilainen wrote:
>
> >No such luck here, it sits there quite happily eating gobs of memory
> >until cowboys come home on all of my systems.
> >
> > - Panu -
> >
> >
> >
> >
> "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my
> installations. :-)
>
> Only root gets it then. Crude but effective.
>
yum remove rhn-applet
Another solution might be to include a simple applet as part of yum that
allows users to see what new software is avaiable without having to run
rhn-applet. I'd happily get rhn-applet, except that it does show me
when new updates have been releasd and what's been updated (without
having to go to the command line, and doing so manually).
I love the applet on my desktop and just wish is was included with yum
(and not rhn-applet).
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
7:38 p.m.
On Wed, 2005-06-01 at 23:48 +0100, Mike Hearn wrote:
On Wed, 01 Jun 2005 23:44:08 +0200, Kyrre Ness Sjobak wrote:
> BTW., how does osx do installs (just bringing up the meta-file installer
> thingy again. Feel free not to answer)?
That shows you pretty much how it works. In short:
Hi Mike,
Have you been using *nix long enough to remember when people thought it
was cool to stuff every package into is own /opt/${PACKAGE} directory?
Does it sound at all familiar to Apple's approach that you just
described?
It should because its the *exact* same crap all over again. And as Jeff
and many other folks will tell you, it just doesn't scale in terms of
libraries (think about shared libraries and dependencies for just a
minute), security updates, etc. Its the packaging equivalent of
declaring that your yard is "clean" because you keep your copious
garbage heaps in carefully segregated piles.
In short, its a total mess.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
1:07 a.m.
On Wed, 01 Jun 2005 20:38:37 -0400, Ed Hill wrote:
Have you been using *nix long enough to remember when people thought
it
was cool to stuff every package into is own /opt/${PACKAGE} directory?
Yep.
Does it sound at all familiar to Apple's approach that you just
described?
Nope. Not really. Putting apps in their own (movable) directory isn't the
issue here. The things that make appfolders easy go pretty deep, but the
fact that it's implemented in terms of magic directories is just a surface
detail.
1:28 p.m.
On Thu, 2005-06-02 at 07:07 +0100, Mike Hearn wrote:
On Wed, 01 Jun 2005 20:38:37 -0400, Ed Hill wrote:
> Have you been using *nix long enough to remember when people thought it
> was cool to stuff every package into is own /opt/${PACKAGE} directory?
Yep.
> Does it sound at all familiar to Apple's approach that you just
> described?
Nope. Not really. Putting apps in their own (movable) directory isn't the
issue here. The things that make appfolders easy go pretty deep, but the
fact that it's implemented in terms of magic directories is just a surface
detail.
From the description that you've provided, there is *no* depth.
And
there is *no* magic.
Quoting from your original email, the two key parts are:
- Packages have no dependencies outside the operating system. They
can embed libraries within themselves easily.
- There is no auto update system. Apple also provide a traditional
Installer service, which some things use.
So when you've thrown out updates and completely eliminated any intra-
package dependencies, whats left? Nothing but a hollow GUI wrapper over
yet-another brain-dead application of /opt/${PACKAGE}.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
3:10 p.m.
On Thu, 02 Jun 2005 14:28:21 -0400, Ed Hill wrote:
So when you've thrown out updates and completely eliminated any
intra-
package dependencies, whats left? Nothing but a hollow GUI wrapper over
yet-another brain-dead application of /opt/${PACKAGE}.
No, not at all. Read the links I posted, in particular the one about
porting Linux apps. There are bits of magic here:
- LaunchServices
- Framework/bundle linking
- Internet enabled DMGs
Anyway, I'm not suggesting we implement appfolders like Apple did. We can
do better (and don't have much choice anyway). See here:
http://autopackage.org/ui-vision.html
That describes how to implement a Mac style UI on top of Linux style
package management.
3:55 a.m.
On Wed, 2005-06-01 at 23:48 +0100, Mike Hearn wrote:
- Packages are contained entirely within a relocatable directory,
which has a magic marker so the finder treats it as a file
- Packages have no dependencies outside the operating system. They
can embed libraries within themselves easily.
The only thing this helps is proprietary crap, which can't be fixed to
use new libraries or the standard system library version of whatever.
There's no need for the free world to work this way because proprietary
software is crapware :)
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
12:55 p.m.
Le mercredi 01 juin 2005 à 23:44 +0200, Kyrre Ness Sjobak a écrit :
BTW., how does osx do installs (just bringing up the meta-file
installer
thingy again. Feel free not to answer)?
Mac systems and all the systems they inspired (java...) basically stuff
an app and all its needs in a single archive (because you can't mouse
easily more than one file)
Installation is just dropping this file in the right place
Un-installation is deleting it
It sucks big time because you have massive code duplication leading to
maintenance problems and high memory usage, no shared infrastructure
apart from the one provided by the OS/JVM and controlled by a single
vendor. And app writers do not really care if all the third-party stuff
they put in their archive with their own code is stale and leaking.
--
Nicolas Mailhot
4:49 p.m.
On Wed, Jun 01, 2005 at 05:11:39PM -0400, seth vidal wrote:
- extras organization into package groups or even sub-repos
Maybe including changing all of the "Group:" tags to something more
well-considered? (Like, just, "Core" and "Extras"; or, whatever the
sub-repos end up being.)
- stripping of core of any program that provides duplicate
functionality to another program.
With a very broad definition of "duplicate".
- making the barrier to use of extras VERY low.
This should go *above* the previous one. :)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
12:57 p.m.
Le mercredi 01 juin 2005 à 17:49 -0400, Matthew Miller a écrit :
On Wed, Jun 01, 2005 at 05:11:39PM -0400, seth vidal wrote:
> - extras organization into package groups or even sub-repos
Maybe including changing all of the "Group:" tags to something more
well-considered? (Like, just, "Core" and "Extras"; or, whatever the
sub-repos end up being.)
Maybe admit they were a bad idea and kill them
--
Nicolas Mailhot
1:32 p.m.
On Thu, Jun 02, 2005 at 07:57:02PM +0200, Nicolas Mailhot wrote:
> Maybe including changing all of the "Group:" tags to
something more
> well-considered? (Like, just, "Core" and "Extras"; or, whatever
the
> sub-repos end up being.)
Maybe admit they were a bad idea and kill them
I'm suggesting killing the idea of using them for fine-grained grouping,
yeah. But they still could be useful for what I suggest above.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.
5:26 p.m.
Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
I'd like to see better laptop support, in particular some sort of
Profile support as well as better wireless support. Currently to have my
laptop work both at home and at work (in dual mode), i have to hack
rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel
argument so that it also changes the Xorg.conf file, .gconf files, and
so on.... Also, system-config-network is still an incredibly
counter-intuitive and confusing tool.
-denis
5:31 p.m.
On Wed, Jun 01, 2005 at 03:26:54PM -0700, Denis Leroy wrote:
>Maybe it's time to start the brainstorming for Fedora Core 5
and Fedora
>Extras 5 - what major features are you willing to put effort into?
I'd like to see better laptop support, in particular some sort of
Profile support as well as better wireless support.
Profiles: Isn't this the aim of sabayon (sp?)
Better wireless support: The upstream drivers are slowly starting
to converge to a point of sanity. Ie, a common ieee80211 core
which drivers share, rather than implementing their own variants
of in each driver with different userspace semantics. So FC5 will
get better through this work, but it probably won't be 'perfect'
for quite a while just due to the sheer volume of work needed
to be done to fix up some of the mess in that part of the kernel.
Dave
5:53 p.m.
On Wed, Jun 01, 2005 at 06:31:21PM -0400, Dave Jones wrote:
On Wed, Jun 01, 2005 at 03:26:54PM -0700, Denis Leroy wrote:
> >Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> >Extras 5 - what major features are you willing to put effort into?
> I'd like to see better laptop support, in particular some sort of
> Profile support as well as better wireless support.
Profiles: Isn't this the aim of sabayon (sp?)
Better wireless support: The upstream drivers are slowly starting
to converge to a point of sanity. Ie, a common ieee80211 core
which drivers share, rather than implementing their own variants
of in each driver with different userspace semantics. So FC5 will
get better through this work, but it probably won't be 'perfect'
for quite a while just due to the sheer volume of work needed
to be done to fix up some of the mess in that part of the kernel.
BTW, on a related matter I had trouble getting my laptop's prism54
card working when trying FC4T3 on it. As usual, I had to install,
then throw the binary firmware into /lib/firmware and then I _would_
have expected the card to "just work" on insertion. But it didn't.
I had to play around to get it recognized at all. First, the system
just ignored the card on insert for whatever reason.
Can someone tell me how this is _supposed_ to work? Having to install
the binary myself is bad enough (yes, I know the politics around this
so I won't start a debate over that *g*), but I'd expect it to work
then... am I asking too much?
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
6:31 p.m.
I'd like to see better laptop support, in particular some sort
of
Profile support as well as better wireless support. Currently to have my
laptop work both at home and at work (in dual mode), i have to hack
rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel
argument so that it also changes the Xorg.conf file, .gconf files, and
so on....
I would like automatic second display support (when connecting your
laptop to a projector for example). So far I haven't been able to figure
out how to do it except restart X with different settings. IMHO, it's one
feature Apple's Powerbooks do really well running OS X.
// kaj
6:59 p.m.
Kaj J. Niemi wrote:
I would like automatic second display support (when connecting your
laptop to a projector for example). So far I haven't been able to figure
out how to do it except restart X with different settings. IMHO, it's one
feature Apple's Powerbooks do really well running OS X.
After watching the video of the talks from Guadec, you can see that this
is a big problem. Almost every talk started off with 5 or 10 minutes of
fiddling to get the video-to-projector working. In some cases, the
presentation went on with partially broken displays.
Of course, if we can't do, neither can John Q. PowerPoint.
Steven Garrity
9:23 a.m.
After watching the video of the talks from Guadec, you can see that
this
is a big problem. Almost every talk started off with 5 or 10 minutes of
fiddling to get the video-to-projector working. In some cases, the
presentation went on with partially broken displays. Of course, if we
can't do, neither can John Q. PowerPoint.
In my experience, having seen a lot of powerpoint presentations in both
IT and telco environments Windows 2000/XP support almost any decent projector
very well and autoconfigure themselves correctly as well. Most issues with
projectors and Windows relate to people being unsure how to switch displays
(what function key was it again?) or not being patient enough while waiting
for the projector to scan its inputs and figuring out how to display it.
Not having watched the Guadec videos I can't of course say if the display
issues were with people using Windows or Linux :-)
// kaj
12:42 p.m.
* Steven Garrity <stevelist(a)silverorange.com> [2005-06-01 20:04]:
Kaj J. Niemi wrote:
>I would like automatic second display support (when connecting your
>laptop to a projector for example). So far I haven't been able to figure
>out how to do it except restart X with different settings. IMHO, it's one
>feature Apple's Powerbooks do really well running OS X.
After watching the video of the talks from Guadec, you can see that this
is a big problem. Almost every talk started off with 5 or 10 minutes of
fiddling to get the video-to-projector working. In some cases, the
presentation went on with partially broken displays.
I think part of the problem here was xrandr. It seemed that when using the
dynamic resolution switching app (which I think uses xrandr), things didn't
work. We ended up having to restart X using the resolution we wanted and
get the technician to re-sync the projector before our stuff worked (and by
'worked' I mean 'worked for all but ~5% of the bottom of the screen' ;) .
Andrew
10:58 p.m.
On Thu, 2005-06-02 at 13:42 -0400, Andrew Overholt wrote:
* Steven Garrity <stevelist(a)silverorange.com> [2005-06-01
20:04]:
> Kaj J. Niemi wrote:
> >I would like automatic second display support (when connecting your
> >laptop to a projector for example). So far I haven't been able to figure
> >out how to do it except restart X with different settings. IMHO, it's one
> >feature Apple's Powerbooks do really well running OS X.
>
> After watching the video of the talks from Guadec, you can see that this
> is a big problem. Almost every talk started off with 5 or 10 minutes of
> fiddling to get the video-to-projector working. In some cases, the
> presentation went on with partially broken displays.
I think part of the problem here was xrandr. It seemed that when using the
dynamic resolution switching app (which I think uses xrandr), things didn't
work. We ended up having to restart X using the resolution we wanted and
get the technician to re-sync the projector before our stuff worked (and by
'worked' I mean 'worked for all but ~5% of the bottom of the screen' ;) .
My wife's Linux based laptop (a HP running FC2) with 1024x768 resolution
just works with projectors. She plugs the projector into the back and
then uses the Fn-<toggle> to choose between just the laptop, just the
projector or both.
On my laptop (a Dell running FC4) with 1920x1200 resolution I've had no
luck at all getting a couple of projectors to show my screen. All these
projectors were capable of sizes up to 1600x1200, but even running my
laptop at these screen sizes didn't work.
The problem didn't seem to be the resolution, but rather the output to
the plug at the back of the laptop. By this I mean that even running my
screen at 1024x768 the bottom and sides were chopped off, pretty much
the same thing that happened at 1920x1200.
This would be great to have addressed as I would love to be able to just
plug in my laptop and go. Getting something on the screen wasn't a
problem, just getting it to display (enough of) my desktop.
Rodd
--
"It's a fine line between denial and faith.
It's much better on my side"
11:10 p.m.
New subject: Laptop Enhancements (was Re: What next?)
On Thursday 02 June 2005 07:31, Kaj J. Niemi wrote:
> I'd like to see better laptop support, in particular some
sort of
> Profile support as well as better wireless support. Currently to
> have my laptop work both at home and at work (in dual mode), i have
> to hack rc.sysinit horribly to extend the semantic of the
> 'netprofile=' kernel argument so that it also changes the Xorg.conf
> file, .gconf files, and so on....
I would like automatic second display support (when connecting your
laptop to a projector for example). So far I haven't been able to
figure out how to do it except restart X with different settings.
IMHO, it's one feature Apple's Powerbooks do really well running OS
X.
This should be requested upstream at X.org. All Fedora can do is provide
config hackery. Automation by flipping between resolutions. meta
modes, virtual resolutions, merged FB, xinerama, etc. etc. is the realm
of X.org.
Anyway, I can't even get the CRT/LCD switch to work since ACPI, it's
just always on my IBM T30.
I'd like to see better default configs for Synaptics.
Recommend MergedFB over Xinerama. It's got some quirks, but it's faster.
(Not all cards support it.)
There also needs to be a massive undertaking to get Sleep in ACPI to
actually function for a wide range of supported laptops. This includes
participation in upstream ACPI to get patches and configs in. Also
should include populating /etc/acpi/actions, /etc/acpi/events with the
right stuff to get better behavior during sleep. Scripts could throw
in cute things like kdialog or gdialog to bring up dialogs like
"Computer sleeping...". Maybe a patch to Dbus to get an event
instead .. who knows.
Maybe there needs to be a fedora laptop mailing list, project, and
working group to address all of these issues and other miscellaneous
howtos littering the internet. Dealing with packaging for different
laptop configurations would also be an interesting issue to address.
--
-jeff
3:16 p.m.
On Wed, 2005-06-01 at 15:26 -0700, Denis Leroy wrote:
Elliot Lee wrote:
>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
>Extras 5 - what major features are you willing to put effort into?
>
>
I'd like to see better laptop support, in particular some sort of
Profile support as well as better wireless support. Currently to have my
laptop work both at home and at work (in dual mode), i have to hack
rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel
argument so that it also changes the Xorg.conf file, .gconf files, and
so on.... Also, system-config-network is still an incredibly
counter-intuitive and confusing tool.
With good hardware [1], NetworkManager works very very well these days.
I expect this to become even better with FC5 (I believe nowadays you
need to manually add /usr/libexec/nm-applet to your startup programs in
GNOME... :-/)
Cheers,
David
[1] : e.g. networking cards with good drivers (and firmware) that are in
the mainline and thus the Fedora kernel. The IBM T41 that I and many
other people at Red Hat uses is an example of this.
3:48 p.m.
David Zeuthen wrote:
On Wed, 2005-06-01 at 15:26 -0700, Denis Leroy wrote:
>Elliot Lee wrote:
>
>
>>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
>>Extras 5 - what major features are you willing to put effort into?
>>
>>
>
>I'd like to see better laptop support, in particular some sort of
>Profile support as well as better wireless support. Currently to have my
>laptop work both at home and at work (in dual mode), i have to hack
>rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel
>argument so that it also changes the Xorg.conf file, .gconf files, and
>so on.... Also, system-config-network is still an incredibly
>counter-intuitive and confusing tool.
With good hardware [1], NetworkManager works very very well these days.
I expect this to become even better with FC5 (I believe nowadays you
need to manually add /usr/libexec/nm-applet to your startup programs in
GNOME... :-/)
Cheers,
David
Looks like a very nice wireless tool. But by the time i get to the desktop
login window, i.e. way before NetworkManager comes into play, it's WAY to late
to make decisions about profiles: my laptop at work wants eth0 to come up on
boot, because it wants things such as nfs-mounted home directories, ntpd,
dual-screen Xorg.conf and so on. For example, booting my laptop at home in
work profile will result in a boot time of 10 MINUTES for all the stupid
startup scripts to time out and fail and a pretty unusable system. So this is
where we're really lacking imho.
-denis
6:06 p.m.
I'd like to see the minimum required size for a 'firewall-only' setup drop.
Something like conectiva's minimum install which takes less than 70Mb.
- mb
On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Best,
-- Elliot
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
6:35 p.m.
On 6/1/05, mbneto <mbneto(a)gmail.com> wrote:
I'd like to see the minimum required size for a
'firewall-only' setup drop.
Something like conectiva's minimum install which takes less than 70Mb.
This comes up a lot. And everytime it comes up I suggest that the
first step that interested community members can do is edit the
comps.xml file that defines the groups the installer uses. The very
first thing users interested in a smaller 'minimal' install can do is
reorganize the comps.xml so the minimal install installs less without
disturbing the desktop/workstation/server install types. A reworked
comps.xml is easy to hand out for the rest of the community to test by
rebuild isos and doing test installs. Once the groups are
reorganized, you'll have to talk with specific developers about
dividing packages into subpackages to reduce the minimal install
further.
-jef
7:55 p.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Some support for live-CD, Knoppix-style media. Stateless clients support
is a plus.
Some way to share Evolution calendar and contacts info between computers
and between users.
Some way to migrate desktop settings from one machine to another, so I
don't end up doing rsync/ssh hacks to keep my xchat/gaim/whatever
settings in sync.
GL-accelerated X server, so that my eyes won't hurt anymore after
staring at the tube for 10 hours straight.
...hmmm, it looks like most of the things I'm mentioning are projects
that are still in full development, unfinished yet.
--
Florin Andrei
http://florin.myip.org/
10:24 p.m.
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Okay, every six months I advertise some of my own projects:
- Bugzilla #127378 Encrypted swap
- Bugzilla #124789 Encrypted root
And here are of few more of interest to me:
- Bugzilla #158657 Build totem's Mozilla plugin
- Bugzilla #127537 Free software applet viewer plugin
- Free software flash viewer?
- Bugzilla #122274 Mouse button emulation on Mac laptops
--
Mike
:wq
1:46 a.m.
On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5
and Fedora
> Extras 5 - what major features are you willing to put effort into?
And here are of few more of interest to me:
- Bugzilla #158657 Build totem's Mozilla plugin
- Bugzilla #127537 Free software applet viewer plugin
http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is
the current lack of sandboxing.
- Free software flash viewer?
http://www.schleef.org/swfdec/
plays some Flash, but fails on interactive and later Flash versions.
--
Aaron Kurtz <a.kurtz(a)hardsun.net> GPG Key ID: ED588CF2
10:43 a.m.
New subject: Snowfox:White list firefox with gcj for intranets [was What next]
On Wed, 2005-06-01 at 23:46 -0700, Aaron Kurtz wrote:
On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote:
> > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> > Extras 5 - what major features are you willing to put effort into?
> And here are of few more of interest to me:
>
> - Bugzilla #158657 Build totem's Mozilla plugin
> - Bugzilla #127537 Free software applet viewer plugin
http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is
the current lack of sandboxing.
Why not adapt the firefox source rpm to build an extra binary (
of /usr/lib/firefox-1.0.4/firefox-bin ) package called
Snowfox - a White list Firefox for intranets.
The Snowfox binary would use separate plug-in and user configure
directories than the Firefox binary, but only be able to access URIs
from an assigned "white list". Snowfox would pass any URLs not matching
the white list to the normal Firefox. A Firefox extension could perform
the same role, passing URLs in the white list to Snowfox. The Snowfox
client would perform vetting using the referrer URL to stop cross-linked
attacks.
The advantage is that it separates the data, cache cookies and plug-ins
used with intranets and Internet. SELinux can be used to further isolate
each instance. You could then deploy trusted plug-ins for Snowfox
without the fear of having them abused like Active-X. That means you can
use Snowfox to deploy GCJ, Python and Perl based plugins which could
access the user environment.
This is something which could be developed downstream at Mozilla, but
trivial enough to it with a patch for the current or next Fedora.
> - Free software flash viewer?
http://www.schleef.org/swfdec/ plays some Flash, but fails on interactive and later Flash
versions.
--
Aaron Kurtz <a.kurtz(a)hardsun.net> GPG Key ID: ED588CF2
--
David Mohring <heretic(a)ihug.co.nz>
10:54 a.m.
New subject: Snowfox:White list firefox with gcj for intranets [was What next]
On Fri, Jun 03, 2005 at 03:43:52AM +1200, David Mohring wrote:
On Wed, 2005-06-01 at 23:46 -0700, Aaron Kurtz wrote:
> On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote:
> > > Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
> > > Extras 5 - what major features are you willing to put effort into?
> > And here are of few more of interest to me:
> >
> > - Bugzilla #158657 Build totem's Mozilla plugin
> > - Bugzilla #127537 Free software applet viewer plugin
>
> http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is
> the current lack of sandboxing.
>
Why not adapt the firefox source rpm to build an extra binary (
of /usr/lib/firefox-1.0.4/firefox-bin ) package called
Snowfox - a White list Firefox for intranets.
That's unnecessary. gcjwebplugin already works as a small mozilla/firefox
plugin and the Java applet is running in a separate process.
To make gcjwebplugin really usable, AppletSecurityManager class needs to
be written (ATM it is just a dummy class that allows almost everything),
I guess some Java auditing needs to be done and SELinux policy written for
gcjappletviewer.
Jakub
10:59 a.m.
New subject: Snowfox:White list firefox with gcj for intranets [was What next]
HI
That's unnecessary. gcjwebplugin already works as a small
mozilla/firefox
plugin and the Java applet is running in a separate process.
To make gcjwebplugin really usable, AppletSecurityManager class needs to
be written (ATM it is just a dummy class that allows almost everything),
I guess some Java auditing needs to be done and SELinux policy written for
gcjappletviewer.
Jakub
What about when users turn off SELinux? (not a bright idea but
still...) Will the plugin check that and stop working?
regards
Rahul
11:07 a.m.
New subject: Snowfox:White list firefox with gcj for intranets [was What next]
On Thu, 2005-06-02 at 11:54 -0400, Jakub Jelinek wrote:
On Fri, Jun 03, 2005 at 03:43:52AM +1200, David Mohring wrote:
> On Wed, 2005-06-01 at 23:46 -0700, Aaron Kurtz wrote:
> > On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote:
> > > > Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
> > > > Extras 5 - what major features are you willing to put effort into?
> > > And here are of few more of interest to me:
> > >
> > > - Bugzilla #158657 Build totem's Mozilla plugin
> > > - Bugzilla #127537 Free software applet viewer plugin
> >
> > http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is
> > the current lack of sandboxing.
> >
>
> Why not adapt the firefox source rpm to build an extra binary (
> of /usr/lib/firefox-1.0.4/firefox-bin ) package called
> Snowfox - a White list Firefox for intranets.
That's unnecessary. gcjwebplugin already works as a small mozilla/firefox
plugin and the Java applet is running in a separate process.
To make gcjwebplugin really usable, AppletSecurityManager class needs to
be written (ATM it is just a dummy class that allows almost everything),
I guess some Java auditing needs to be done and SELinux policy written for
gcjappletviewer.
And what about Python, Perl etc?
BTW I'm getting a little tired of ALL the vendors, be it Microsoft,
KDE, Opera, Apple and yes, even Mozilla saying "Trust the browser and
plugin!". Recent history, even including Sun's JVMs, points to the
browser and plugins being the real weak point on ALL desktop platforms.
If you TRULY want fedora/Redhat to provide better security, is not a
little more isolation a better option?
Jakub
--
David Mohring <heretic(a)ihug.co.nz>
11:33 a.m.
New subject: Snowfox:White list firefox with gcj for intranets [was What next]
>>>> "Jakub" == Jakub Jelinek
<jakub(a)redhat.com> writes:
> Why not adapt the firefox source rpm to build an extra binary (
> of /usr/lib/firefox-1.0.4/firefox-bin ) package called
> Snowfox - a White list Firefox for intranets.
Jakub> That's unnecessary. gcjwebplugin already works as a small
Jakub> mozilla/firefox plugin and the Java applet is running in a
Jakub> separate process. To make gcjwebplugin really usable,
Jakub> AppletSecurityManager class needs to be written (ATM it is just
Jakub> a dummy class that allows almost everything), I guess some Java
Jakub> auditing needs to be done and SELinux policy written for
Jakub> gcjappletviewer.
A few things are needed before I would be comfortable advertising
libgcj's applet security. I have a to-do list here with the tasks,
I'll put it on the gcc wiki or in the gcc bugzilla or something soon.
A couple of us are pressing for "make applets work" to be the next big
target for gcj development. This means finishing the security tasks
and also some AWT improvements. AFAIK this decision isn't settled
yet; and we're taking suggestions. (Another related task I want to
see is java web start support, so we can run applications off the web.
Most of the pieces for this exist once we've got security working.)
Defense in depth sounds like a great plan to me, so an SELinux policy
should definitely be included.
Tom
11:57 a.m.
New subject: Snowfox:White list firefox with gcj for intranets [was What next]
On Thu, 2005-06-02 at 10:33 -0600, Tom Tromey wrote:
>>>>> "Jakub" == Jakub Jelinek
<jakub(a)redhat.com> writes:
>> Why not adapt the firefox source rpm to build an extra binary (
>> of /usr/lib/firefox-1.0.4/firefox-bin ) package called
>> Snowfox - a White list Firefox for intranets.
Jakub> That's unnecessary. gcjwebplugin already works as a small
</SNIP>
Defense in depth sounds like a great plan to me, so an SELinux
policy
should definitely be included.
Then why not "Defense in depth" using SELinux typing to isolate intranet
and Internet client access?
Tom
--
David Mohring <heretic(a)ihug.co.nz>
7:58 a.m.
On Wed, 1 Jun 2005 22:24:26 -0500, W. Michael Petullo <mike(a)flyn.org>
wrote:
- Bugzilla #158657 Build totem's Mozilla plugin
- Bugzilla #127537 Free software applet viewer plugin
- Free software flash viewer?
I hate to say it, but intellectual property restrictions make the
multimedia software shipped with Fedora a joke, which I end up scrapping
and replacing with stuff that plays media I get off the street.
Ogg is great, for instance, and I rip CDs with ogg, but if I want to
listen to 99% of the audio streams out there, I need mp3, and that's a
matter of trashing the multimedia stuff that comes with Fedora and
replacing it. My flash mp3 player doesn't play ogg, and I'd rather
install some encoder software of questionably status than shell out
another $200 for one that does.
I know you can't really do anything about it, but this underlying
problem makes improvements to multimedia players on Fedora like
rearraigning the deck chairs on the titanic.
8:02 a.m.
Hi
Ogg is great, for instance, and I rip CDs with ogg, but if I
want to listen to 99% of the audio streams out there, I need mp3,
and that's a matter of trashing the multimedia stuff that comes with
Fedora and replacing it. My flash mp3 player doesn't play ogg, and
I'd rather install some encoder software of questionably status than
shell out another $200 for one that does.
You can use Real Player or relocate into a region that doesnt support
software patents :-)
regards
Rahul
8:05 a.m.
Ogg is great, for instance, and I rip CDs with ogg, but if I want
to
listen to 99% of the audio streams out there, I need mp3, and that's a
matter of trashing the multimedia stuff that comes with Fedora and
replacing it.
Trashing? No. It's been my experience that all that it takes is
installing on gstreamer plugin from livna and one set of libraries for
it.
then it's done.
what do you have to trash?
I know you can't really do anything about it, but this
underlying
problem makes improvements to multimedia players on Fedora like
rearraigning the deck chairs on the titanic.
not really. As long as they allow simple plugins it works nicely, I've found.
-sv
3 p.m.
Paul A. Houle wrote:
On Wed, 1 Jun 2005 22:24:26 -0500, W. Michael Petullo
<mike(a)flyn.org>
wrote:
>
> - Bugzilla #158657 Build totem's Mozilla plugin
> - Bugzilla #127537 Free software applet viewer plugin
> - Free software flash viewer?
>
I hate to say it, but intellectual property restrictions make the
multimedia software shipped with Fedora a joke, which I end up
scrapping and replacing with stuff that plays media I get off the street.
Ogg is great, for instance, and I rip CDs with ogg, but if I want
to listen to 99% of the audio streams out there, I need mp3, and
that's a matter of trashing the multimedia stuff that comes with Fedora
and replacing it. My flash mp3 player doesn't play ogg, and I'd
rather install some encoder software of questionably status than shell
out another $200 for one that does.
I know you can't really do anything about it, but this underlying
problem makes improvements to multimedia players on Fedora like
rearraigning the deck chairs on the titanic.
Has a high-ranked RedHat official ever tried calling Fraunhofer in Germany to
negociate something ? Fraunhofer has always said they would not enfore the MP3
patents onto open-source and free projects. Maybe RHEL wouldn't qualify, but
Fedora should be fine...
3:42 p.m.
On Thu, Jun 02, 2005 at 01:00:02PM -0700, Denis Leroy wrote:
Has a high-ranked RedHat official ever tried calling Fraunhofer in
Germany
to negociate something ? Fraunhofer has always said they would not enfore
the MP3 patents onto open-source and free projects. Maybe RHEL wouldn't
qualify, but Fedora should be fine...
If RHEL doesn't qualify, then that would be an additional restriction
forbidden by the GPL. Some-other-licensed MP3 player might get by with this,
though. (However, it's not really in the spirit of Free / open source
software.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 79 degrees Fahrenheit.
11:49 a.m.
Matthew Miller wrote:
If RHEL doesn't qualify, then that would be an additional
restriction
forbidden by the GPL. Some-other-licensed MP3 player might get by with this,
though. (However, it's not really in the spirit of Free / open source
software.)
Which means that it couldn't be included in Fedora (Core or Extras)
either.
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
1:52 p.m.
Ian Pilcher wrote:
Matthew Miller wrote:
> If RHEL doesn't qualify, then that would be an additional restriction
> forbidden by the GPL. Some-other-licensed MP3 player might get by with
> this,
> though. (However, it's not really in the spirit of Free / open source
> software.)
Which means that it couldn't be included in Fedora (Core or Extras)
either.
This doesn't look obvious to me. I know the way the GPL and Patents interact
is always a source of debate, but the GPL specifies "If, as a consequence of a
court judgment or allegation of patent infringement..., conditions are imposed
on you (whether by court order, agreement or otherwise) that contradict the
conditions of this License...". The whole point here would be to get
Fraunhofer to give 'written promise' to not sue the newly founded non-profit
Fedora Foundation, then there will not be any 'court judgments' or
'allegations' to speak of that would bother the GPL... See this interesting
read at http://www.phptr.com/articles/article.asp?p=353550&seqNum=14&rl=1
-denis
1:58 p.m.
Once upon a time, Denis Leroy <denis(a)poolshark.org> said:
otherwise) that contradict the conditions of this License...".
The whole
point here would be to get Fraunhofer to give 'written promise' to not sue
the newly founded non-profit Fedora Foundation, then there will not be any
'court judgments' or 'allegations' to speak of that would bother the
GPL...
Read the rest of that section of the GPL:
For example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive copies
directly or indirectly through you, then the only way you could
satisfy both it and this License would be to refrain entirely from
distribution of the Program.
So if Fraunhofer allows any GPL distribution, anyone can take that code
(or a derived work) and distribute it under the terms of the GPL (which
means that Red Hat or TiVo for example can sell it without paying
license feeds to Fraunhofer). Under the terms of the GPL, Fraunhofer
cannot allow free/non-commercial distribution and restrict commercial
distribution of the same code.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
2:24 p.m.
On 6/3/05, Chris Adams <cmadams(a)hiwaay.net> wrote:
So if Fraunhofer allows any GPL distribution, anyone can take that
code
(or a derived work) and distribute it under the terms of the GPL (which
means that Red Hat or TiVo for example can sell it without paying
license feeds to Fraunhofer). Under the terms of the GPL, Fraunhofer
cannot allow free/non-commercial distribution and restrict commercial
distribution of the same code.
If this issue was about Fraunhofers rights and responsbilities as a
"copyright" holder to GPL code you'd be sort of right.. but the issue
isn't about "copyrights" its about "patents".
Fraunhofer has not released a single piece of code "copyrighted" under
the GPL. The issue is about the "patents" Fraunhofer holds, and
Fraunhofter can absolutely grant their patent as they deem fit
regardless of what the GPL "copyright" license says. Do not confuse
patents with copyrights.. they are distinctly different legal
concepts.
Fraunhofer is not a party to any GPL "copyright" license for any code
that uses concepts from the associated "patents." Fraunhofer's
actions with regard how it licenses its "patents" are not bound by the
"copyright" restrictions GPL places works under its "copyright"
protections. The GPL puts restrictions on the actions of
redistributors of the GPL "copyrighted" work. If a "patent" holder
prevents redistribution to any individual.. then the GPL says noone is
allow to redistribute. The GPL does not restrict the actions of the
"patent" holder in any way.. it restricts redistribution of the
"copyrighted" work to prevent privledged redistribution. Fraunhofer
can attempt to play favorites with its patents all it wants...but the
GPL prevents anyone from taking advantage of Fraunhofer's actions. If
there was a BSD "copyright" licensed implementation out there for mp3,
that would change things considerable. BSD "copyright" license is
perfectly compatible with non-commercial use "patent" licenses like
what Fraunhofer currently allows.
-jef"dials up groklaw and signs chris up for the next GPL-101 class"spaleta
3:32 p.m.
*snip*
If
there was a BSD "copyright" licensed implementation out there for mp3,
that would change things considerable. BSD "copyright" license is
perfectly compatible with non-commercial use "patent" licenses like
what Fraunhofer currently allows.
So that somebody would write a BSD gstreamer mp3 plugin, and RH would
call Fraunhofer and get the goahead for Fedora - it would be OK (but
they would have to pay fraunhofer for distributing the same plugin with
RHEL?)?
3:40 p.m.
On 6/3/05, Kyrre Ness Sjobak <kyrre(a)solution-forge.net> wrote:
So that somebody would write a BSD gstreamer mp3 plugin, and RH
would
call Fraunhofer and get the goahead for Fedora - it would be OK
I said the existence of a BSD codebase would be compatible with the
patent situation whereas the GPL codebases are not by virtue of
restrictions that the GPL places regarding redistribution. I did not
say a BSD licensed plugin to gst would be acceptable in terms of
licensing arrangements (though gstreamer is lgpl so it seems likely).
I did not say that RH would choose to allow any such code base in
Fedora Core or Extras.
-jef
3:41 p.m.
On Fri, 2005-06-03 at 22:32 +0200, Kyrre Ness Sjobak wrote:
*snip*
> If
> there was a BSD "copyright" licensed implementation out there for mp3,
> that would change things considerable. BSD "copyright" license is
> perfectly compatible with non-commercial use "patent" licenses like
> what Fraunhofer currently allows.
So that somebody would write a BSD gstreamer mp3 plugin, and RH would
call Fraunhofer and get the goahead for Fedora - it would be OK (but
they would have to pay fraunhofer for distributing the same plugin with
RHEL?)?
But is that what we want? To enable anybody to just take Fedora and
distribute it -- for free or for money -- we don't want to include
software with specific license exemptions for us. Having a patent
license exemption only for the project wouldn't be different in my eyes.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
4:36 p.m.
fre, 03.06.2005 kl. 22.41 skrev Nils Philippsen:
On Fri, 2005-06-03 at 22:32 +0200, Kyrre Ness Sjobak wrote:
> *snip*
> > If
> > there was a BSD "copyright" licensed implementation out there for
mp3,
> > that would change things considerable. BSD "copyright" license is
> > perfectly compatible with non-commercial use "patent" licenses like
> > what Fraunhofer currently allows.
>
> So that somebody would write a BSD gstreamer mp3 plugin, and RH would
> call Fraunhofer and get the goahead for Fedora - it would be OK (but
> they would have to pay fraunhofer for distributing the same plugin with
> RHEL?)?
But is that what we want? To enable anybody to just take Fedora and
distribute it -- for free or for money -- we don't want to include
software with specific license exemptions for us. Having a patent
license exemption only for the project wouldn't be different in my eyes.
I agree, was just testing out the idea. Even if mp3 support would be
great for many users.
OTOH, don't already RH-artwork, present such a problem for freely
distributing?
And not everyone lives in the US.
Kyrre
4:40 p.m.
On 6/3/05, Kyrre Ness Sjobak <kyrre(a)solution-forge.net> wrote:
OTOH, don't already RH-artwork, present such a problem for
freely
distributing?
No.. because there is an explicit trademark license that allows 3rd
parties to take the fedora software..without modification... and
redistribute it.
http://fedora.redhat.com/about/trademarks/guidelines/page4.html
-jef
4:02 p.m.
Once upon a time, Kyrre Ness Sjobak <kyrre(a)solution-forge.net> said:
So that somebody would write a BSD gstreamer mp3 plugin, and RH
would
call Fraunhofer and get the goahead for Fedora - it would be OK (but
they would have to pay fraunhofer for distributing the same plugin with
RHEL?)?
That would still mean that Fedora would have a restricted distribution,
which is counter to the Fedora project goals.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:33 p.m.
On Fri, Jun 03, 2005 at 10:32:20PM +0200, Kyrre Ness Sjobak wrote:
So that somebody would write a BSD gstreamer mp3 plugin, and RH
would
call Fraunhofer and get the goahead for Fedora - it would be OK (but
they would have to pay fraunhofer for distributing the same plugin with
RHEL?)?
People sell Fedora and it is also free software, which means no restrictions.
Anyone who wants is free to try and negotiate with the MP3 license holders to
get a license one off for their project or for GPL use. I believe people have
tried.
4:06 p.m.
Once upon a time, Jeff Spaleta <jspaleta(a)gmail.com> said:
If this issue was about Fraunhofers rights and responsbilities as a
"copyright" holder to GPL code you'd be sort of right.. but the issue
isn't about "copyrights" its about "patents".
I was basing my comments on the current state of freely (legal or not)
available MP3 decoders. AFAIK the free decoders are all GPL. For that
code to actually be legally distributable in some places (i.e. the US),
Fraunhofer would have to agree to a royalty-free patent license to the
copyright holder _and_ to anyone else who distributes such code under
the terms of the GPL (whether such distribution is commercial or not).
Otherwise, the code cannot be distributed at all (since a patent license
requirement conflicts with the terms of the GPL).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:18 p.m.
On 6/3/05, Chris Adams <cmadams(a)hiwaay.net> wrote:
I was basing my comments on the current state of freely (legal or
not)
available MP3 decoders. AFAIK the free decoders are all GPL. For that
code to actually be legally distributable in some places (i.e. the US),
Fraunhofer would have to agree to a royalty-free patent license to the
copyright holder _and_ to anyone else who distributes such code under
the terms of the GPL (whether such distribution is commercial or not).
Otherwise, the code cannot be distributed at all (since a patent license
requirement conflicts with the terms of the GPL).
The assessment is valid... and materially different than what you
wrote earlier... because this paragraph does not put constraints on
what Fraunhofer is allowed to do with their patents.
-jef
12:25 a.m.
Am Mittwoch, den 01.06.2005, 13:59 -0400 schrieb Elliot Lee:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
These were the first ideas that jumped out of my head:
- http://gnome-power.sourceforge.net/ ?
- Suspend-to-Disk support in the kernel? I know, Davej does not like the
implementation in the kernel. Okay, I trust his decision -- but
outsiders may not.
And on the other side: Suse (and probably others) use it since two or
three versions now. IMHO we should either prove somehow why we don't
like it and therefor disable it in our kernel -- or we should enable
(and test)it (at least in rawhide).
- core only on three(?) CDs (better one)?
- One DVD that can install both i386 and x86_64 (now that Intel starts
shipping Celerons more and more people will try x86_64)
- x86-Fedora-Live-DVD (like Knoppix) that also can install both i386 and
x86_64 (for computer magazines that want to ship one media with a
Linux-Distribution together with their print issue).
- Once during lifetime of Core a updated media-set with all updates
integrated -- this was done for the Red Hat magazine before iirc
- One minor thing: network yum cache of downloaded packages. With
something like that you don't have to download all packages more then
once if you install them on more then one system (okay, something like
that can be implemented with a shared network folder -- until someone
calls "yum clean all" or does other bad things). I can post more details
if someone is interested
- Maybe a central "folder"/frontend from where you can call all the
"system-config-*" (no, I don't think we need it -- but it seems those
yast and drakeconf users miss something like that)
- dmraid support in anaconda (I don't like this fake-raid-controllers
but users do...)
BTW, who takes all suggestions from this thread and updates
http://www.fedoraproject.org/wiki/Wishlist
?
CU
thl
9:33 a.m.
- One minor thing: network yum cache of downloaded packages. With
something like that you don't have to download all packages more then
once if you install them on more then one system (okay, something like
that can be implemented with a shared network folder -- until someone
calls "yum clean all" or does other bad things). I can post more details
if someone is interested
You seen yum-downloader yet? It might help with some of this.
I think a yum caching util should probably be in yum-utils and not
really for discussion on this list.
-sv
9:37 a.m.
Once upon a time, Thorsten Leemhuis <fedora(a)leemhuis.info> said:
- One DVD that can install both i386 and x86_64 (now that Intel
starts
shipping Celerons more and more people will try x86_64)
I don't think that's going to be very practical. There's already a good
bit of duplication in the distributed files and this would just add too
it.
I'd like to see a single source CD/DVD set (I know this is a non-trivial
thing, but it would be nice). The FTP site is structured with all the
SRPMS in the same directory; it would save a bunch of disk space if the
ISOs were common as well.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:01 p.m.
Am Donnerstag, den 02.06.2005, 12:20 -0400 schrieb Bill Nottingham:
Thorsten Leemhuis (fedora(a)leemhuis.info) said:
> - One DVD that can install both i386 and x86_64 (now that Intel starts
> shipping Celerons more and more people will try x86_64)
Won't fit. :)
(Yes, it's possible to get there, but you can't do it yet.)
Of course double layer DVDs or double side DVDs could be used. More an
more magazines ship with such beasts and double-layer DVD-burners are
not unusual anymore.
BTW, I know one german computer magazine that just announced that it
will ship with a DVD/CD combo-media soon (CD on one side, double layer
DVD on the other). On the DVD-Side there is a Suse-Live-Media and a
install versions of Suse for i386 and x86_64. On the CD side there is a
lot of windows software.
Something like that should be possible with Fedora, too. Maybe without
the Live-CD part for now.
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
12:04 p.m.
Thorsten Leemhuis (fedora(a)leemhuis.info) said:
> Won't fit. :)
> (Yes, it's possible to get there, but you can't do it yet.)
Of course double layer DVDs or double side DVDs could be used. More an
more magazines ship with such beasts and double-layer DVD-burners are
not unusual anymore.
Obviously, double-sided can be done right now. Are dual-layer *readers*
really that popular these days?
Heck, if they are that popular, we should drop CD images altogether!
Bill
12:10 p.m.
Hi.
Bill Nottingham <notting(a)redhat.com> wrote:
Obviously, double-sided can be done right now. Are dual-layer
*readers*
really that popular these days?
Am I missing some hidden joke here? All readers can do dual-layer.
--
"Shall I tell you what I want? What I really really want?"
12:28 p.m.
Am Donnerstag, den 02.06.2005, 19:10 +0200 schrieb Ralf Ertzinger:
Hi.
Bill Nottingham <notting(a)redhat.com> wrote:
> Obviously, double-sided can be done right now. Are dual-layer *readers*
> really that popular these days?
Am I missing some hidden joke here? All readers can do dual-layer.
Yes, all DVD-ROM should do that. (But yes, some have trouble with those
burned in dual-layer dvd-burners)
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
12:50 p.m.
Thorsten Leemhuis (fedora(a)leemhuis.info) said:
BTW, I know one german computer magazine that just announced that it
will ship with a DVD/CD combo-media soon (CD on one side, double layer
DVD on the other). On the DVD-Side there is a Suse-Live-Media and a
install versions of Suse for i386 and x86_64. On the CD side there is a
lot of windows software.
Something like that should be possible with Fedora, too. Maybe without
the Live-CD part for now.
The big issue with *this* is that the CD media might not be useful for
some CD players; see various online refs on DualDisc.
Bill
1:16 p.m.
Am Donnerstag, den 02.06.2005, 13:50 -0400 schrieb Bill Nottingham:
Thorsten Leemhuis (fedora(a)leemhuis.info) said:
> BTW, I know one german computer magazine that just announced that it
> will ship with a DVD/CD combo-media soon (CD on one side, double layer
> DVD on the other). On the DVD-Side there is a Suse-Live-Media and a
> install versions of Suse for i386 and x86_64. On the CD side there is a
> lot of windows software.
>
> Something like that should be possible with Fedora, too. Maybe without
> the Live-CD part for now.
The big issue with *this* is that the CD media might not be useful for
some CD players; see various online refs on DualDisc.
Okay. But that not our problem if magazines what to ship those discs
(and it seems they do) we should help them with that IMHO (if
possible).
Some may even ship only double layer dvds without the CD backside (if
x86_64 becomes more widespread they probably *will* have to ship both
x86_64 and i386 together). Any argument against those nearly normal DVDs
also? ;-)
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
9:41 a.m.
On Thu, 2005-06-02 at 20:16 +0200, Thorsten Leemhuis wrote:
Am Donnerstag, den 02.06.2005, 13:50 -0400 schrieb Bill Nottingham:
> The big issue with *this* is that the CD media might not be useful for
> some CD players; see various online refs on DualDisc.
Okay. But that not our problem if magazines what to ship those discs
(and it seems they do) we should help them with that IMHO (if
possible).
Magazines distributing CDs that don't work will hurt our reputation,
even though it may not be (directly) our fault. Given which type of
drives the discs are most likely to fail on, I think we should
discourage it.
--
Peter
2:47 p.m.
On Thu, 2005-06-02 at 07:25 +0200, Thorsten Leemhuis wrote:
- One DVD that can install both i386 and x86_64 (now that Intel
starts
shipping Celerons more and more people will try x86_64)
We already do this for PPC/PPC64. But it's a little saner there because
ppc32 isn't quite as crappy as i386 is -- so we actually end up using
mostly ppc32 userspace even on ppc64 hardware, just because there's
little point in being 64-bit. Whereas on x86_64 you almost always want
the 64-bit binaries just so you get a sane number of registers, so
there's much more duplication.
--
dwmw2
4:49 a.m.
Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Continue/support the RAM optimization work in gnome/X
Core-- && Extras++
Stateless
Better support for (kickstart) CD customization
--
Pádraig Brady - http://www.pixelbeat.org
--
5:19 a.m.
ons, 01.06.2005 kl. 19.59 skrev Elliot Lee:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Best,
-- Elliot
system-config-role
some setup tool where you could select a machines role using profiles -
examples:
- Laptop (ACPI, NetworkManager etc)
- Workstation (nothing special)
- LAMP server (setup apache, mysql, and PHP in a sane way)
- File/login-server (LDAP, NFS, Samba)
Surely you can make a lot of profiles. program runs as stand-alone and
in firstboot.
Could probably make it really easy to setup a server etc. - reducing
deployment time.
Kyrre
10:08 a.m.
New subject: Services, Roles and Xen [was whats next]
On Thu, 2005-06-02 at 12:19 +0200, Kyrre Ness Sjobak wrote:
ons, 01.06.2005 kl. 19.59 skrev Elliot Lee:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
>
> Best,
> -- Elliot
system-config-role
See below
- LAMP server (setup apache, mysql, and PHP in a sane way)
- File/login-server (LDAP, NFS, Samba)
Instead of a single role, it's better to have the ability to assign
individual services to individual machines, with each service having a
"meta-role" of Master( primary host for a resource ), Apprentice ( in
sync with Master ), or Backup ( as with Apprentice, but does not
actively serve ).
You configure the service for the Master server using a front end, which
also stores the details in a single generalized config file, which also
can be copied so it can be accessed at a given URI. When creating an
Apprentice or Backup service all you should need to do is declare the
URI of the Master file. When starting a init.d service, the back end
grabs the generalized config file and generates the appropriate /etc/
files. The front and back ends should also include the ability to use
encryption and digital signatures.
And if your going to do that, then why not have the option of for each
PC to load a master list of services and required rpm packages from a
single remote URI at boot time, pxeboot style.
some setup tool where you could select a machines role using profiles
-
examples:
- Laptop (ACPI, NetworkManager etc)
- Workstation (nothing special)
https://www.redhat.com/archives/fedora-devel-list/2005-April/msg00545.html
QUOTE
However, with a little scripted configuration, one OS install and one
mounted file system tree, should be able to perform all of the
following, one at a time, depending on boot flags and kernel
selection.
Native without Xen
Workstation : Run level 5
Graphical mode.
Runs most user applications locally.
Can host remote services ( httpd etc ).
X-Terminal : Run level 4?
LTSP like thin graphical client.
Runs most user applications remotely.
* Important for desktop support: you can fix the
normal workstation setup without any user downtime.
Server : Run level 3
Text mode.
Runs most user applications locally.
hosts remote services.
Repair : Run level 2
Text mode
Root login only.
Does not host remote services.
Xen domain 0
Xen + Domain 0 Workstation : Run level 5
Graphical mode ( assuming that AGP is compatible )
Should operate same as native workstation
Xen + Domain 0 X-Terminal : Run level 4?
Graphical mode ( assuming that AGP is compatible )
Can also log into local domain U servers.
Xen + Domain 0 Server : Run level 3
Text mode,
Xen + Domain 0 Monitor : Run level 2?
Text mode.
Minimal Xen host setup, plus network support.
Runs user application and services on domain U servers
NOTE : whatever runlevel the Xen domain 0 is running it would still
host/run the "xen" init.d Xen0 services.
Xen domain U
Note only two.
Domain U Server : Run level 3
Domain U Repair : Run level 2
UNQUOTE
Surely you can make a lot of profiles. program runs as stand-alone
and
in firstboot.
Could probably make it really easy to setup a server etc. - reducing
deployment time.
Kyrre
--
David Mohring <heretic(a)ihug.co.nz>
9:30 a.m.
Le Mercredi 1 Juin 2005 19:59, Elliot Lee a écrit :
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
A gnome navigator by defaut : firefox is not a good choice : it's in english
only and many localisation don't work.
Galeon or Epiphany are better choice for remplace Mozilla by defaut.
--
je sais pas di il y a quelqu'un sur internet à 1h48 mais j'aimerais bien
parler!
bisous
-+- poisson des iles In: Guide du linuxien pervers - "Bavardage..." -+-
9:03 a.m.
Le Jeudi 2 Juin 2005 18:21, Bill Nottingham a écrit :
Aph (liste-p.alain(a)wanadoo.fr) said:
> A gnome navigator by defaut : firefox is not a good choice : it's in
> english only and many localisation don't work.
Have you tried 1.0.4-4 from rawhide?
Yes ; what is new ? I have firefox in english ?! And anything change when I
apply a french localisation (error, ...). Idea for many users is a localized
program in defaut choice (navigator, mail, term, ...) ; with firefox, it's
"bricolage".
Regards.
12:29 a.m.
Aph (liste-p.alain(a)wanadoo.fr) said:
> > A gnome navigator by defaut : firefox is not a good choice
: it's in
> > english only and many localisation don't work.
>
> Have you tried 1.0.4-4 from rawhide?
Yes ; what is new ? I have firefox in english ?!
While I can't comment on the quality fo the translations, when
I run:
LANG=fr_FR.UTF-8 firefox
with 1.0.4-4, it does come up in French.
Bill
12:35 p.m.
Aph wrote:
Le Mercredi 1 Juin 2005 19:59, Elliot Lee a écrit :
>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
>Extras 5 - what major features are you willing to put effort into?
A gnome navigator by defaut : firefox is not a good choice : it's in english
only and many localisation don't work.
I added quite a few localizations installed by default into Fedora Core
4's version of Firefox. Try firefox-1.0.4-4 or later. From the changelog:
- Add support for locales:
af-ZA, ast-ES, ca-AD, cs-CZ, cy-GB, da-DK, de-DE, el-GR,
en-GB es-AR, es-ES, eu-ES, fi-FI, fr-FR, ga-IE, he-IL,
hu-HU, it-IT, ko-KR, ja-JP, ja-JPM, mk-MK, nb-NO, nl-NL,
pa-IN, pl-PL, pt-BR, pt-PT, ro-RO, ru-RU, sk-SK, sl-SI,
sq-AL, sv-SE, tr-TR, zh-CN, zh-TW
Galeon or Epiphany are better choice for remplace Mozilla by defaut.
Is your only complaints about Mozilla/Firefox the language issue? If
you strongly feel that those browsers are better choices, you should
qualify those with reasons to back your statement up. Making general
statements is no way to fix the issue. If I know what's wrong, I can
address it properly.
Thanks
1:43 p.m.
Christopher Aillon wrote:
> Galeon or Epiphany are better choice for remplace Mozilla by
defaut.
Is your only complaints about Mozilla/Firefox the language issue? If
you strongly feel that those browsers are better choices, you should
qualify those with reasons to back your statement up. Making general
statements is no way to fix the issue. If I know what's wrong, I can
address it properly.
As much as i like Firefox, it is not a Gnome application. It has lots of
settings that are direct duplicates of Gnome global settings (Proxy, Fonts,
...). Firefox doesn't quit when i type 'Ctrl-Q', you can't detach the menu
bars, nor change the menu shortcuts. You can't use Firefox to view HTML
directly into a Nautilus window (only Galeon can do this). Those are just a
few differences that come to mind.
-denis
1:54 p.m.
Once upon a time, Denis Leroy <denis(a)poolshark.org> said:
As much as i like Firefox, it is not a Gnome application.
...
Firefox doesn't quit when i type 'Ctrl-Q',
Neither do lots of GNOME applications, which is quite annoying. I
thought maybe GNOME had decided you weren't supposed to quit
applications and had deprecated that keyboard shortcut.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:56 p.m.
On Fri, 2005-06-03 at 13:54 -0500, Chris Adams wrote:
Once upon a time, Denis Leroy <denis(a)poolshark.org> said:
> As much as i like Firefox, it is not a Gnome application.
> ...
> Firefox doesn't quit when i type 'Ctrl-Q',
Neither do lots of GNOME applications, which is quite annoying. I
thought maybe GNOME had decided you weren't supposed to quit
applications and had deprecated that keyboard shortcut.
If you don't close applications then the startup time is that much
faster.... :)
/me runs.
-sv
2:02 p.m.
Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
If you don't close applications then the startup time is that
much
faster.... :)
Well, for the first couple of dozen apps anyway. :-)
I didn't actually notice Firefox didn't support ^Q for a while, because
I typically leave a few xterms and a browser running all the time. I
noticed the missing ^Q short-cut with gpdf and ggv first. ISTR others,
but I don't remember the names off the top of my head.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:39 a.m.
cmadams(a)hiwaay.net (Chris Adams) writes:
I didn't actually notice Firefox didn't support ^Q for a
while, because
I typically leave a few xterms and a browser running all the time. I
noticed the missing ^Q short-cut with gpdf and ggv first.
The question is, why simple viewers need two keystrokes to quit the
program. Existing viewers like 'less', 'more', 'info' or
'xpdf' need
only a simple 'Q' (instead of C-Q).
Enrico
10:01 a.m.
On Sat, Jun 04, 2005 at 10:39:49AM +0200, Enrico Scholz wrote:
The question is, why simple viewers need two keystrokes to quit the
program. Existing viewers like 'less', 'more', 'info' or
'xpdf' need
only a simple 'Q' (instead of C-Q).
I would assume because the GNOME people would like consistency across
the platform (that's what led to this discussion) and people feel it
would be annoying to put in extra keystrokes to shift more interactive
editors and other programs into a viewing mode where 'Q' would quit them.
Having 'Q' for some programs and 'CTRL-Q' for others would be annoying,
as this thread has shown.
John Thacker
10:50 a.m.
On Sat, Jun 04, 2005 at 11:01:28AM -0400, John Thacker wrote:
> The question is, why simple viewers need two keystrokes to quit
the
> program. Existing viewers like 'less', 'more', 'info' or
'xpdf' need
> only a simple 'Q' (instead of C-Q).
I would assume because the GNOME people would like consistency across
the platform (that's what led to this discussion) and people feel it
would be annoying to put in extra keystrokes to shift more interactive
editors and other programs into a viewing mode where 'Q' would quit them.
Having 'Q' for some programs and 'CTRL-Q' for others would be annoying,
as this thread has shown.
Well, not to mention that it'd be horribly bad if hitting one key closed
your web browser.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
12:24 p.m.
mattdm(a)mattdm.org (Matthew Miller) writes:
Well, not to mention that it'd be horribly bad if hitting one key
closed
your web browser.
My response was regarding
| noticed the missing ^Q short-cut with gpdf and ggv first.
and simple viewers should be controllable by one-key bindings.
Enrico
6:06 p.m.
On Sat, Jun 04, 2005 at 07:24:58PM +0200, Enrico Scholz wrote:
> Well, not to mention that it'd be horribly bad if hitting
one key closed
> your web browser.
My response was regarding
| noticed the missing ^Q short-cut with gpdf and ggv first.
and simple viewers should be controllable by one-key bindings.
Sorry, I misread -- I thought you were classing web browsers with "simple
[html] viewers".
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
12:22 p.m.
thacker(a)math.cornell.edu (John Thacker) writes:
Having 'Q' for some programs and 'CTRL-Q' for others
would be annoying,
as this thread has shown.
I do not think so. People distinguished between :wq, C-x C-c, q and C-q
for several decades, so why should viewers -- which are used mainly by
one-key bindings -- need suddenly two keystrokes for shutdown?
Enrico
2:18 p.m.
On Sat, Jun 04, 2005 at 07:22:14PM +0200, Enrico Scholz wrote:
thacker(a)math.cornell.edu (John Thacker) writes:
> Having 'Q' for some programs and 'CTRL-Q' for others would be
annoying,
> as this thread has shown.
I do not think so. People distinguished between :wq, C-x C-c, q and C-q
for several decades, so why should viewers -- which are used mainly by
one-key bindings -- need suddenly two keystrokes for shutdown?
Hmm. I seem to recall that when vi(m) is run as a viewer, with view,
it still requires :wq to shutdown. I don't think it would be a good
idea to have vi, when executed as view or in read-only mode, suddenly
switch keybindings and quit with one keystrokes. It's confusing to
be inconsistent. And what applies to vi as one application applies
to GNOME as a platform.
Yes, people did distinguish. I distinguished between :wq, used by a program
I used, and C-x C-c, used by a program I never used. Part of the reason
that I (and other people I know) don't use emacs is because I don't want
to bother to learn a whole other set of keyboard shortcuts. Similarly,
I know plenty of average users that use only emacs and never vi(m) for
the same reasons, as well as pico/nano users who want the same keyboard
shortcuts that they've had in pine for many years who avoid emacs and
vi.
Having lots of different keyboard shortcuts that differ across programs
is annoying for users, especially casual users. Since GNOME stresses
usability, it encourages common keyboard shortcuts. For several decades
plenty of people avoided UNIX-based systems because it was "hard to use,"
and learning esoteric keyboard commands for vi and a host of other
esoteric keyboard commands for emacs is one commonly-pointed to example
of it being hard to use, in my experience.
John Thacker
4:04 p.m.
On Sat, Jun 04, 2005 15:18:34 PM -0400, John Thacker
(thacker(a)math.cornell.edu) wrote:
Having lots of different keyboard shortcuts that differ across
programs
is annoying for users, especially casual users.
FWIW: I spend roughly 40% of my computer time in Emacs, 40% in
OpenOffice. Almost every day for several hours a day. So I'm not a
casual user of those two program. And I still curse every day because:
I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling
whatever was highlighted and being asked if I want to close the file
without saving.
I go Emacs after two hours of OO.o, hit C-s to save, and the program
stops until I remember that it's waiting for me to know what to
search.
Not that with VI it would be different. And using any other editor is
not an option for me, those two are the only ones I am sure to find,
with a decent configuration, on any *nix machine I have to work.
I'd switch to any Linux distro that came configured with the same
shortcuts for Emacs and OO.o in one second...
Ciao,
Marco
--
Marco Fioretti mfioretti, at the server mclink.it
Fedora Core 3 for low memory http://www.rule-project.org/
Non si vive se non il tempo che si ama. C. A. Helvetius
8:07 a.m.
On Sat, 2005-06-04 at 23:04 +0200, M. Fioretti wrote:
I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling
whatever was highlighted and being asked if I want to close the file
without saving.
You can change OOo's keybindings to that of Emacs, if you so incline.
Its an XML file edit away...
--
Colin Charles, http://www.bytebot.net/
10:59 a.m.
On Wed, Jun 08, 2005 06:07:35 AM -0700, Colin Charles
(byte(a)aeon.com.my) wrote:
On Sat, 2005-06-04 at 23:04 +0200, M. Fioretti wrote:
>
> I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling
> whatever was highlighted and being asked if I want to close the
> file without saving.
You can change OOo's keybindings to that of Emacs, if you so
incline. Its an XML file edit away...
I'd probably prefer to make Emacs behave as OO.o and others, but
thanks, I will look into this.
However (IIRC), I was making a general point, that is the fact that,
for users integration is often something very different, and simpler,
than what developers and packagers struggle to do.
Thanks again,
Marco
--
Marco Fioretti mfioretti, at the server mclink.it
Fedora Core 3 for low memory http://www.rule-project.org/
Excuse me for being greedy, but I want freedom and good government.
Both a flourishing economy and a well-cared-for earth. A society that
is diverse and communal.. that offers both privacy and accountability.
One that can afford a big conscience, along with lots of neat toys.
-- David Brin -- The Transparent Society
11:31 a.m.
byte(a)aeon.com.my (Colin Charles) writes:
> I go OO.o after two hours of Emacs, hit C-x C-W to save,
canceling
> whatever was highlighted and being asked if I want to close the file
> without saving.
You can change OOo's keybindings to that of Emacs, if you so incline.
Really? Does OOo support multi-keystroke actions (e.g. 'C-x C-s' for
save)?
Enrico
7:35 p.m.
On Wed, 2005-06-08 at 18:31 +0200, Enrico Scholz wrote:
>> I go OO.o after two hours of Emacs, hit C-x C-W to save,
canceling
>> whatever was highlighted and being asked if I want to close the
file
>> without saving.
>
> You can change OOo's keybindings to that of Emacs, if you so
incline.
Really? Does OOo support multi-keystroke actions (e.g. 'C-x C-s' for
save)?
It should. Look at editing
~/.openoffice.org2.0/user/config/soffice.cfg/global/accelerator/en-US
(basically anything in soffice.cfg), edit current.xml and have fun
Now, the catch, you need to read the StarOffice 6/7/8 Administrator
Guide to get the correct accels... I can't remember them off-hand
--
Colin Charles, http://www.bytebot.net/
FUDCon II @ LinuxTag
June 24-25, 2005 in Karlsruhe, Germany
http://fedoraproject.com/fudcon/
4:22 p.m.
Once upon a time, John Thacker <thacker(a)math.cornell.edu> said:
Hmm. I seem to recall that when vi(m) is run as a viewer, with
view,
it still requires :wq to shutdown.
You recall incorrectly. ":wq" is two commands: "w" is write and
"q" is
quit. If you are in view only mode, you can just ":q".
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
5:30 a.m.
thacker(a)math.cornell.edu (John Thacker) writes:
Having lots of different keyboard shortcuts that differ across
programs
is annoying for users, especially casual users. Since GNOME stresses
usability,
The "usability" stressed by Gnome2 is the usability expected by novice
Windoze users seeing Linux the first time. For experienced users, Gnome2
has a horrible usability: with every new minor version they make a 180
degree turn[1] without providing a transitition. Examples? The spastic
windowmode of nautilus appeared suddenly in existing installations
without a way to use the old one, the Emacs style bindings were suddenly
turned off in favor of the windoze like ones (and there are only hidden
ways to use the old one), a good webbrowser was replaced by something
with an experimental bookmarking which was never proved to be usefully
(and this thing still resists in ages of Firefox...), a powerful
windowmanager was replaced by a crippled something which is unable to do
the simplest things.
Perhaps, the "features" mentioned above could be provided in parallel
to the existing ones. But removing suddenly the old ones is the wrong
way. (FWIW, that's why I use KDE for my family; I am tired to explain
on every update why the old things do not work anymore).
it encourages common keyboard shortcuts.
The "common shortcuts" are probably the Emacs style ones (e.g. they are
used by *Emacs, bash and old versions of Gnome). I do not see a reason
why they could not be patched into Ooffice; RH is crippl^Wpatching other
programs (e.g. firefox) already, so Ooffice could become a little bit
more Unix-style also.
Enrico
Footnotes:
[1] they are very good in inventing new dimensions of unusability so do
not expected to reach the old direction ever
11:15 a.m.
On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote:
why they could not be patched into Ooffice; RH is crippl^Wpatching
other
programs (e.g. firefox) already, so Ooffice could become a little bit
Actually firefox support for unixlike keybindings is something from the Firefox
community rather than RH as I understand it.
3:25 a.m.
New subject: Firefox crippling (was: What next?)
alan(a)redhat.com (Alan Cox) writes:
On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote:
> why they could not be patched into Ooffice; RH is crippl^Wpatching other
> programs (e.g. firefox) already, so Ooffice could become a little bit
Actually firefox support for unixlike keybindings is something from
the Firefox community rather than RH as I understand it.
The broken (windoze-like) keybindings (which appear suddenly and without
prior confirmation although formerly the Unix like keybindings were
active) are probably caused by a Gnome2 misbehavior.
The firefox crippling is the result of %patch25-29 in the src.rpm: it
removes the functionality which allows to update extensions with
potential security leaks, and it replaces the nice looking default
icons with butt-ugly icons from a Gnome2 theme.
There exists a better patch for the first issue (which disables only
the capability to upgrade the application but still allows to update
extensions) but it is silently ignored by the firefox maintainer.
Regarding the ugly icons, I do not see how this change can be justified.
The new icons are objectively ugly, the default firefox icons are much nicer
and there are now some missing icons. So it seems that these icon patches
are only applied to satisfy some brainless Gnome2 ideas about consistent
lookout of applications (which might have different functionality and can
never have the same lookout therefore).
Based on the discussion regarding the "Firefox" branding, I do not see
how the FC4 firefox can be stilled named "Firefox" as it is destroys the
reputation of the project.
Enrico
6:23 a.m.
New subject: Firefox crippling (was: What next?)
On Mon, Jun 06, 2005 at 10:25:12AM +0200, Enrico Scholz wrote:
prior confirmation although formerly the Unix like keybindings were
active) are probably caused by a Gnome2 misbehavior.
As I understand it, it should pick up the preferences from your gnome
settings - ie if the emacs key support is on in gnome then firefox should
use them
[I find it funny people call it "Unix like" keybindings btw, historically its
nothing like 'unix keybindings' 8)]
I'm not too familiar with all the other bits you comment on.
8:12 a.m.
New subject: Firefox crippling
alan(a)redhat.com (Alan Cox) writes:
> prior confirmation although formerly the Unix like keybindings
were
> active) are probably caused by a Gnome2 misbehavior.
As I understand it, it should pick up the preferences from your gnome
settings - ie if the emacs key support is on in gnome then firefox
should use them
Yes, that's the Gnome2 misbehavior I am speaking about. There was a firefox
in an existing Gnome2 environment with emacs-style keybindings and from one
day to the other, these bindings did not work anymore. Using autoupdate
functionality for Gnome2 packages will be the total horror for the enduser
support...
Enrico
8:16 a.m.
New subject: Firefox crippling (was: What next?)
Once upon a time, Alan Cox <alan(a)redhat.com> said:
[I find it funny people call it "Unix like" keybindings
btw, historically its
nothing like 'unix keybindings' 8)]
^W is a Unix "delete previous word" keybinding. In Firefox now however
that closes the current window (quite annoying when you are editing a
significant text area, like a Bugzilla report, and want to delete the
last word quickly and instead close the window and lose everything
you've entered).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:41 a.m.
New subject: Firefox crippling (was: What next?)
On Mon, Jun 06, 2005 at 08:16:47AM -0500, Chris Adams wrote:
significant text area, like a Bugzilla report, and want to delete
the
last word quickly and instead close the window and lose everything
you've entered).
And if it closes without asking that would be a large bug for the mozilla
bugzilla..
9:07 a.m.
New subject: Firefox crippling (was: What next?)
--On Monday, June 06, 2005 8:16 AM -0500 Chris Adams <cmadams(a)hiwaay.net>
wrote:
Once upon a time, Alan Cox <alan(a)redhat.com> said:
> [I find it funny people call it "Unix like" keybindings btw,
> historically its nothing like 'unix keybindings' 8)]
^W is a Unix "delete previous word" keybinding.
I remember using that on TOPS-20 in the early 80's. Did it inherit the
command line hot keys from early Unix?
I usually get burned using control-W in the command buffer of Lugaru
Epsilon, a commercial Emacs clone (available for Win32, Linux, and BSD). In
that context it "wipes" everything back to the last mark, which if one
wasn't explicitly set, defaults to the start of the buffer. If I then
mindlessly yank, it pastes the entire command buffer into the current
command line. Fortunately this now generates a popup warning asking me if I
really want to paste 1000's of command lines. (Lugaru is very responsive to
user requests.)
9:11 a.m.
New subject: Firefox crippling (was: What next?)
On Mon, Jun 06, 2005 at 07:07:02AM -0700, Kenneth Porter wrote:
>^W is a Unix "delete previous word" keybinding.
I remember using that on TOPS-20 in the early 80's. Did it inherit the
command line hot keys from early Unix?
via emacs. Traditional unix never had 'delete word'. I suspect it may have
come via teco originally but lets not mention that too many times in case
it comes back to life ;)
Alan
9:29 a.m.
New subject: Firefox crippling (was: What next?)
Once upon a time, Alan Cox <alan(a)redhat.com> said:
On Mon, Jun 06, 2005 at 07:07:02AM -0700, Kenneth Porter wrote:
> >^W is a Unix "delete previous word" keybinding.
>
> I remember using that on TOPS-20 in the early 80's. Did it inherit the
> command line hot keys from early Unix?
via emacs. Traditional unix never had 'delete word'. I suspect it may have
come via teco originally but lets not mention that too many times in case
it comes back to life ;)
Are you sure ^W comes via emacs? Word erase is a TTY setting (look at
"stty -a"). ^U is line erase, ^R is redraw, and so on; these all work
in "true" Bourne shell on Unix systems.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:55 a.m.
New subject: Firefox crippling (was: What next?)
On Mon, Jun 06, 2005 at 09:29:52AM -0500, Chris Adams wrote:
Are you sure ^W comes via emacs? Word erase is a TTY setting (look
at
"stty -a"). ^U is line erase, ^R is redraw, and so on; these all work
in "true" Bourne shell on Unix systems.
Only on late system5 and after.
9:47 a.m.
New subject: Firefox crippling (was: What next?)
On Mon, 6 Jun 2005 10:11:10 -0400, Alan Cox <alan(a)redhat.com> wrote:
On Mon, Jun 06, 2005 at 07:07:02AM -0700, Kenneth Porter wrote:
> >^W is a Unix "delete previous word" keybinding.
>
> I remember using that on TOPS-20 in the early 80's. Did it inherit the
> command line hot keys from early Unix?
via emacs. Traditional unix never had 'delete word'. I suspect it may
have
come via teco originally but lets not mention that too many times in case
it comes back to life ;)
Alan
Can you really win by changing key bindings?
You might be able to do it with Firefox, but if you mess with my emacs
keybinding it will be just another application that gets the
rpm --erase ...
./configure
make
make install
treatment.
I use emacs on at least five different operating systems a day, it's bad
enough dealing with ^H-backspace-delete problems, I don't need to see it
changed. emacs is a solid application that really works, I find myself
losing work with emacs about once every two years. you can do whatever
you like with the half-working GUI "rpm --erase"ware that comes with RH,
but don't mess with tools I need to get work done.
(For instance, I need emacs so I can make configuration changes in 20
seconds that my coworker needs 20 minutes to do through the GUI because
the GUI screws things up and makes the machine go off the network.)
7:37 a.m.
New subject: Firefox crippling (was: What next?)
On Mon, Jun 06, 2005 at 10:25:12AM +0200, Enrico Scholz wrote:
The firefox crippling is the result of %patch25-29 in the src.rpm:
it
removes the functionality which allows to update extensions with
potential security leaks, and it replaces the nice looking default
icons with butt-ugly icons from a Gnome2 theme.
There exists a better patch for the first issue (which disables only
the capability to upgrade the application but still allows to update
extensions) but it is silently ignored by the firefox maintainer.
That'd be: <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136080>
To be a little more fair to the RH firefox maintainer, he's waiting for a
better-designed updates infrastructure from the upstream project. But I
think that's a bit over-optimistic and would really appreciate it if the
less-intrusive replacement patch were swapped in in the meantime.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
9:47 a.m.
New subject: Firefox crippling (was: What next?)
On 6/6/05, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de> wrote:
alan(a)redhat.com (Alan Cox) writes:
Based on the discussion regarding the "Firefox" branding, I do not see
how the FC4 firefox can be stilled named "Firefox" as it is destroys the
reputation of the project.
I vote for Red Baron.. but thats because I know the pain that I
inflicted that upon Red Hat 4.x :).
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
10:54 a.m.
New subject: Firefox crippling
Enrico Scholz wrote:
alan(a)redhat.com (Alan Cox) writes:
>On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote:
>
>>why they could not be patched into Ooffice; RH is crippl^Wpatching other
>>programs (e.g. firefox) already, so Ooffice could become a little bit
>
>Actually firefox support for unixlike keybindings is something from
>the Firefox community rather than RH as I understand it.
The broken (windoze-like) keybindings (which appear suddenly and without
prior confirmation although formerly the Unix like keybindings were
active) are probably caused by a Gnome2 misbehavior.
This is controlled by GNOME, actually. If you want the old bindings,
there is a setting you can add to your rc file which I don't remember
off the top of my head.
The firefox crippling is the result of %patch25-29 in the src.rpm:
it
removes the functionality which allows to update extensions with
potential security leaks, and it replaces the nice looking default
icons with butt-ugly icons from a Gnome2 theme.
Installing third party software, which includes Firefox extensions is
always at your own risk.
There exists a better patch for the first issue (which disables only
the capability to upgrade the application but still allows to update
extensions) but it is silently ignored by the firefox maintainer.
Better in whose eyes? I've already vocalized that upstream doesn't want
those patches in our tree. There is a plan to get this done right.
It's not done just yet. It missed the FC4 final cutoff but as soon as
the proper fix gets done, it will be included as an update if possible.
Regarding the ugly icons, I do not see how this change can be justified.
The new icons are objectively ugly, the default firefox icons are much nicer
and there are now some missing icons.
Thanks for the comments. Some share your opinion, some don't. I have
had many positive comments about them. And yes there have been a few
complaints. Much like some people prefer Firefox, some prefer Epiphany.
Some prefer GNOME, some prefer KDE. Some prefer to troll, some don't.
So it seems that these icon patches
are only applied to satisfy some brainless Gnome2 ideas about
consistent
lookout of applications (which might have different functionality and can
never have the same lookout therefore).
Hey, be fair. They are my brainless ideas, too.
Based on the discussion regarding the "Firefox" branding, I
do not see
how the FC4 firefox can be stilled named "Firefox" as it is destroys the
reputation of the project.
By getting the patches we use approved by upstream, as I make sure to
do. It's not really rocket science.
11:03 a.m.
New subject: Firefox crippling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christopher Aillon wrote:
Enrico Scholz wrote:
> alan(a)redhat.com (Alan Cox) writes:
>
>
>> On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote:
>>
>>> why they could not be patched into Ooffice; RH is crippl^Wpatching
>>> other
>>> programs (e.g. firefox) already, so Ooffice could become a little bit
>>
>>
>> Actually firefox support for unixlike keybindings is something from
>> the Firefox community rather than RH as I understand it.
>
>
>
> The broken (windoze-like) keybindings (which appear suddenly and without
> prior confirmation although formerly the Unix like keybindings were
> active) are probably caused by a Gnome2 misbehavior.
This is controlled by GNOME, actually. If you want the old bindings,
there is a setting you can add to your rc file which I don't remember
off the top of my head.
do you mean this in your $HOME/.gtkrc-2.0 ?
gtk-key-theme-name = "Emacs"
or if that doesn't work
include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc"
Em
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCpHPLl/fI0i0h13cRAlHSAJ9wgn6108Pd8SxpKfpfA1hUuswIYwCgiFR3
7LGVMeeAxvCRZdMhO7JoolU=
=fy5/
-----END PGP SIGNATURE-----
12:25 p.m.
New subject: Firefox crippling
Emily Brantley wrote:
Christopher Aillon wrote:
>Enrico Scholz wrote:
>>The broken (windoze-like) keybindings (which appear suddenly and without
>>prior confirmation although formerly the Unix like keybindings were
>>active) are probably caused by a Gnome2 misbehavior.
>
>
>This is controlled by GNOME, actually. If you want the old bindings,
>there is a setting you can add to your rc file which I don't remember
>off the top of my head.
do you mean this in your $HOME/.gtkrc-2.0 ?
gtk-key-theme-name = "Emacs"
or if that doesn't work
include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc"
Yeah, that's it.
12:51 p.m.
New subject: Firefox crippling
caillon(a)redhat.com (Christopher Aillon) writes:
> The broken (windoze-like) keybindings (which appear suddenly and
without
> prior confirmation although formerly the Unix like keybindings were
> active) are probably caused by a Gnome2 misbehavior.
This is controlled by GNOME, actually. If you want the old bindings,
there is a setting you can add to your rc file which I don't remember
off the top of my head.
I do not care whether Windoze or Emacs keybindings are the default
ones (as long as they can be configured). As expressed several times,
I am just pissed off by the Gnome2 practice to *override* existing
installations with their ideas of usability.
> The firefox crippling is the result of %patch25-29 in the
src.rpm: it
> removes the functionality which allows to update extensions with
> potential security leaks, and it replaces the nice looking default
> icons with butt-ugly icons from a Gnome2 theme.
Installing third party software, which includes Firefox extensions is
always at your own risk.
Having an update functionality helps to reduce this risk. But this
functionality was removed to avoid complains of novice users which try
to update the firefox application and get error messages.
> There exists a better patch for the first issue (which disables
only
> the capability to upgrade the application but still allows to update
> extensions) but it is silently ignored by the firefox maintainer.
Better in whose eyes?
Mmh... let's compare both patches:
current patch:
* removes functionality to update both firefox and extensions
* 4 files changed, 11 insertions(+), 10 deletions(-)
Matthew Miller's patch (bz #136080)
* removed only the functionality to update firefox
* 2 files changed, 2 insertions(+), 5 deletions(-)
So, the alternative patch is less intrusive and simpler, has the wanted
purpose and does not have unwanted side-effects.
I've already vocalized that upstream doesn't want those
patches in our
tree.
And upstream accepts the current patches?
> Regarding the ugly icons, I do not see how this change can be
justified.
> The new icons are objectively ugly, the default firefox icons are much
> nicer and there are now some missing icons.
Thanks for the comments. Some share your opinion, some don't. I have
had many positive comments about them.
Let me guess who gave these positive comments... Gnome2 developers... right?
And yes there have been a few complaints.
Why was there no response on these complaints? E.g. these about invisible
icons (#138986) or the uglyness of the icons itself (#138984, #138988).
Much like some people prefer Firefox, some prefer Epiphany. Some
prefer GNOME, some prefer KDE. Some prefer to troll, some don't.
Trolling is sometimes the only way when the bugreports are ignored...
Enrico
1:15 p.m.
New subject: Firefox crippling
Enrico Scholz wrote:
caillon(a)redhat.com (Christopher Aillon) writes:
>>The broken (windoze-like) keybindings (which appear suddenly and without
>>prior confirmation although formerly the Unix like keybindings were
>>active) are probably caused by a Gnome2 misbehavior.
>
>This is controlled by GNOME, actually. If you want the old bindings,
>there is a setting you can add to your rc file which I don't remember
>off the top of my head.
I do not care whether Windoze or Emacs keybindings are the default
ones (as long as they can be configured). As expressed several times,
I am just pissed off by the Gnome2 practice to *override* existing
installations with their ideas of usability.
So take your complaints up with the GNOME guys and stop pissing on me.
Your flaming is not going to make me care any more about you or your
causes. In fact, it is likely to make me care less.
Let me guess who gave these positive comments... Gnome2 developers...
right?
Several corporate types, a few members of various media organizations, a
bunch of artists, some users. A few geekier people have voiced their
distaste in them --- you know what? you're complaining about GNOME, not
Firefox. Go to a GNOME list instead and stop pissing on Firefox.
>And yes there have been a few complaints.
Why was there no response on these complaints? E.g. these about invisible
icons (#138986) or the uglyness of the icons itself (#138984, #138988).
Sorry, I just wontfixed them with clarification.
>Much like some people prefer Firefox, some prefer Epiphany. Some
>prefer GNOME, some prefer KDE. Some prefer to troll, some don't.
Trolling is sometimes the only way when the bugreports are ignored...z
Be careful, not all maintainers respond well to trolls. Trolling with
some people may result in more of your items ignored.
1:27 p.m.
New subject: Firefox crippling
caillon(a)redhat.com (Christopher Aillon) writes:
>>This is controlled by GNOME, actually. If you want the old
bindings,
>>there is a setting you can add to your rc file which I don't remember
>>off the top of my head.
> I do not care whether Windoze or Emacs keybindings are the default
> ones (as long as they can be configured). As expressed several times,
> I am just pissed off by the Gnome2 practice to *override* existing
> installations with their ideas of usability.
So take your complaints up with the GNOME guys
does not make fun... they always say: "only we are right, we are the
gods of usability, you are just a stupid user who does not have the
faintest idea about usability"...
> Let me guess who gave these positive comments... Gnome2
developers... right?
Several corporate types, a few members of various media organizations,
a bunch of artists, some users. A few geekier people have voiced
their distaste in them --- you know what? you're complaining about
GNOME, not Firefox.
No. I complain about firefox. Things are fine when removing patches
25-28 from the firefox src.rpm. I do not have to touch Gnome.
Enrico
8:59 p.m.
New subject: Firefox crippling
On Mon, 2005-06-06 at 20:27 +0200, Enrico Scholz wrote:
caillon(a)redhat.com (Christopher Aillon) writes:
>>>This is controlled by GNOME, actually. If you want the old bindings,
>>>there is a setting you can add to your rc file which I don't remember
>>>off the top of my head.
>> I do not care whether Windoze or Emacs keybindings are the default
>> ones (as long as they can be configured). As expressed several times,
>> I am just pissed off by the Gnome2 practice to *override* existing
>> installations with their ideas of usability.
>
> So take your complaints up with the GNOME guys
does not make fun... they always say: "only we are right, we are the
gods of usability, you are just a stupid user who does not have the
faintest idea about usability"...
Personally, I've filed dozens of usability bugs against gnome and for
the most part they have been taken very seriously. The developers (and
I am not a Gnome developer) seem to respond very positively to me
comments on usability.
My experience is that Gnome developers do not think they are "", and are
more than willing to address usability issues.
Food for thought:
Maybe this isn't a usability issue, but instead is a personal peeve
about how you think it should work.
Maybe it has to do with how you approach the situation.
Maybe it has to do with just accepting that other view points are also
valid. At least you can complain - go try that with Windows were the
decision is made without your input and you simply can't complain to the
developers.
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
2:52 p.m.
New subject: Firefox crippling
rodd(a)clarkson.id.au (Rodd Clarkson) writes:
> >> I do not care whether Windoze or Emacs keybindings are
the default
> >> ones (as long as they can be configured). As expressed several
> >> times, I am just pissed off by the Gnome2 practice to *override*
> >> existing installations with their ideas of usability.
> >
> > So take your complaints up with the GNOME guys
>
> does not make fun... they always say: "only we are right, we are the
> gods of usability, you are just a stupid user who does not have the
> faintest idea about usability"...
Personally, I've filed dozens of usability bugs against gnome and for
the most part they have been taken very seriously.
Do you remember the spartial window management in nautilus? It was a
completely experimental feature, it was tried only by a very small
userbase before, there were lot of critical voices against it -- and
the Gnome2 developers actived it without providing a way to turn it
off, and it was activated on every existing system.
Ditto for epiphany -- its experimental bookmark management was never proved
to be useful but everybody was forced to use it. Or metacity... there are
lot of wishes which are all rejected because configurability is assumed as
evil by Gnome2 developers. Or the ~/.Xmodmap + ~/.Xresources files: Gnome2
developers do not accept that people want to configure their system by
these methods and there does not exist a way to stop Gnome2 to override the
settings of these files; only stupid suggestions to delete/edit files in
/usr/share/... (which will be overridden by the next auto-update).
Or the recent firefox discussions... there are lot of critical voices
against the Gnomeification but they are rejected without giving a reason
or responding to other suggestions.
Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly
software should adapt to the user, but with Gnome2 the user has to adapt
to the software. This is caused by the refusal of Gnome2 developers to
allow configuration of their software and the frequent changes of the
user interface.
Enrico
3:23 p.m.
New subject: Firefox crippling
Altogether, Gnome2 is a very unergonomic piece of software.
Userfriendly
software should adapt to the user, but with Gnome2 the user has to adapt
to the software. This is caused by the refusal of Gnome2 developers to
allow configuration of their software and the frequent changes of the
user interface.
Any claim like this should probably start with a definition of user ;-).
I would imagine that someone who does, say, marketing, would never
configure their desktop (for better or worse).
3:55 p.m.
New subject: Firefox crippling
On Wed, Jun 08, 2005 at 04:23:01PM -0400, Richard Li wrote:
>Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly
>software should adapt to the user, but with Gnome2 the user has to adapt
>to the software. This is caused by the refusal of Gnome2 developers to
>allow configuration of their software and the frequent changes of the
>user interface.
>
Any claim like this should probably start with a definition of user ;-).
I would imagine that someone who does, say, marketing, would never
configure their desktop (for better or worse).
Yes, and shipping a large combination of software with dramatically
different icons and keyboard shortcuts for the same tasks forces a
user to adapt to the software, and can hardly be considered user friendly.
I agree that user configuration should be allowed (and I believe that
the gconf setting that turns off spatial Nautilus was available right
at the release of GNOME 2.6.0, not that using gconf is user friendly).
However, while changing an application from its original defaults to
something consistent with other applications does force people who have
gotten used to the original application to adapt, having a bunch of
inconsistent applications also forces users to adapt too.
So long as experienced users can configure things if they want to,
I think that consistency across the desktop is a much better default.
It makes things easier for the people who are most likely to have
trouble, people seeing things for the first time. Experienced users
are more likely to be able to figure out how to set their configuration.
John Thacker
4:38 p.m.
New subject: Firefox crippling
thacker(a)math.cornell.edu (John Thacker) writes:
> >Altogether, Gnome2 is a very unergonomic piece of software.
Userfriendly
> >software should adapt to the user, but with Gnome2 the user has to adapt
> >to the software. This is caused by the refusal of Gnome2 developers to
> >allow configuration of their software and the frequent changes of the
> >user interface.
> >
> Any claim like this should probably start with a definition of user ;-).
I think on my mother which was not very amused when the desktop had a
completely different behavior after the Gnome2.4->2.6 upgrade. Or on me,
who wants to use his ~/.Xmodmap and ~/.Xresources files and is stopped
in this by the arrogance of the Gnome2 developers.
> I would imagine that someone who does, say, marketing, would
never
> configure their desktop (for better or worse).
Yes, and shipping a large combination of software with dramatically
different icons and keyboard shortcuts for the same tasks forces a
user to adapt to the software, and can hardly be considered user
friendly.
1. The default firefox icons are not "dramatically different" from the
default Gnome2 icon theme
2. I do not care about the default setting as long as:
- it can be configured
- does not override current settings
3. What is the meaning of "different"? Different to what? Firefox is the
only Gnome2 application I am using, so why am I forced to see these
ugly icons?
I do not know KDE, but I can imagine that people with this desktop
environment will be shocked also when they see the current firefox
icons; they probably do not match the KDE theme neither.
Enrico
5:14 p.m.
New subject: Firefox crippling
On Wed, Jun 08, 2005 at 11:38:16PM +0200, Enrico Scholz wrote:
1. The default firefox icons are not "dramatically
different" from the
default Gnome2 icon theme
2. I do not care about the default setting as long as:
- it can be configured
- does not override current settings
But weren't you complaining about the change to spatial nautilus?
Your complaint there, it seems, is because of the dramatic change
in behavior between people who had GNOME 2.4 and upgraded. But I know
plenty of people who *do* want current settings to be overriden, at
least in the case where they always used the previous application default
and never set any sort of special configuration. So many users never
change the default preferences, and they want any genuinely useful
or cool new feature to be enabled by default; they don't want to have
to specifically enable everything in the new release. They don't want
to have to be that familiar with every detail of their program. Especially
when you're changing the UI, it's rather crazy to make users specifically
select from a list of preferences many options in order to change to the new
look and feel. That violates user friendliness as well.
People who hate some change should be able to change it back, certainly.
3. What is the meaning of "different"? Different to what?
Firefox is the
only Gnome2 application I am using, so why am I forced to see these
ugly icons?
I'm impressed that you're familiar enough with the Gnome2 icon theme
to make the statement in 1. despite not using any Gnome2 applications.
I'm furthermore impressed that you can argue simultaneously that the
icons are not all that different, yet very ugly. I can see the
position, I suppose.
Largely you see those icons by default because GNOME is the default
desktop for Fedora. There are plenty of reasons to make the default
desktop have consistent icons; it's absolutely a core principle
of user friendliness. The default certainly has to be something, and
that is the most logical choice. Admittedly, from the user perspective
of someone who uses Firefox on multiple different operating systems,
it's not the greatest either. (In the same way, there is a reasonable
argument for key shortcuts which are close to Windows, too.) There's
nothing forcing you to see those icons, though. There are plenty
of ways around it. A unified look to the desktop, like similar
keyboard shortcuts, are kinder to users than everything being
different.
You mentioned not using KDE; RedHat got a lot of grief for a similar
decision to develop Bluecurve in order to have a unified look throughout
the desktop. (Bero left around when 8.0 was released over this.)
From any usability standpoint, it makes sense. I'm a little confused;
are you complaining partially because you only use GUI apps which are
too difficult to make look consistent to be worth the effort to do so?
John Thacker
1:12 a.m.
New subject: Firefox crippling
thacker(a)math.cornell.edu (John Thacker) writes:
> 1. The default firefox icons are not "dramatically
different" from
> the default Gnome2 icon theme
>
> 2. I do not care about the default setting as long as:
> - it can be configured
> - does not override current settings
But weren't you complaining about the change to spatial nautilus?
Your complaint there, it seems, is because of the dramatic change in
behavior between people who had GNOME 2.4 and upgraded. But I know
plenty of people who *do* want current settings to be overriden,
Then, such dramatical changes should be done in an user friendly
manner. E.g. pop up a dialog box saying "We invented a new feature... Do
you want to use this or do you want to stay at the current behavior? You
can toggle between both by Settings -> ...".
> 3. What is the meaning of "different"? Different to
what? Firefox is the
> only Gnome2 application I am using, so why am I forced to see these
> ugly icons?
I'm impressed that you're familiar enough with the Gnome2 icon theme
to make the statement in 1. despite not using any Gnome2 applications.
??? I see the butt-ugly Gnome2 icons when I upgrade firefox from RH
sources. I see the nice looking default icons when I recompile the
.src.rpm after removing patches 25-28.
I'm furthermore impressed that you can argue simultaneously that
the
icons are not all that different, yet very ugly.
In both, "go back/forward" are symbolized by arrows, "go home" by a
house,
... But the Gnome2 icons are butt-ugly (intrusive default bookmark [1],
erroneously [2], the 4-color icons were perhaps beatiful in the ages of
CGA graphics). Corresponding bug reports and user wishes were completely
ignored by Gnome2 developers.
(In the same way, there is a reasonable argument for key shortcuts
which are close to Windows, too.)
That's another problem of Gnome2; it tries to satisfy the novice Windoze
user seeing Linux the first time. But it completely ignores the existing
Linux userbase which learned to configure their systems with ~/.X* files
or by editing files.
There's nothing forcing you to see those icons, though.
RH/Gnome2 *is* forcing me to see these butt-ugly icons; there is no
simple way to enable the standard icons. Recompiling firefox does not
count; installing the resulting package might be complicated till
impossible (no root perms).
You mentioned not using KDE; RedHat got a lot of grief for a similar
decision to develop Bluecurve in order to have a unified look throughout
the desktop. (Bero left around when 8.0 was released over this.)
Yes, he was probably pissed off the ignorance of the Gnome2 developers
who are enforcing their ideas ("we are always right"). Best, what I
heard about the RH KDE is "wow, it looks really like Gnome. But please,
can you restore the defaults?".
From any usability standpoint, it makes sense. I'm a little
confused;
are you complaining partially because you only use GUI apps which are
too difficult to make look consistent to be worth the effort to do so?
I am complaining about the arrogance of the Gnome2 developers which
* stops me to use ~/.Xmodmap + ~/.Xresources, without providing a way to
disable the broken gnome-settings-daemon behavior
* enforces butt-ugly icons in firefox, without providing a way to use
the default ones
* overrides existing user-configurations
Enrico
Footnotes:
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138984
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=106558
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138986
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=106559
1:29 a.m.
New subject: Firefox crippling
On Wed, 2005-06-08 at 23:38 +0200, Enrico Scholz wrote:
I do not know KDE, but I can imagine that people with this
desktop
environment will be shocked also when they see the current firefox
icons; they probably do not match the KDE theme neither.
I use KDE and FF, but "shocked" is a bit strong expression to describe
what I felt when first seeing these new icons. A strong dislike would
be more accurate.
Anyway, these icons made me realize that I never use the home or reload
buttons anyway, so I got rid of them. Part of the problem solved.
Other parts of the problem still remain. I do agree that replacing the
default theme of a themeable browser, and while at it, making it
impossible to switch back to the original doesn't sound like a good
idea. (I haven't studied the theming in-depth, so there might be
inaccuracies here.)
BTW, the "Firefox (default) 2.0" theme which AFAICT is now no longer
what it says in the FF themes UI is still "credited" to the original
upstream authors.
4:29 p.m.
New subject: Firefox crippling
Le mercredi 08 juin 2005 à 16:23 -0400, Richard Li a écrit :
>Altogether, Gnome2 is a very unergonomic piece of software.
Userfriendly
>software should adapt to the user, but with Gnome2 the user has to adapt
>to the software. This is caused by the refusal of Gnome2 developers to
>allow configuration of their software and the frequent changes of the
>user interface.
>
>
Any claim like this should probably start with a definition of user ;-).
I would imagine that someone who does, say, marketing, would never
configure their desktop (for better or worse).
What a strange things to say.
Marketing people _love_ eye-candy and fancy stuff. That's why they are
in marketing.
--
Nicolas Mailhot
5:18 p.m.
New subject: Firefox crippling
On Wed, Jun 08, 2005 at 11:29:30PM +0200, Nicolas Mailhot wrote:
Le mercredi 08 juin 2005 à 16:23 -0400, Richard Li a écrit :
> >Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly
> >software should adapt to the user, but with Gnome2 the user has to adapt
> >to the software. This is caused by the refusal of Gnome2 developers to
> >allow configuration of their software and the frequent changes of the
> >user interface.
> Any claim like this should probably start with a definition of
user ;-).
>
> I would imagine that someone who does, say, marketing, would never
> configure their desktop (for better or worse).
What a strange things to say.
Marketing people _love_ eye-candy and fancy stuff. That's why they are
in marketing.
Yes, but they don't tend to configure their desktop outside of things
like desktop wallpaper, screen savers, and, say, WinAMP skins.
Marketing people like eyecandy and fancy stuff and choices when it
comes to *producing* things for their work. That doesn't mean that
they want to fiddle with a bunch of choices about what double-clicking
on a title bar does or whether their windows auto-raise on mouseover.
Nor have I ever seen a marketing person who was interested in customizing
their keyboard shortcuts-- outside of complaining if they didn't all
basically work like Microsoft Office shortcuts for similar tasks.
John Thacker
4:01 p.m.
New subject: Firefox crippling
On Wed, 2005-06-08 at 21:52 +0200, Enrico Scholz wrote:
Do you remember the spartial window management in nautilus? It was a
completely experimental feature, it was tried only by a very small
userbase before, there were lot of critical voices against it -- and
the Gnome2 developers actived it without providing a way to turn it
off, and it was activated on every existing system.
It was always possible to turn it off, but in order to get _more_
testing it wasn't made obvious to begin with. Nowadays it's right there
in
Edit->Preferences. You're getting awfully close to red herrings here!
Ditto for epiphany -- its experimental bookmark management was never
proved
to be useful but everybody was forced to use it.
Epiphany was never meant to be all things to all people, if you don't
like it then use another web browser. Its purpose is to be an easy-to-
use non-intimidating browser. By the way, basically what you are asking
here is that the authors write a _different_ bookmark system from what
they want, in addition to the one they want.
Or metacity... there are
lot of wishes which are all rejected because configurability is assumed as
evil by Gnome2 developers.
To some extent, configurability _is_ evil, especially when it's done
instead of just doing things right. More generally, options have a cost,
both to the developer and the user. Have you even cared to read Havoc's
(now somewhat old, but still generally relevant) article on this?
http://www.ometer.com/free-software-ui.html
(especially the section on options a bit down.)
Altogether, Gnome2 is a very unergonomic piece of software.
Userfriendly
software should adapt to the user, but with Gnome2 the user has to adapt
to the software. This is caused by the refusal of Gnome2 developers to
allow configuration of their software and the frequent changes of the
user interface.
I'm a Gnome user and have been for a long time and the only really major
shift that I noticed and cared about was when Nautilus went spatial.
In principle I think the debate here might be between trying to keep
compatibility with old cruft (with rather few users) or to try to build
the best system for the future (i.e. something that will attract users
who have Windows and Mac experience and couldn't care less about hacking
config files in order to get some sanity to a desktop.)
/Per
4:28 p.m.
New subject: Firefox crippling
perbj(a)stanford.edu (Per Bjornsson) writes:
> Do you remember the spartial window management in nautilus? It
was a
> completely experimental feature, it was tried only by a very small
> userbase before, there were lot of critical voices against it -- and
> the Gnome2 developers actived it without providing a way to turn it
> off, and it was activated on every existing system.
It was always possible to turn it off, but in order to get _more_
testing it wasn't made obvious to begin with.
Abusing users as beta testers is known from other companies also...
Nowadays it's right there in Edit->Preferences.
But it still does not respect current settings (was Gnome2.4 running
previously, then use normal window mode. Else, use the default spatial
mode), right?
> Or metacity... there are lot of wishes which are all rejected
because
> configurability is assumed as evil by Gnome2 developers.
To some extent, configurability _is_ evil, especially when it's done
instead of just doing things right.
That's why I said, that Gnome2 developers think that they are gods
because only they know what is right and what is not. But in most
cases, the right thing is to make it configurable; you will find a
common base only very seldom.
More generally, options have a cost, both to the developer and the
user. Have you even cared to read Havoc's (now somewhat old, but still
generally relevant) article on this?
http://www.ometer.com/free-software-ui.html (especially the section on
options a bit down.)
Yes, this paper is one of the root of the Gnome2 evil. Gnome2 developers
read it and think that they should program after it. E.g. because Gnome2
developers always think, they are right (see above), they assume that
everybody wants Emacs in the colors of the default theme. So they do not
care about existing ~/.Xresources entries and there is not way (not even
in the registry) to turn off this behavior. Ditto for ~/.Xmodmap. Or as
this thread shows, Gnome2 developers assume that everybody wants theme
icons in firefox and do not allow to configure it in another way.
Enrico
9:39 a.m.
New subject: Firefox crippling
ons, 08,.06.2005 kl. 23.28 +0200, skrev Enrico Scholz:
perbj(a)stanford.edu (Per Bjornsson) writes:
>> Do you remember the spartial window management in nautilus? It was a
>> completely experimental feature, it was tried only by a very small
>> userbase before, there were lot of critical voices against it -- and
>> the Gnome2 developers actived it without providing a way to turn it
>> off, and it was activated on every existing system.
>
> It was always possible to turn it off, but in order to get _more_
> testing it wasn't made obvious to begin with.
Abusing users as beta testers is known from other companies also...
Can we stop with the shit slinging and throwing around hints that GNOME
== Windows please?
> Nowadays it's right there in Edit->Preferences.
But it still does not respect current settings (was Gnome2.4 running
previously, then use normal window mode. Else, use the default spatial
mode), right?
The decision was made to use spatial as default, can you seriously still
be offended by having to flick a switch two years later? You sure know
how to hold a grudge :-)
>> Or metacity... there are lot of wishes which are all rejected because
>> configurability is assumed as evil by Gnome2 developers.
>
> To some extent, configurability _is_ evil, especially when it's done
> instead of just doing things right.
That's why I said, that Gnome2 developers think that they are gods
because only they know what is right and what is not. But in most
cases, the right thing is to make it configurable; you will find a
common base only very seldom.
And some people are more interested in tweaking settings that actually
doing work. Seriously, the argument is that every preference comes with
a cost. That cost is on the maintainer since the maintainer has to deal
with bugs in the code, porting to new interfaces, documenting things
etc. This is one of the main arguments against preferences. Not that the
user interface should be dumbed down so that "newbies" don't get scared
off or that one should mimick other OSes just for the fun of it.
The GNOME project definitely is influenced by design choices of other
desktops and OSes, but it's not like we blindly follow either one of
them and have no opinion of our own.
> More generally, options have a cost, both to the developer and the
> user. Have you even cared to read Havoc's (now somewhat old, but still
> generally relevant) article on this?
> http://www.ometer.com/free-software-ui.html (especially the section on
> options a bit down.)
Yes, this paper is one of the root of the Gnome2 evil. Gnome2 developers
read it and think that they should program after it. E.g. because Gnome2
developers always think, they are right (see above), they assume that
everybody wants Emacs in the colors of the default theme. So they do not
care about existing ~/.Xresources entries and there is not way (not even
in the registry) to turn off this behavior. Ditto for ~/.Xmodmap. Or as
this thread shows, Gnome2 developers assume that everybody wants theme
icons in firefox and do not allow to configure it in another way.
AFAIK there is code in gnome-settings-daemon to merge stuff from both
Xmodmap and Xresources, maybe the daemon just has bugs that were never
filed because someone decided to flame and rant about the issue because
they thought it was a conscious decision to fuck users over?
You know where bugzilla is if that's the case.
Cheers
Kjartan
11:28 a.m.
New subject: Firefox crippling
kmaraas(a)broadpark.no (Kjartan Maraas) writes:
> But it still does not respect current settings (was Gnome2.4
running
> previously, then use normal window mode. Else, use the default spatial
> mode), right?
>
The decision was made to use spatial as default, can you seriously still
be offended by having to flick a switch two years later?
There has nothing been changed in these two years on the Gnome2 practice to
enforce the Gnome2 ideas of "usability". The Emacs -> Windoze keybindings
were introduced silently without a smooth transition, the ~/.X* files were
made pointless, Firefox was crippled, ...
> So they do not care about existing ~/.Xresources entries and
there is
> not way (not even in the registry) to turn off this behavior. Ditto
> for ~/.Xmodmap...
>
AFAIK there is code in gnome-settings-daemon to merge stuff from both
Xmodmap and Xresources, maybe the daemon just has bugs that were never
filed because someone decided to flame and rant about the issue because
they thought it was a conscious decision to fuck users over?
You know where bugzilla is if that's the case.
Filing bugs regarding Gnome2 usability is senseless; Gnome2 developers think
that they are the gods of usability and reject anything which is against
their ideas. E.g. regarding ~/.Xresources read [1]: instead of adding an
appropriate configuration option, Gnome2 developers give worthless responses
like "if you do not like it, delete files under /usr/share/...". Perhaps a
good practice under Windoze, but does not work in Linux where I might have
no perms for that or the next autoupdate will override my "settings".
Similarly for ~/.Xmodmap in [2]. And regarding firefox, the BZ tickets
were told in this thread already.
Enrico
Footnotes:
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103521
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117221
11:43 a.m.
New subject: Firefox crippling
On Thu, Jun 09, 2005 at 06:28:30PM +0200, Enrico Scholz wrote:
Filing bugs regarding Gnome2 usability is senseless; Gnome2 developers think
that they are the gods of usability and reject anything which is against
their ideas.
<shrug>
I haven't noticed that. I have noticed that they tend to stick very tightly
to a set of usability rules (which are approved and allow modification)
which follow well-known guidelines that have been tested experimentally
and with ordinary users by many, many companies and programmers. They
don't seem to think that they are the "gods of usability"; if anything,
they're following in the footsteps of a large amount of research and
discussion from everyone in the industry.
The only person I see as setting himself up as a "god of usability" is
you, who apparently gets strongly upset whenever any one of your ideas
is rejected. This despite that almost all of your suggestions that
I've seen go against every well-known and well-tested concept of
usability. It's easy enough to point you to books, essays, and research
on the topic of usability (I believe that earlier someone pointed to
links to chapters from Joel Spolsky's book, for example) that disagree
with you. People aren't disagreeing with you out of arrogance or
refusal to listen; they're disagreeing with you because there is real
data to back their side. I don't doubt that your suggestions would
make life easier for you personally, but they don't apply to users
in general.
I'm not going to reply anymore, though; fedora-desktop-devel or
some of the GNOME desktop mailing lists are better places for this
sort of thing.
John Thacker
7:52 p.m.
New subject: Firefox crippling
Christopher Aillon wrote:
> Why was there no response on these complaints? E.g. these about
invisible
> icons (#138986) or the uglyness of the icons itself (#138984, #138988).
Sorry, I just wontfixed them with clarification.
One legitimate problem with the GNOMEification is that there is no way
to switch the Firefox theme back to the upstream original. It would be
nice if we had this capability, but not a priority.
Warren Togami
wtogami(a)redhat.com
4:09 p.m.
New subject: Firefox crippling
Enrico Scholz wrote:
I do not care whether Windoze or Emacs keybindings are the default
ones (as long as they can be configured). As expressed several times,
I am just pissed off by the Gnome2 practice to *override* existing
installations with their ideas of usability.
You speak for me, this has also been an enormous source of frustration over
the past few years, and filing bugs on bugzilla.gnome.org to ask for better
configurability always result in absolute ignorance. The worst for me was
switching from the 3rd button to the middle button to perform interactive
window resizing, almost impossible to do on a mouse on which the middle button
is a wheel (ie. all Logitech mice). Fortunately, that's an easy enough
metacity patch. I know those are all GNOME issues, but Fedora, being one of
the big Gnome "client" (read, supporter), should have considerable influence
over them. Just as an example, if Fedora were to ditch Metacity, or Epiphany,
or some other Gnome default, based on Fedora users feedback, it would send a
powerful message...
-denis
7:56 a.m.
On Wed, 1 Jun 2005, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
I'd like to see Fedora Core continue to slim down, and apps which largely
duplicate functionality continue to move into Extras
One proposal: postfix in core, sendmail in extras. Vice-versa would be
fine too, but I think Postfix makes more sense for core than sendmail -
the design is more amenable to SELinux, and the configuration files are
simpler for new users to parse
Of course, really slimming core requires support for generating cds of
extras....
later,
chris
8:35 a.m.
On 6/3/05, Chris Ricker <kaboom(a)oobleck.net> wrote:
Of course, really slimming core requires support for generating cds
of
extras....
Does anyone have any contacts with 3rd party media vendors like for
example cheapbytes?
If someone is going to tackle how to split up extras into cd sized
chunks.. clearly media vendors as well as lugs are going to end up
being the primary consumers of those media images and then they would
in turn redistributed to users. I think ideally you would want some
input from media vendors as to what would be ideal for them.
-jef
8:57 a.m.
New subject: dkms coreward for fc5? (was Re: What next?)
On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Now that dkms is in Extras... and fc4 has kernel modules in Core.
How about for fc5 we put dkms in Core and have the kernel modules in
Core use dkms to alleviate some of the sync issues we saw this time
around in rawhide.
I know the kernel module maintainer in Core is trying hard to keep on
the ball about keeping up with the kernel builds, and I have no doubts
that kernel module packages in Core will be made available asap after
an update kernel is released... but i don't think thats always going
to be simultaneous. dkms could really help out and provide the client
side stopgap during the hours when a critical kernel update comes out
and a new set of clustering kernel module packages are built and
available for updating. This also sets up the groundwork for providing
useful kernel modules in Extras. I fully expect future kernel modules
in Extras to lag a kernel update by a day or two, and having dkms in
Core for Extras packagers to rely on to provide a client side module
rebuild in the lagtime would be useful.
And.. I'm willing to actually help test and implement this with regard
to the core kernel module packages.
-jef"is really just hoping for a heated technical debate"spaleta
9:26 p.m.
New subject: dkms coreward for fc5? (was Re: What next?)
On Fri, 2005-06-03 at 09:57 -0400, Jeff Spaleta wrote:
On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
Now that dkms is in Extras... and fc4 has kernel modules in Core.
How about for fc5 we put dkms in Core and have the kernel modules in
Core use dkms to alleviate some of the sync issues we saw this time
around in rawhide.
DKMS doesn't solve the problem of the dependencies for the packages not
matching, so it feels to me like you're just trying to be a troll. But
I'll bite ;-)
As far as I'm concerned, DKMS solves the wrong problem. As long as the
user has to have a compiler installed to use it, it's not useful. As
long as it's not an integrated part of the packaging system, it's not
useful.
That said, I think that cleaning up the interaction for kernel module
packages and ensuring that everything is cleanly defined such that it
can work is a good goal for FC5 and I'm willing to help out some to make
it happen. Spot and I talked briefly about this in New Orleans and I
think the plan is to restart that discussion after he gets back from a
(much needed and deserved) vacation.
Once _that_ is defined, then we can think about buildsystem triggers to
ensure that the packages get rebuilt in a timely fashion and that the
tree thus stays sane.
Jeremy
12:34 a.m.
New subject: dkms coreward for fc5? (was Re: What next?)
Am Sonntag, den 05.06.2005, 22:26 -0400 schrieb Jeremy Katz:
On Fri, 2005-06-03 at 09:57 -0400, Jeff Spaleta wrote:
> On 6/1/05, Elliot Lee <sopwith(a)redhat.com> wrote:
> > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> > Extras 5 - what major features are you willing to put effort into?
>
> Now that dkms is in Extras... and fc4 has kernel modules in Core.
> How about for fc5 we put dkms in Core and have the kernel modules in
> Core use dkms to alleviate some of the sync issues we saw this time
> around in rawhide.
I'm against using DKMS in core. IMHO it solves the problem in the wrong
way. It was nice in the 2.4 days but IMHO the overhead from dkms with
2.6 kernels is way to much.
But to be more productive: Lets discuss kernelmodule packaging, dkms and
the issues with updateing kernel-module packages somewhere on the lists.
Especially with those who maintain kernel-module packages already for a
long time (Ville, moZer, C. Feist, me are the first who come to my mind;
surely i missed someone). If we agree on dkms then I have no problem
with it. But saying "we have X in extras so let use it in core now" is
IMHO the wrong approach (and maybe stupid).
DKMS doesn't solve the problem of the dependencies for the
packages not
matching,
And not the yum update problem for those who don't want to install
gcc-stuff.
CU
thl
9:41 a.m.
New subject: dkms coreward for fc5? (was Re: What next?)
On 6/5/05, Jeremy Katz <katzj(a)redhat.com> wrote:
DKMS doesn't solve the problem of the dependencies for the
packages not
matching, so it feels to me like you're just trying to be a troll. But
I'll bite ;-)
Whatever it takes to get the kernel module discussion restarted. It
sort of died in the packaging list when it came up before. I'm more
than happy to wait for spot to come back and discussion can begin in
earnest in the packaging list.
Once _that_ is defined, then we can think about buildsystem triggers
to
ensure that the packages get rebuilt in a timely fashion and that the
tree thus stays sane.
buildsystem triggers that Core and Extras and 3rd party builders of
ntfs modules can rely on?
-jef
9:48 a.m.
New subject: dkms coreward for fc5? (was Re: What next?)
On Mon, Jun 06, 2005 at 10:41:31AM -0400, Jeff Spaleta wrote:
buildsystem triggers that Core and Extras and 3rd party builders of
ntfs modules can rely on?
And third-party builders of OpenAFS. :)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
1:16 p.m.
New subject: dkms coreward for fc5? (was Re: What next?)
On Sun, Jun 05, 2005 at 10:26:27PM -0400, Jeremy Katz wrote:
As far as I'm concerned, DKMS solves the wrong problem. As long
as the
user has to have a compiler installed to use it, it's not useful.
You don't have to have a compiler on the target systems. *If* you've
got a compiler, and choose to invoke the build system (either through
AUTOINSTALL="yes" on a per-package basis, or manually), then it yes,
you can use the compiler to build. But it's not strictly required.
Point in fact, Dell's factory install process doesn't invoke the
compiler at all - it uses the precompiled modules from each package.
The build system needs a compiler, the target systems don't.
As long as it's not an integrated part of the packaging system,
it's not useful.
This is mostly true. It would be of great benefit if it were
integrated, but it's not strictly required to be if you've got a
compiler on your target systems, or an ancillary build system.
That said, I think that cleaning up the interaction for kernel
module
packages and ensuring that everything is cleanly defined such that it
can work is a good goal for FC5 and I'm willing to help out some to make
it happen. Spot and I talked briefly about this in New Orleans and I
think the plan is to restart that discussion after he gets back from a
(much needed and deserved) vacation.
Agreed on all points.
Once _that_ is defined, then we can think about buildsystem triggers
to
ensure that the packages get rebuilt in a timely fashion and that the
tree thus stays sane.
Agreed.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
1:37 p.m.
New subject: dkms coreward for fc5? (was Re: What next?)
On Mon, 2005-06-06 at 13:16 -0500, Matt Domsch wrote:
On Sun, Jun 05, 2005 at 10:26:27PM -0400, Jeremy Katz wrote:
> As far as I'm concerned, DKMS solves the wrong problem. As long as the
> user has to have a compiler installed to use it, it's not useful.
You don't have to have a compiler on the target systems. *If* you've
got a compiler, and choose to invoke the build system (either through
AUTOINSTALL="yes" on a per-package basis, or manually), then it yes,
you can use the compiler to build. But it's not strictly required.
Point in fact, Dell's factory install process doesn't invoke the
compiler at all - it uses the precompiled modules from each package.
The build system needs a compiler, the target systems don't.
Allow me to clarify.
If DKMS is to be the solution to Jef's problem (which is that the kernel
modules in the devel tree don't match the kernel in the devel tree),
then you need to have a compiler on the system so you can recompile
whenever the kernel changes. Or we get into the build system trigger
stuff I talked about (at which point, we should be doing it with the
packaging system anyway IMHO)
Jeremy
10:24 a.m.
On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
Can we make it a point to write out Specification documents? This way we
foster more openness, everyone has an idea of what we want to achieve,
and its publically accessible (and more can come along to help out when
they see interest)
This is very much like how we did it for UbuntuDownUnder
(http://udu.wiki.ubuntu.com/) and I think we can only gain from
repeating this exact process
We too have a wiki at http://fedoraproject.org/wiki/ and I'm sure a new
section for this can be created and will foster a lot more community
targets (and we'll also know what to expect for FC-5, goals,
expectations, future goals, etc.)
Regards
--
Colin Charles, http://www.bytebot.net/
10:18 a.m.
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
Maybe it's time to start the brainstorming for Fedora Core 5 and
Fedora
Extras 5 - what major features are you willing to put effort into?
- Ability to fully configure IPv6 networking in Anaconda
(static IP, stateless autoconfig, DHCPv6, listen to RAs or static
default route, etc.pp)
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
9:18 a.m.
On Wed, Jun 15, 2005 at 05:18:34PM +0200, Daniel Roesen wrote:
On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote:
> Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora
> Extras 5 - what major features are you willing to put effort into?
- Ability to fully configure IPv6 networking in Anaconda
(static IP, stateless autoconfig, DHCPv6, listen to RAs or static
default route, etc.pp)
FWIW, this is now
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160661
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
6893
days inactive
6908
days old
399 comments
102 participants
participants (102)
-
Aaron Kurtz -
Alan Cox -
Andrew Overholt -
Anthony Green -
Aph -
Arjan van de Ven -
Axel Thimm -
Bill Nottingham -
Chris Adams -
Chris McDonough -
Chris Ricker -
Christopher Aillon -
Chuck Anderson -
Colin Charles -
Curtis Doty -
Daniel Roesen -
Daniel Veillard -
Dave Jones -
David Hollis -
David Kewley -
David Mohring -
David Woodhouse -
David Zeuthen -
Davide Bolcioni -
Denis Leroy -
Ed Hill -
Elliot Lee -
Emily Brantley -
Emmanuel Seyman -
Enrico Scholz -
Felipe Alfaro Solana -
Felipe Alfaro Solana -
Florin Andrei -
Havoc Pennington -
Ian Pilcher -
Ignacio Vazquez-Abrams -
Jakub Jelinek -
Jef Spaleta -
Jeff Pitman -
Jeff Pound -
Jeremy Katz -
Jesse Keating -
Joe Desbonnet -
John Thacker -
Jose Pedro Oliveira -
Josh Boyer -
Kaj J. Niemi -
kas -
Kenneth Porter -
Kjartan Maraas -
Konstantin Ryabitsev -
Kyrre Ness Sjobak -
M. Fioretti -
Manuel Moreno -
Matt Domsch -
Matthew Lenz -
Matthew Miller -
mbneto -
Michael Schroeder -
Michael Tiemann -
Michael Wiktowy -
Mike Chambers -
Mike Hearn -
Mike MacCana -
Miloslav Trmač -
Nicholas Miell -
Nicolas Mailhot -
Nicolas Mailhot
-
Nils Philippsen -
Panu Matilainen -
Paul A Houle -
Paul Howarth -
Paul Nasrat -
Pekka Pietikäinen -
Per Bjornsson -
Peter Jones -
Peter Robinson -
Pádraig Brady -
Rahul Sundaram -
Ralf Ertzinger -
Richard June -
Richard Li -
Rodd Clarkson -
Roland McGrath -
Ronny Buchmann -
Rudi Chiarito -
Rui Miguel Silva Seabra -
seth vidal -
Stephen John Smoogen -
Steve Bergman -
Steven Garrity -
Tarjei Knapstad -
Thomas Fitzsimmons -
Thomas Vander Stichele -
Thorsten Leemhuis -
Tom Tromey -
Tomas Mraz -
Toshio Kuratomi -
Ulrich Drepper -
Ville Skyttä -
W. Michael Petullo -
Warren Togami