For FC6 we're looking at bringing forward and integrating some of the
Stateless Linux work. More detail will be up at:
although probably not for a couple of days.
One of the main tenets of this is that the system filesystems should
be able to run read-only; there's no reason for apps to be writing
to the system filesystem in general use. However, tracking this
can be difficult; you don't want to force everyone to run read-only
just to get data on their workloads.
So, what we've worked on is a way to simply log what apps are writing
to (or trying to write to) the system filesystems. This is now
A readme for this is attached. Basically, we're interested in getting
logs from a variety of workloads, ranging from basic desktop to server;
with this information, we can make sure that a readonly root scenario
works for the majority of use cases that someone might want.
Right now, reports can go to this list, in this thread or similar.
If we need to set up a separate mechanism for recieving them, we
On Mon, 2006-03-27 at 15:39 -0500, sean wrote:
> On Mon, 27 Mar 2006 12:33:50 -0800 (PST)
> Shane Stixrud <shane(a)geeklords.org> wrote:
> > I find it hard to believe no one else sees the current
> > complexity of system/application configuration as undesirable? Is
> > this problem too big to be addressed? Is there too much historical
> > precedence involved? Or is there a solid technical reason for not having
> > a standardized configuration file format?
> > Linux is perceived to be "difficult" to configure and managed by many,
> > this is not because we lack guis and wizards, rather because one must
> > discover the process each subsystem and application uses to
> > accept configure directives from its users.
> > I see no reason why it would not be possible and desirable to have a
> > plain text compatible configuration file standard that is universal
> > between subsystems, services and applications (besides it being a lot of
> > work). It seems to me that the complexities of existing configuration
> > tools (authconfig, system-config-samba etc...) are largely due to this
> > same fundamental issue.
> GUI users don't want to be hunting through text files anyway, they
> want nice settings windows and wizards. Anyone hand editing config
> files better know what's going on anyway; the current situation isn't too
> bad there.
> gconf already provides a reasonable way to change settings from the
> command line and via GUI tools. What would you change?
> No matter what you come up with though, it will be many years before
> you see wide spread adoption. If anything, you might consider a
> project to create a system-wide config editor that knows all
> the different formats etc and provides a consistent CLI/GUI
I started designing this type of system. A gui config editor/manager
with it's own config languages, that used translator plugins for all the
different config file formats out in the opensource community. It is
really an ugly massive project, that is useless until you get all the
translators written. The scariest problem that forced me to give it up
was not just maintaining the translator plugins, but maintaining the
translation rules for the different versions of config files for the
Just thought I would chime in.
I would image that 3D effects (drop shadows, beveled edges etc) are
possible. The downside of SVG is that it's all relatively new and
products/libraries are not that common. If you are pitching to a
conservative client (military type people for example) you don't want
to take risks with the technology.
Another thin client option I mentioned in an earlier post is VNC: you
can run the application on the server and just use VNC protocol to
update a VNC display. Ideal if the thin clients are on a high
If you want a fat client with portability: my personal preferences
would be Java (SWT or Swing). It sounds like your application is going
to be deployed on a controled environment, so I don't think Java would
be a problem. If C++ is your language of choice I would agree with one
of the previous posters -- you will not go wrong with Qt.
On 3/27/06, Kenneth Porter <shiva(a)sewingwitch.com> wrote:
> On Monday, March 27, 2006 7:52 PM +0100 Joe Desbonnet
> <jdesbonnet(a)gmail.com> wrote:
> > Advantage of SVG is that it's a thin client solution: ie you just need
> > IE + SVG Plugin or just Firefox 1.5+
> Does SVG do 3D? I tried a few of the examples and they all looked flat.
> That's not a problem for me personally, but the PHB's love the pretty
> gizmos, and that's who I'm shopping for. (I'm the guy who looks closely at
> the screenshots in reviews to see what's actually happening, instead of
> which has the prettier control set. For my own use, I buy for
> functionality, not looks. Even in games.)
> fedora-devel-list mailing list
If your application needs an update rate of less than 1Hz (ie one
second or more between updates) consider SVG:
Take a look at these real time instrumentation demos from WPS Energy:
Advantage of SVG is that it's a thin client solution: ie you just need
IE + SVG Plugin or just Firefox 1.5+
On 3/27/06, Kenneth Porter <shiva(a)sewingwitch.com> wrote:
> --On Friday, March 24, 2006 8:33 PM -0700 "Lamont R. Peterson"
> <lamont(a)gurulabs.com> wrote:
> > Trust me, I've written enough code in various languages and using various
> > frameworks and toolkits to know that when you want stable, simple,
> > reliable cross-platform code, Qt is excellent.
> I was looking at Qt. The developer license is pricey but probably doable.
> What does it provide for the kinds of controls I mentioned? Do you know of
> any demo apps I can look at that illustrate how well they function?
> As an example of the kind of app I'm thinking of, consider a model train
> control panel which can control the speeds of various locomotives and
> report track conditions in real time (eg. graphing the impedance of the
> For an example of the kinds of controls I'm looking for, National
> Instruments' Measurement Studio is an instrumentation GUI control library:
> And as you can see, there's no Linux port.
> fedora-devel-list mailing list
After installing Fedora on any system, when the system boots up for the
first time I always log in as root immediately, in a text-mode console
(not via X), then run this sequence:
yum -y update
yum clean packages
I just type everything in then I walk away and let the system do it
since there should be no user interaction. Perhaps a better idea would
be to run everything inside a typescript session, just to catch all the
output for further analysis - hmmm, that actually does sound good, I
should add that to my first boot ritual from now on. :-)
Anyway, even before Fedora, I was pretty much doing the same thing, but
translated in Red Hat Linux terms.
Even before that, 10 years ago when I was using Slackware Linux :-) I
was doing things that were functionally equivalent, albeit a lot more
manual and hugely more cumbersome.
I just think it's a good idea and it's the best and shortest way to
build a clean and up to date system out of a fresh install.
So I was thinking - perhaps it, or something equivalent - could be added
as the last step to firstboot. Perhaps as a popup, informing the user
that the system will apply all available updates, perform some
maintenance tasks then reboot, and asking the user to either accept or
The only snag that I can think of is Internet access - firstboot should
test HTTP access and perhaps ask the user to configure proxy settings
first (and skip this whole thing if there seems to be no way to enable
Internet access at this point).
Also, perhaps anacron should not even be started the very first time the
system comes up after install, but instead wait for this maintenance
task to be either accepted by the user (then the system will reboot and
anacron will launch normally next time) or rejected (then perhaps
anacron should be launched by firstboot).
This might also help a lot of newbies since I noticed that some people
running Linux for the first time are not aware of the necessity to apply
updates and patches and do not even know how to do it.
For the advanced users it would be just a convenient way to bring a
fresh install up to date before actually pounding on it with real
Are there any plans for doing stable releases of fedora core for ia64?
I've seen the rawhide tree for the platform, but with the recent
pledges from intel, hp, and others to put more money into the
platform, I think it might be time to release fedora for end users on
"Don't worry about what anybody else is going to do.
The best way to predict the future is to invent it."
-- Alan Kay
-----BEGIN PGP SIGNED MESSAGE-----
Pup sorely needs an uncheck-all button. Right now I have a few
packages that keep messing the whole process up since they depend on
Xorg6 (since the packagers haven't updated the specs yet) so it's
quite tedious to uncheck every single box that won't work.
Note: All emails from this address should have a GPG signature. If
you have the proper setup you can use this to confirm my identity and
that the email was not changed in transit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
my old method to mount a smbfs filesystem does not work, further
investigation shows, that the smbfs kernel module does not exist in the
actual FC5 kernel.
Has the method changed? In fedora core 3 there was such a kernel module.
>On 3/26/06, Ron Yorston <rmy(a)tigress.co.uk> wrote:
>> If anyone needs a pre-release version of metacity with configurable new
>> window focus I have it here:
>I'd be curious to see a description of how each behaviour acts. I know
>some of the behaviours are listed on the Gnome bugzilla but there's a
>lot to read there.
>I think other people would also be curious about what different
>focusing styles exist in Gnome or will exist.
My patch currently has two settings: "smart" which is the pre-2.14
behaviour and "strict" which enables the experimental strict focus
approximation mode. (Neither of these is a particularly good name,
as the smart mode isn't really smart and the strict mode isn't really
The smart mode simply applies the user's current focus policy to new
windows. So if you're using focus follows mouse and the new window
appears at your mouse position it gets focus. Some people don't like
this and claim it can be dangerous.
The experimental strict focus approximation mode tries to prevent
windows started from a hardcoded list of terminals from getting focus.
In part it does this by putting the new window underneath the terminal,
which lots of people find objectionable.
In the GNOME Bugzilla Elijah Newren has suggested additional modes
which might be called "always" and "never", though these haven't been
implemented yet. I guess that "always" would force the new window always
to have focus while "never" would never give focus to new windows. This
latter is what some people would call "strict".
All of these modes apply an additional layer of behaviour beyond what you
currently get with the click/mouse/sloppy focus modes (and are independent
of those modes).