Notes from the leading edge
The gnome-terminal package picked up some interesting behavior where it seemingly grows without bound - a 350MB virtual address space on your editor's system, with 76MB resident. It easily outweighs lean-and-mean applications like emacs and liferea - though it remains outclassed by firefox. The cursor does not respond to focus events; your editor has learned to type at terminals even if they look like they are not listening. Occasionally a terminal will get into a mode where it refuses to respond to input until it receives a mouse click or two. And, occasionally, the whole thing just crashes, taking down every terminal window and every associated ssh session.
Your editor's longstanding appreciation for xterm is on the rise again.
In the hope of picking up a fix in a timely manner, your editor has been tracking the Rawhide repository a bit more closely than usual. Or, at least, attempting to do so. It can be quite discouraging to type "yum update" and have yum simply go off forever. Among other things, one must wait a great long time to distinguish this behavior from yum's normal mode of operation. Other times, it comes back very quickly with a message saying, for all practical purposes, "RPM crashed, you lose, sorry."
That is the sort of message that can chill a system administrator's blood. There's no end of system problems which can be addressed by reinstalling a package, perhaps moving to an older version. That is especially true for systems which are following a leading-edge development repository; one simply expects to install an ill-fated package occasionally. But if the package management system itself fails, this important tool goes away and one's ability to restore a sick system is severely compromised. It's about at this point that one begins to think it would have been good to check the system's backups a little more frequently.
Some digging around turns up the fact that these problems are well known and well documented in the bug-tracking system. Also found was a magic command, previously unknown to your editor, which evidently needs to be part of every system administrator's toolkit (at least, those who work with RPM-based systems):
rm /var/lib/rpm/__db*
Sure enough, every time your editor's system goes nonlinear (i.e. after every "yum update"), removing those cache files makes the problem go away. It would be awfully nice if RPM could figure out for itself that its cache is corrupt and not depend on people to clean up its messes for it. But that, evidently, is more than we should feel entitled to expect.
Still, one could consider taking this issue - perhaps with a patch - to the
RPM maintainer. Except that, for the purposes of most distributions, there
still is no RPM maintainer. Your editor asked who maintains RPM? back in
August, but no distributor has since announced a plan for moving to the
current "upstream" version of RPM or establishing a formal fork. The
November 20 Fedora Board
meeting talked about an upcoming "RPM
announcement," but it remains unannounced as of this writing. Getting a
handle on the status of that crucial package would be most beneficial for
users of RPM-based distributions, whether or not they do silly things like
track development repositories.
Posted Nov 22, 2006 5:02 UTC (Wed)
by charris (guest, #13263)
[Link] (2 responses)
Posted Nov 22, 2006 10:36 UTC (Wed)
by nix (subscriber, #2304)
[Link]
My favourite is from Solaris, with this wonderfully understated yet horrifying bug description:
4137237 patchadd 106300-01 results in rm -rf / as root
Posted Nov 22, 2006 10:36 UTC (Wed)
by amsix_noc (guest, #38927)
[Link]
Hopefully the lesson was this: if you want bleeding edge, be prepared to bleed.
;-)
-- Steven
Posted Nov 22, 2006 7:13 UTC (Wed)
by pr1268 (guest, #24648)
[Link] (8 responses)
I said it two weeks ago: Fedora Core is beta-quality software. My post was meant to actually defend Fedora, a Linux distribution which I can't stand. Someone disagreed with a couple of the generalizations I made (That's fine - I try to respect others' facts and opinions), but I stand behind my convictions (and smirky comment) that Fedora users need to wear "Beta Tester" in scarlet letters written across their shirts. ;-) Fedora's efforts to make open-source software more stable and reliable whilst pushing the envelope of current software technology incur the penalty of making its users' lives miserable (if I'm to understand my editor's remarks above). That being said, I still admire and respect FC's efforts to make the software issues/bugs more visible so as to improve all the FLOSS packages that come together at Fedora.
Posted Nov 22, 2006 8:57 UTC (Wed)
by hp (guest, #5220)
[Link]
Posted Nov 22, 2006 10:31 UTC (Wed)
by jonth (guest, #4008)
[Link] (5 responses)
It's too easy to hide behind "it's beta software, what do you expect?" and anyway, that's not the quality level you expect with beta software. Beta software is expected to work with a few glitches. The sort of thing our editor is seeing is pre-alpha quality, and just smacks of a lack of care.
I agree with Jon - rpm/yum needs some love.
Posted Nov 22, 2006 10:50 UTC (Wed)
by jospoortvliet (guest, #33164)
[Link]
anyway, i've been running testing and development packages all my life (i
i now run arch-linux. rolling release, stable, always up-to-date. you
Posted Nov 23, 2006 8:48 UTC (Thu)
by brother_rat (subscriber, #1895)
[Link]
Now that would be news!
Posted Nov 25, 2006 23:39 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (1 responses)
We can't say that. It may well be a bug that is exposed only with a certain combination of environmental factors that don't exist on the developer's system, or even any alpha test system. Beta test is the appropriate way to find out about those things.
It appears to me that it's customary in the open source world to do beta testing where proprietary software developers would normally use alpha testing instead. Sun would spend a lot of money testing Solaris before any user gets access to it, and the users would ultimately pay for that testing in money. You really have to have money to do alpha testing, because it is boring and people do not volunteer for it. So an open source project instead skips the alpha testing and puts the code out for people to try. Consequently, open source beta test code has plenty of bugs compared to proprietary beta test code.
(Clarifying some terminology: alpha testing is simulating use of a product for the sole purpose of finding bugs; beta testing is using a product to do real work, with the immediate goal of getting a job done and a side goal of finding bugs).
Posted Nov 27, 2006 15:16 UTC (Mon)
by jonth (guest, #4008)
[Link]
I can just about buy the idea that Fedora-rawhide is the equivalent of Debian-experimental, but if that's the case, where's Fedora's equivalent of unstable or testing? There doesn't appear to be one. How Fedora approaches stability I really don't know - which lines up with my experiences of Fedora core 3 and 4 at work, where we had a huge number of stability and consistency problems on laptops (Vaios and Thinkpads). As a result of this, we've voted with our feet and moved all our laptops over to Ubuntu (Dapper), with an instant, noticeable improvement in stability.
Posted Nov 28, 2006 0:53 UTC (Tue)
by malor (guest, #2973)
[Link]
I haven't seen a dead-end like that in all the years since. Unstable is indeed unstable, and it's not at all uncommon to have a broken package for a week or so while some incompatibility gets worked out, but I've never again been jammed into a corner where the package system itself was compromised. There has always been a shovel available to dig me out of holes.
But it did Really and Truly Break one time. :)
Posted Nov 22, 2006 23:40 UTC (Wed)
by alspnost (guest, #2763)
[Link]
It's all rather strange. I myself have had "issues" with Edgy, whereas Dapper was totally solid. But other people have different experiences. To be honest, my best experience so far was with Gentoo - whenever there was a problem, the forums helped me fix it within minutes. The same is *not* true with Ubuntu, despite the huge user base!
Posted Nov 22, 2006 10:28 UTC (Wed)
by kzin (guest, #841)
[Link] (3 responses)
Posted Nov 22, 2006 12:20 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (2 responses)
Posted Nov 22, 2006 12:47 UTC (Wed)
by kzin (guest, #841)
[Link]
Posted Nov 23, 2006 6:05 UTC (Thu)
by mokki (subscriber, #33200)
[Link]
I actually have created a reduced set of terminfo files in a ready tar.gz package that I just extract into my home directory in oldie unix systems.
Posted Nov 22, 2006 13:20 UTC (Wed)
by ernstp (guest, #13694)
[Link]
Posted Nov 22, 2006 13:56 UTC (Wed)
by smitty_one_each (subscriber, #28989)
[Link] (4 responses)
I think I know what these words mean, discretely, but this combination is fraught with cognitive dissonance, sir. ;)
Posted Nov 22, 2006 14:59 UTC (Wed)
by dvrabel (subscriber, #9500)
[Link] (1 responses)
Given that on my box emacs is 25% of the memory footprint of GNOME's clock applet, I think the term "lean" applies. After all, a clock should be really lightweight, right?
Posted Nov 23, 2006 10:18 UTC (Thu)
by jonth (guest, #4008)
[Link]
3438 jpl 15 0 21540 9964 8300 S 0.0 0.6 0:00.15 clock-applet
(although I'd agree that 21M is also a bit big for a clock!)
Posted Nov 22, 2006 16:41 UTC (Wed)
by flewellyn (subscriber, #5047)
[Link] (1 responses)
So this whole "Emacs is a memory hog!" meme needs to die.
Posted Nov 29, 2006 3:22 UTC (Wed)
by mikov (guest, #33179)
[Link]
You are right. On my box sometimes Emacs actually starts faster than
Konsole. It does take less memory too:
Posted Nov 22, 2006 16:32 UTC (Wed)
by lonely_bear (subscriber, #2726)
[Link] (3 responses)
Posted Nov 22, 2006 21:37 UTC (Wed)
by leoc (guest, #39773)
[Link] (2 responses)
Posted Nov 23, 2006 13:01 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
Posted Nov 23, 2006 13:15 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
Posted Nov 22, 2006 17:38 UTC (Wed)
by corbet (editor, #1)
[Link] (6 responses)
Posted Nov 22, 2006 18:20 UTC (Wed)
by thoffman (guest, #3063)
[Link] (4 responses)
I've been a happy convert since I switched from Fedora Core 5 to Dapper Drake, although I have not had opportunity to try the 64 bit versions.
As you point out in your article, package management is important, and the best thing in my experience with Ubuntu is the package management!
Synaptic and apt-get really are much, much better than Yum and rpm, in my experience. Many other things "just work" better and I spend much less time admin'ing and more time getting real work done.
Posted Nov 22, 2006 19:32 UTC (Wed)
by corbet (editor, #1)
[Link] (3 responses)
Posted Nov 22, 2006 21:05 UTC (Wed)
by tjc (guest, #137)
[Link]
Posted Nov 24, 2006 21:55 UTC (Fri)
by verdurin (subscriber, #36233)
[Link] (1 responses)
Posted Nov 25, 2006 0:16 UTC (Sat)
by corbet (editor, #1)
[Link]
Something I've wanted to do for a long time is to have an LWN "weather report" for volatile distributions and projects. Wouldn't it be nice to be able to tune in and see what storms you'll encounter before updating to the current version? Unfortunately, we don't have the time to do that now.
Posted Nov 23, 2006 11:35 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
I forget what the bugzilla number is, but just install the libXfont packages from Fedora Core 6.
Posted Nov 22, 2006 19:03 UTC (Wed)
by nicku (guest, #777)
[Link] (1 responses)
I learned and needed to type on my (non-rawhide) Fedora boxes for well over one year now. The two main problems with Fedora Core are: However, I continue to use Fedora since in every other respect, it works better for me than Ubuntu (X stopped working on the Ubuntu partition on my wistful laptop after It's odd that I can be such a happy Fedora user!
Posted Nov 27, 2006 15:36 UTC (Mon)
by SiliconSlick (guest, #39955)
[Link]
I learned and needed to type on my (non-rawhide) Fedora boxes for well over one year now.
A lot of our problems _seem_ to stem from problems with NFS mounts, but even when NFS is working flawlessly (and all mounts are available/reliable), the RPM DB still manages to cause hangs on occasion.
Posted Nov 22, 2006 20:03 UTC (Wed)
by hein.zelle (guest, #33324)
[Link] (1 responses)
You may want to try out xfce4-terminal. It appears to be a near-literal clone of gnome-terminal (at least feature- and looks-wise). I switched to it after the gnome-terminal developers took more than several months (still going strong) to decide what to do about the fact that nobody seems to like close buttons on every tab (oops! closed that 3-day model run. let's start over).
I'm not sure if it will be more stable for you, but for me it's meant less gnome-services started just for a terminal, more stable behaviour and less memory use overall (not verified in a proper way, though). I can't stand living without proper truetype/antialias font support and tabs in a terminal anymore, so I refuse to go back to xterm, even though I stuck with it a long time.
Posted Nov 23, 2006 17:58 UTC (Thu)
by jordi (guest, #14325)
[Link]
Posted Nov 22, 2006 20:57 UTC (Wed)
by oak (guest, #2786)
[Link]
A rawhide update once removed my inittab file. Running rawhide proved a learning experience in many ways.Notes from the leading edge
Other vendors have had this problem as well, of course.Notes from the leading edge
> Running rawhide proved a learning experience in many ways.Notes from the leading edge
I'll say it again: Fedora Core is beta-quality at best
Rawhide is not a released version of Fedora Core, it's a nightly build of Fedora-Core-in-progress.I'll say it again: Fedora Core is beta-quality at best
Well, compare and contrast with Debian unstable. I've _never_ had an apt/dpkg database get corrupted like this, even with unstable (which I've run daily on my laptop for many years). Packages occasionally break, but the system never gets in a state where you can't re-run apt to pick up fixes.I'll say it again: Fedora Core is beta-quality at best
i think debian-unstable is very well comparable to Fedora core's final I'll say it again: Fedora Core is beta-quality at best
releases. you should check debian-experimental to get the rawhide
feel... ;-)
don't mind an occasional crash) and i can tell you - sure you'll get into
trouble, but it'll be a learning experience. it's mostly fun, and you'll
have what others will have to wait for for another 5 or 6 months ;-)
shouldn't be afraid of the commandline, but if you're not, it's a great
distribution... no need for development versions of distributions to keep
up-to-date.
Maybe this rumoured "RPM announcement" is they are going to junk the lot and switch to apt/dpkg? ;-)I'll say it again: Fedora Core is beta-quality at best
I'll say it again: Fedora Core is beta-quality at best
The sort of thing our editor is seeing is pre-alpha quality
Sorry, I don't buy that - there's an existence proof that we can do better than Fedora-rawhide and that is Debian-unstable.I'll say it again: Fedora Core is beta-quality at best
Many, many years ago, I was running an Unstable box, and something was damaged in an upgrade to perl. This appeared to completely break the package management system. I don't remember exactly what broke, but I was completely stuck and unable to do much of anything. Dpkg seemed to be in some bizarre half-installed state. It wasn't fixable because the broken dpkg wouldn't run, and no other packages could be added or removed because of the broken installation program. I couldn't fall back perl versions without doing it manually. I wasn't particularly good at Linux yet, and this was way more than I could handle. Ended up reinstalling the box... which fortunately wasn't too painful, as it was just a toy workstation anyway. I avoided unstable for a good long while after that. :) I'll say it again: Fedora Core is beta-quality at best
Maybe true, but even Ubuntu has its problems. I recently tried to set it up on a friend's mondo-gaming 64-bit box. Neither Dapper not Edgy would even boot - at all - in either 32 or 64-bit guise, with no clues as to the problem. Fedora 6, on the other hand, just installed and worked without a hitch from the first attempt.
Ubuntu blues
For the terminal problem, you "screen". Who cares if the terminal emulator crashes when a newly-started terminal emulator simply restores all the running sessions and everything in them?Notes from the leading edge
Those of us who have to login from a terminal to an other system that has no idea what to do when the TERM is set to "screen".
Notes from the leading edge
I think "TERM=screen" is standard Linux termcap, and (nearly) all distros have it. Of course, you can always "TERM=linux" or "TERM=xterm" if you need to to log into AIX or whatever. They're compatible.Notes from the leading edge
A good practice is to copy the linux terminfo database to any solaris / hp-ux / aix system you log into and just set the TERMINFO environmental variable to point to it. That way you can use TERM=rxvt, TERM=screen and not have broken functionality.Notes from the leading edge
Maybe you should try tracking Feisty instead? :-PNotes from the leading edge
>lean-and-mean applications like emacsNotes from the leading edge
Notes from the leading edge
4843 dv02 15 0 184m 129m 9056 S 0 12.9 1:18.82 clock-applet
6538 dv02 15 0 39508 30m 8152 S 0 3.1 7:29.96 emacs
I'd suggest you've got a memory leak with your version of clock-applet. Here's mine:Notes from the leading edge
Emacs was huge twenty years ago. Its memory consumption has not significantly increased since then, while everything else has ballooned.Notes from the leading edge
Notes from the leading edge
ceco 4030 0.0 2.9 28620 15092 ? S 13:10 0:00 kdeinit: konsole
ceco 6803 28.0 1.6 11708 8368 ? S 19:13 0:00 emacs
ceco 6855 2.0 0.5 5892 2832 ? S 19:16 0:00 xterm
ceco 6869 5.2 2.0 27620 10728 ? S 19:17 0:00 gnome-terminal
:) Kterm is no better, I use mrxvt (materm.sf.net). It has the right feature set that I want. Well, it is actually more than what I want, I always compile without all those eye candy features.GNOME terminal is horrible
I love mrxvt except for one thing: no support for unicode characters. Generally this isn't a problem, but it requires setting my locale to a non-unicode one before I can use some text mode apps (mostly the text mode kernel configuration system).GNOME terminal is horrible
Try mltermGNOME terminal is horrible
regarding mlterm: anybody using its "genuine" daemon mode (allowing to keep the terminal sessions even after the X server has crashed)?GNOME terminal is horrible
It seems somehow appropriate that, after putting LWN out for the week, I updated to current Rawhide and haven't had a working X server since. It's interesting times in that part of the world...
More fun from the leading edge
Forgive me for asking an obvious question, but have you considered switching to a 64-bit version of Ubuntu?More fun from the leading edge
I have Ubuntu on another system, don't worry. But, then, the edginess of early Edgy forced me into a complete reinstall there. If you play on the leading edge, these things happen.
Ubuntu
Ubuntu
If you play on the leading edge, these things happen.
I hold back on updates for a few days on my Debian unstable system any time there are major changes to X or glibc, etc.. If there's a major problem, it will be noted almost immediately on the mailing list. This has saved me from major X problems on one occasion, and a few other minor things as well.
In that case, why complain so much about Rawhide?Did you forget it was the "leading edge"?
Was I complaining about Rawhide? Or remarking on the current state of the Rawhide experience? I have no complaints about my experiences with any of the development distributions I have run - or development kernels, for that matter. I know what game I'm playing. But that doesn't mean that no words can be said.
Did you forget it was the "leading edge"?
X not working in Fedora rawhide?
Notes from the not-so-leading edge
rm /var/lib/rpm/__db*
rpm is fragile and yum needs resources beyond the wildest dreams of my PII 300MHz laptop.dist-upgradeing to edgy.) Unfortunately, I have once had all instances of gnome-terminal terminate simultaneously with little provocation on FC6.Even further from the edge...
Indeed... we've experienced the same problem on CentOS(/RHEL) 4.3/4.4 so often that we have a script to quickly remedy the situation.
rm /var/lib/rpm/__db*
(note, we make extensive use of yum/rpm in cfengine).
$ cat /usr/local/sbin/reset_rpm_db.sh
#!/bin/sh
# resetrpm.sh - reset RPM DB when RPM deadlock occurs - 27mar2006
# run as root/sudo
# Make sure nothing is going to start rpm/yum...
/etc/rc.d/init.d/cfexecd stop
/etc/rc.d/init.d/yum stop
# while current yum/rpm/cfagent sessions...
let MOREPIDS=1
while [ $MOREPIDS -ne 0 ]
do
let MOREPIDS=0 # assume no more
# kill them
for PID in `ps axfu | grep -e yum -e rpm/rpm -e cfagent | grep -v grep | cut -b10-15 | sort`
do
let MOREPIDS=1 # there were more
echo -n "Killing "
ps axfu | grep $PID | grep -v grep
kill -9 $PID
done
done
echo ""
echo "Finished killing hung processes..."
# clean up DB
rm -f /var/lib/rpm/__db.00?
# do a quick query
rpm -q glibc
# restart daemons
/etc/rc.d/init.d/yum start
/etc/rc.d/init.d/cfexecd start
# EOF
> Occasionally a terminal will get into a mode where it refuses to respondNotes from the leading edge
> to input until it receives a mouse click or two. And, occasionally, the
> whole thing just crashes, taking down every terminal window and every
> associated ssh session.
>
> Your editor's longstanding appreciation for xterm is on the rise again.
You really shouldn't be tampering with multiple tabs (or even multiple terminals) if you're afraid of killing/closing your precious rendering process and are not into screen(1).Notes from the leading edge
See the "Compilation stops without a reason when using gnome-terminal" My "favorite" gnome-terminal problem
section here: http://www.scratchbox.org/faq/knownissues.html
Besides Xterm, Rxvt has always worked OK too (and is much faster).