Unblock Avahi by default (for the Desktop live CDs)
by Bastien Nocera
Heya,
It seems to me that Avahi would be safe to run by default. That would
allow accessing remote machines through their .local names, even if it
wouldn't solve the problem of sharing *from* the machine itself.
But it would mean we can SSH, or VNC into local area machines, and
consume data (shares, music, etc.).
Comments?
12 years, 10 months
Droid Sans
by William Jon McCann
Hey,
I think we want to consider switching to Droid Sans for the default
font. At the very least I want it included on the install/live media.
What do we need to do to make this happen?
I seem to recall there were some technical reasons why we weren't able
to make this happen for F12.
Thanks,
Jon
12 years, 10 months
Fuse Workspace Union
by Jeroen van Meeuwen
Hello there,
I just received a phone call from Stef Bon, a fellow Dutchman who's been
working on a Fuse technology based module to make it easier, and more
transparent, to a user, to mount, navigate and use pluggable storage devices
and network resources like Samba shares.
While Stef is in a better position to describe the project, I'm going to take
a stab at providing a summary. Since Stef wrote a bunch of good documentation
on his project, please allow me to refer you to those pages:
http://linux.bononline.nl/linux/mount.md5key.new/
In short, this type of technology could move the user's desktop experience
forward a great deal as far as navigation experience goes.
For instance, and this is just one of many example scenarios listed in the
documentation, creating a "Shared Folder" for documents and files that all
users on a system can use is a little more difficult on Linux still then it is
on, say, a Windows XP Home edition workstation.
Very much the same goes for navigation to a freshly (automatically) mounted
USB thumb drive, that simply is not mounted within the user's home directory,
but instead causes the user to have to navigate through system folders (e.g.
/media/XXX/), even though a "1.8 GiB Filesystem" might show up in "Places" -if
you use that navigation pane.
Stef would love to increase awareness about his project, and would appreciate
some constructive feedback. I'm glad to be able to make the introductions. I
think Stef's project has a very high potential, and so, if you're interested,
Stef would also appreciate some help in terms of further development.
Kind regards,
Jeroen van Meeuwen
12 years, 10 months
Re: Fuse Workspace Union
by Bastien Nocera
On Fri, 2010-04-30 at 10:08 +0200, Stef Bon wrote:
> 2010/4/29 Bastien Nocera <bnocera(a)redhat.com>:
> > On Thu, 2010-04-29 at 12:35 +0200, Jeroen van Meeuwen wrote:
> >> Hello there,
> >>
> >> I just received a phone call from Stef Bon, a fellow Dutchman who's been
> >> working on a Fuse technology based module to make it easier, and more
> >> transparent, to a user, to mount, navigate and use pluggable storage devices
> >> and network resources like Samba shares.
> >
> > From a quick glance, this is something that gvfs already offers,
> > user-space filesystems and fuse integration for non-GIO applications.
> Well there are some important differences. Correct me if I'm wrong, but the
> Gnome VFS is providing a browing facility for applications, and if you're not a
> Gnome App, and there fore cannot make use of these libaries, you'll
> have to use the
> fuse module.
Non-GIO applications can still browse already mounted sources. Note that
in all of your demos, you're using a file manager to browse those
filesystems. Browsing the file system with a GIO-using file manager
(Thunar or nautilus) would work about the same.
> Mine is completely based on the fuse module (and the automounter to do
> the mounting)
> and does not depend on the desktop environment, it's just a level
> lower: the filesystem.
>
> Second, I'm working on inotify, still thinking how to make it work.
> Does it already work with Gvfs?
Yes. See the g_file_monitor*() functions.
> Futher locking, extended attributes, and seeking in afile is
> supported by mine. Does Gvfs also?
We don't have locking support, but the rest works fine.
> Finally mine lacks good integration with hal (udisk) for local devices
> to export the directory
> where a device is available for the user.
We have that as well.
Cheers
12 years, 11 months
Re: spin kickstart/minimization cleanups
by Colin Walters
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> I've spent a little time looking at the hardware side of things and
> done a basic patch for some of the hardware stuff based on the current
> rawhide comps file. I've broken it down into network/server/misc for
> the time being and pushed the print stuff over to its group. More can
> be done as it was a quick look through. The old hardware-support
> currently includes all the other groups so there's no real change for
> current builds overall.
This looks like a good start. I think the way this kind of thing
should work in general is that the system detects if you have the
hardware, and dynamically installs support for it. We'd need some
database mapping things like USB ids to packages. Networking is an
exception; we should include as many drivers/tools for
networking-related functionality as possible so that the system can be
bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If
you don't, it doesn't.
12 years, 11 months
change to critical-path-gnome group
by Bill Nottingham
As part of the update acceptance policy approved by FESCo,
we have the following:
The 'important' package set is defined as the following:
* The current critical path package set
* All major desktop environments' core functionality (GNOME, KDE, XFCE,
* LXDE)
* Package updating frameworks (gnome-packagekit, kpackagekit)
* Major desktop productivity apps. An initial list would be firefox,
* kdebase (konqueror), thunderbird, evolution, kdepim (kmail).
(c.f. https://fedoraproject.org/wiki/Package_update_acceptance_criteria)
I've generated a change to the F-14 comps file along these lines.
Does this look accurate?
Bill
12 years, 11 months
Some Ideas About Fedora 14 Media
by Liang Suilong
Hi, all.
Fedora 13 Desktop Spin would target to 1GB LiveDVD. But at last desktop team
decided to return to 700MB CD size. It means that we should give up
OpenOffice.org and GIMP by default. It looks quite sad. Looking at
BrOffice.org, I seem to find out some ideas.
Broffice suite and GIMP are installed in BrOffice.org by default,
nevertheless, broffice spin gives up many locale files. Broffice just only
support English, Spanish and Portuguese. So does desktop spin follow this
method? Deskop spin contains OOo and GIMP, but it should remove most of
GNOME locale files and OOo langpack. Then desktop spin can keep 700MB CD
size.
How can we download langpack file? Yum-langpacks seems to be the best
solution. When we choose some language in system-config-lanage,
yum-langpacks can download langpack of GNOME, KDE and OOo and some fonts we
need and IME for that language. Anaconda also can run this plugin in
%post-install so that it can fetch language pack and IME from remote
repository.
But We can not ignore that separating langpack from GNOME is a great job.
Packaging langpack like kde-l10n-* and language-pack-* in Ubuntu needs a lot
of packager to do it.
Better experience: Live/Install Hybrid DVD
Looking at install DVD, it looks too old. To add a Livesystem on DVD media
can improve user experience. However, unlike Anaconda on install media,
Anaconda on live system can not load a repository on media or a remote
repository. That's a great problem.
Just hope these suggestions can help Fedora community, I wish that Fedora 14
would have a better installation experience.
Liang Suilong
--
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong
12 years, 11 months
RE: The hardware
by Hristo Petkov
Hi,
The OS should provide absolute control on the hardware with full functionality.
This can be used as a competitive advantage in the design and development.
When people buy some hardware they expect to get the most out of it.
If the OS could not manage with this requirement - people start looking for alternatives.
Thus for example I have installed hplip 3.10.2 fc11 and it gives a bug report when shutting down the computer that hp-systray is crashed (whatever this may mean) and I have no idea of how to fix it. I have tried various things without success (to manage with the bug). The printer however is working normally.
Just for the record, the Ubuntu forums are reporting similar problem.
It is amazing that with hplip 3.9.12 the absolutely same hardware with absolutely the same Distro (fc11) from the very same Live CD worked 'without remarks'.
The idea is when a development is done one should be very careful to avoid 'downgrading' things meanwhile.
Regards
12 years, 11 months
Updates next steps
by William Jon McCann
Hey folks,
We discussed this a bit on IRC yesterday but I wanted to bring it up
on the list too.
Now that we have rough consensus that we should try to limit the
volume of "pointless" updates, what is next?
I propose we look at two things right away:
1. Limit the frequency of non-critical updates to once per week in
stable releases
2. Establish norms or rules that limit the types of changes in stable
releases to ensure the releases remain stable
A concrete example of the kind of thing that I think we should try to avoid:
Two days ago I installed updates for F12 (over a hundred random
updates) then yesterday I noticed a lot more udpates (40ish) that
included an update for vala 0.8.0 with the description "Update to new
major release 0.8.0".
Longer term, I'd like to see a more comprehensive plan similar to
http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience but
we probably need to work towards that incrementally.
Thoughts? What is the best way to accomplish these two things?
Jon
12 years, 11 months
RE: Updates
by Hristo Petkov
Hi,
> And we can address part of the 'update frequency' problem client-side,
> by only checking for new updates once a week.
>
> But one problem which we cannot address client-side, and for which 'do
> nothing now and reassess later' will not help at all is the amount of
> updates. Even if you only check once per week, the flood of pointless
> updates is a problem. That is that part of the problem that we need to
> address with Jon's 'establishing norms or rules to limit changes'.
In my view the problem is not in the updates themselves, but rather in the Fedora specification of developing new software versions which should differ significantly from the previous ones.
Who really needs all these distos to change at the 'speed of light in vacuum'.
New distros - yes, but not like this, and not so often.
Perhaps the new distro should be something like a compilation of the old distros with the updates. In this way the problem with the compatibility of the distros would be solved as well.
For over 30 years of software monopoly on the market MS has all in all 9 OS, and within less time some other people have 14.
Maybe this needs some interpretation.
Regards
12 years, 11 months
