GUI controls for instrumentation
by Kenneth Porter
I'm tasked to write a front end for an instrumentation application for
"that other operating system" ;) and I'd like to use GUI controls that are
cross-platform portable for an eventual Linux port. What would the list
recommend? I essentially need something that resembles the front panel of
an oscilloscope, along with some dial indicators and knobs. I've also been
thinking about making it web-accessible, so perhaps a Java-based solution
would be suitable.
18 years, 1 month
Bootsplash?
by Richard Hughes
Now that FC5 has hibernate working for lots of people, how about we do
something about the delay which currently is displayed as a black
screen?
I click the hibernate button, and am presented with the black screen for
about 30 seconds as my ram is swapped out to disk. At resume, I'm
presented with a black screen until the desktop re-appears.
I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think
that requires a patch to the kernel away from vanilla, so that might not
be an option for fedora. Maybe rhgb could be used instead?
Has any work been done, or ideas discussed on this for fedora? Thanks.
Richard.
18 years, 1 month
Package names in FC5
by Rafał Kwaśny
Hi,
I wonder why some packages are named like:
cman-1.0.5-0.FC5.1.i386.rpm
(with capital FC5)
some are named like:
compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
but most of them don't have any fc5 tag
Is there any pattern in this?
--
Rafal Kwasny
rkwasny(a)aurox.org
18 years, 1 month
The Strengths and Weakness of Fedora/RHEL OS management
by Shane Stixrud
Greetings,
This message to the Fedora Development Community is an attempt to start a
useful discussion on where Fedora/RHEL is today and where it is going in
the future, on the subject of OS management. My apologies in advance for
the long message.
OS management is a very broad topic, in specific I will focus on the
elements that I consider foundational weaknesses (compared to what it
could be). This is not to imply these perceived "weaknesses" out weigh
its strengths or that other OS's are overall superior in this regard.
A bit of background to put my technical comments in perspective:
I remember when I was first introduced to Unix (1992) and then later
Linux (1993) compared to what I was used to at the time they combined a
flexibility, functionality and a form of simplicity (in design) that when
combined made all other operating systems seem hallow. For the most part
I still feel this way today, but over the years having worked in
enterprise environments where Linux is the up and coming challenger to
entrenched non-unix platforms (VMS, Windows, zOS, etc...) I have come to
better appreciate some of the elements involved in limiting Linux's
adoption.
I was recently tasked with standardizing/documenting our Linux server
build/configuration process and as part of this process began training
some of our Windows/Novell administrators to be able to carry out some of
these basic tasks. It was this second part of helping train people that
caused me to examine and re-examine the processes I used for this
standardization.
My goal was simple in theory, I would use pxe+kickstart and enforce
standard configurations and policies via a series of post scripts while
attempting to keep readability, simplicity and supportability from a
"non-unix guru" perspective as my guiding light (A wise man once said:
Make it as simple as possible but no simpler). For those interested an
example of what I came up with it can be obtained here:
http://geeklords.org/~shane/kickstart
The process turned out to be not quite as simple as the theory but very
educational none the less. To start with I had a number of ways I could
manipulate my fresh Linux install.
1) I could create a custom RPM that had all of the changes imbedded in
config files and rpm scripts that merely overwrote the pre-existing ones.
Problem being this approach hides the complexity of what all was being
changed and why.
2) Use cfengine after the kickstart install. This of course has some
advantages over the rpm method but it also hides the same complexity and
adds some of its own.
3) Document on paper all of the steps required and how to perform them
from the console, taking advantage of the guis when available or command
line when required. I felt that was not only a big waste of time but left
far too much to human error.
4) Create a series of simple scripts using basic OS applications/tools
(sed, echo, cp, mv, authtool, postconf etc...) to perform all of the
required modifications, documenting what and why along the way.
I choose method 4.
My conclusion having completed this process is that the number of
variables, complexity and dependencies that must be understood and taken
into account when modifying configuration files is much higher than it
needs to be. I think this should be clear when reading the example scripts
mentioned above.
Some things I learned:
Sed is a wonderful tool, but it is highly limited by the fact its user
must take into account whole file(s) for each expression, this is further
complicated when one must consider the file may change over time. The
complexity and readability of regular expression tools is much higher than
should be required to change OS/application variables.
Creating new files or appending to the end of existing files with "echo"
only takes one so far. This also tends to have the cost of hurting
readability as it is often the case you would prefer putting data
somewhere else in the file (i.e. sed).
The nature of flat configuration files where each application has its own
format is such where recovery and/or applying changes only if they have
not been already applied is too complex and hurts readability far to much
to be attempted in a simple shell script.
Many applications have their own command line driven configuration
utilities. However each has their own oddities and complexities
(authtool, gconftool-2, postconf etc...) Oddly enough out of all of the
command line configuration tools I have used, I find gconftool-2 to be
closest to The Right Way (TM), which is odd as it is by far one of the
most complex syntax's to use (God help anyone who tries to make major
edits to gnome xml files using sed) example:
"gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.mandator
y --type float --set /desktop/gnome/peripherals/mouse/motion_acceleration 1"
Even a complex (yet powerful) tool can meet the golden rule of "Make it as
simple as possible but no simpler" when compared against a bunch of tools
that are less powerful (and perhaps less complex when viewed in
isolation).
It is my opinion that we as a community need to find a Better Way (tm) to
manage configuration changes for Linux subsystems and applications.
Everything should be a file, but that does not mean every configuration
file needs to be formatted and managed differently.
In closing, a change this fundamental must be designed by the best minds
and must have a strong champion for it to have a chance to succeed. The
Fedora community is likely the only Linux entity with the brain power and
influence to address this issue.
Cheers,
Shane
18 years, 1 month
Re: The Strengths and Weakness of Fedora/RHEL OS management
by Avi Alkalay
Bill Crawford <billcrawford1970 gmail com> wrote:
> Dunno where you got this obsession, but just because you can represent data as
> "key/value pairs" doesn't mean that's always the best layout.
Maybe not for your or my eyes. The best layout is the one accessible
by the broadest range of ways. Currently, human-readable files are
accessible by human-beings only, or by configuration file "compilers",
that are difficult, unique, that nobody wants to write or maintain
except for the original software writer (e.g. the Samba developer with
the smb.conf file).
The proposed layout is accessible to you by simple reformatting (as
with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or
by GUIs (as kdbedit,
http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any
software that uses a simple API as libelektra.
> There's a reason why programs aren't written for the old Turing Machine, and
> that's that however well it might be able to represent any possible program,
> it's incredibly verbose.
The only reason I can see is historical. Since there is now projects
integration efforts in the OSS world, everybody uses its own format.
So you may think there is a reason, lost in time, but there is
actually no reason why BIND named.conf file look that way, which is
different from /etc/passwd, which is different from smb.conf, which is
different from httpd.conf. Well, the real reason I can see is selfish
developers that enjoy rewriting config file parsing code and invent
configuration file layouts that seems best suited for their apps. But
when you strip the syntax fat, they all are not more than key and
value pairs on a hierarchy.
So to make the discussion productive, please enlighten us with the
reasons you think exists somewhere, or please don't speculate.
> The examples which have appeared in this thread have all made things *less*
> clear afaics.
Again, maybe for our human eyes, but are 100% clear for software. And
the end-goal is leverage better software integration between
themselves, so we, human-beings, will have to look at configuration
element everyday less.
Anyway, for human eyes, I think this is pretty pleasant to see:
http://www.libelektra.org/Screenshots_and_Key_Examples
> Bill"somewhat sick of this thread but suspecting if people don't reply the
> lunatics will end up running the asylum"Crawford.
Or maybe the lunatics are already running it and some people are
trying to take the control back :-)
Avi
18 years, 1 month
system-config-boot
by Arthur Pemberton
I would like to submit for critique, suggests, etc. this program I have
made. It is the first GUI app I've made in Linux, and I would appreciate
some constructive criticism.
I made this program because system-config-boot as it exists (in FC4 and
FC5Test3 at least) only allows for selecting of a default boot entry and
changing of the timeout. And FC tends to accumulate a large list of boot
entries during its release cycle. Who knows, maybe this can be included in
FC.
I coded it on a machine running FC5Test3 in case that makes any difference.
Peace
Arthur
--
As a boy I jumped through Windows, as a man I play with Penguins.
18 years, 1 month
r300 driver in extras?
by Jonathan Dieter
Mike, I've been following the fedora-devel mailing list, and I
understand why you removed r300 support in Mesa and the kernel. I was
working through a bug where OpenGL didn't work at all (even in indirect
mode), and, in the process, rebuilt both Mesa and the kernel after
removing your fixes. Apparently, I'm one of the lucky ones whose Radeon
9600 works with the experimental driver because it all started working.
I'm now thinking of putting together a package (similar to the
proprietary one in livna) that would give accelerated 3D to any Radeon
users willing to take the risk.
It seems that the only difference in Mesa when the r300 is enabled is
that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and
that the only difference in the kernel is the drm module is patched to
not recognize the r300 PCI ids. It seems that the Mesa problem could be
easily fixed, but what is the easiest way to fix the kernel (aside from
providing my own (un)patched kernel)? Will X even try to load the DRM
module if Mesa doesn't provide r300_dri.so but the kernel does provide
the PCI id's? If it doesn't, could we re-enable the r300 PCI ids in the
kernel and just ship Mesa without the r300 driver? If it does, is there
any other possible solution to the kernel that I'm missing?
I've been using the fglrx driver in earlier version of Fedora for years
now and would love to take this chance to move off of it and helping
others move off in the process is a bonus.
Thanks,
Jonathan Dieter
18 years, 1 month
Recommended way to start numlockx before gdm?
by John Mahowald
I maintain numlockx in extras. I have recieved requests for it to be
started before gdm, so the keypad works with the numbers while logging
in. [1] Currently it drops a one-liner script into
/etc/X11/xinit/xinitrc.d/numlockx.sh. Is there a way to do it that
earlier in the X startup that isn't too hacky? I'm not an expert on
the X start process by any means. Appending a line to
/etc/X11/xdm/Xsetup_0 has been suggested, is this acceptable?
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171361
18 years, 1 month
Re: 'Commercial Partners'
by Eric S. Raymond
sean <seanlkml(a)sympatico.ca>:
> But you're making some rather unsupportable assumptions about whether
> the changes you desire will really lead to the outcome you hope for.
Read up on the distinction between "necessary" and "sufficient" sometime.
I'm advocating necessary changes, I have not represented that they
will be *sufficient*.
> You've refused to acknowledge that there are other alternatives
> in the Linux landscape already doing the exact same thing you want
> Fedora to do.
And that would be who, exactly?
> And you've refused to articulate why every
> distribution must follow this same course of action.
No, just the ones that want market share among non-technical users.
Or, taking a larger view, Linux fans who actually want to do something
to stem the tide of creeping DRM and locked-down video card and the
like. To prevent that, we need to be the 800-pound gorilla, not
a niche product appealing to techies only.
> You're trying to take choice away from people.
OK, you've devolved into sputtering ga-ga incoherence now, Go take a
tranquilizer.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
18 years, 1 month
Fwd: The Strengths and Weakness of Fedora/RHEL OS management
by Avi Alkalay
On 3/28/06, Toshio Kuratomi <toshio(a)tiki-lounge.com> wrote:
> I'd argue that as the number of subnets and special case workstations
> goes up, the ability of a system administrator to read and understand
> the flat file is going to be markedly harder than for the admin to read
> the custom-crafted dhcp-config syntax.
>
> So if the end-goal is to keep the system-administrator's poor brain from
> exploding while manually editing the files, I'd say custom-crafted
> config files can be a win versus the generic one-size-fits-all approach.
Thats not the end-goal.
See, the end goal is to standarize configurations in such a way that
one program with proper permissions can directly interact with another
program's configurations. So in your DHCP server problem, an LDAP
helper can easily change DHCP's configuration to add/remove/change
some host's fixed IP address, for example, without having to ask the
sysadmin (a human being) to edit it manualy, and without having to
regenerate the entire config file again.
Another more easy to understand problem that a global standarized
configuration standard solves is the ability for you to buy a
commodity video card, install it on your system, and the vendor
scripts will safely, automatically, and precisely change your X.org
standarized configuration to inject itself there. Currently they have
to ask you to use vi plus your human brain and human eyes to make the
xorg.conf changes by yourself, because it is too hard for them write
an xorg.conf "compiler". Actualy, we know that what really happens is
a simple "Linux is not suported" statement from these vendors.
Avi
18 years, 1 month
