devel March 2006

devel@lists.stg.fedoraproject.org

285 participants
295 discussions

GUI controls for instrumentation
by Kenneth Porter 02 Apr '06

02 Apr '06

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.

14 36

Bootsplash?
by Richard Hughes 02 Apr '06

02 Apr '06

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.

12 28

Package names in FC5
by Rafał Kwaśny 02 Apr '06

02 Apr '06

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

6 7

The Strengths and Weakness of Fedora/RHEL OS management
by Shane Stixrud 02 Apr '06

02 Apr '06

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

16 36

Re: The Strengths and Weakness of Fedora/RHEL OS management
by Avi Alkalay 02 Apr '06

02 Apr '06

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

4 6

system-config-boot
by Arthur Pemberton 01 Apr '06

01 Apr '06

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.

4 3

r300 driver in extras?
by Jonathan Dieter 01 Apr '06

01 Apr '06

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

5 5

Recommended way to start numlockx before gdm?
by John Mahowald 31 Mar '06

31 Mar '06

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

1 0

Re: 'Commercial Partners'
by Eric S. Raymond 31 Mar '06

31 Mar '06

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>

2 1

Fwd: The Strengths and Weakness of Fedora/RHEL OS management
by Avi Alkalay 31 Mar '06

31 Mar '06

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

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2006