Charles's KDE Journal

Debian

Tue, 06 May 2008 07:13:13 GMT

A coupl'a developments in my distribution of choice:

Debian Weekly News is being published again, after a nearly year-long hiatus
Steve McIntyre was crowned king of Debian for the year, replacing Sam Hocevar

Sam had thoroughly failed miserably in making "Debian more sexy", sadly. However, there are at least a few reasons to be optimistic. For example, Bart Coppens once complained about Debian stupidity. The Debian team ultimately decided that they cannot continue treating their users like beta testers and fixed his complaint (4 days too late).

My machine suspends with the current debian kernel, as opposed to a very carefully self-compiled one.

It sucks that the nvidia drivers (with module-assistant) are still unavailable on testing; I can't really test it if I need to switch to unstable just to get a working X server (that isn't painfully slow). I'm hoping to switch to ATI graphics soon (as it's possible that we're getting open source drivers for them in the foreseeable future). NVidia is only happy with me as a user for the first month after I buy their hardware.

My server, running Debian etch, has been up for nearly 500 days, with the reiser4 patch. The server has not, as of yet, been convicted of murder.

It's a shame that the Debian team puts so little effort into being desktop-friendly. They could easily crush Ubuntu if they just got a pretty installer that would create a functional KDE desktop by default.

Does Debian have a mailing list of things that users of "testing" should know? For example "package X is broken because we're arrogant @#$☯@☢*$&☠^ that don't care about our users and it will be fixed next week" announcements would be most helpful. I would prefer it in the form of an RSS feed.

If you post comments, consider getting an OpenID account in lieu of a LiveJournal account.

Port Wine

Wed, 16 Apr 2008 06:43:08 GMT

From the Crackipedia article on Port wine:

If the port becomes forestalled at some point, it is considered poor form to ask for the decanter directly. Instead, the person seeking a refill would ask of the person who has the bottle: "Do you know the Bishop of Norwich?" (after the notoriously stingy Bishop). If the person being thus queried does not know the ritual (and so replies in the negative), the querent will remark "He's an awfully nice fellow, but he never remembers to pass the port."

Nobody showed up to our LugRadio booth with flowers in their hair, which goes to show how many people actually read my journal. Also I'm supposed to write a dot article about it.

KDE at LugRadio Live USA

Tue, 08 Apr 2008 16:53:27 GMT

KDE will be present at LugRadio Live USA this weekend at the Metreon in San Francisco, California.

Please come and don't forget to wear flowers in your hair. (No, really, *ahem* ;)

We will be presenting KDE 4.

Oh yeah, and I just updated the hotspot on kde.org to announce it.

perfecting gcc's output

Fri, 21 Mar 2008 03:26:52 GMT

Pretty up your console!

make -j
- atomicpipe
- atomicgcc
  - make dirs and symlinks
Colorgcc
- colorgcc.diff
A better make
More less is more
A better grep
A better ls

make -j

If you have multiple CPUs, or if you have one cpu and a slow harddrive, you should be using make with the -j option. Problem with -j is that it causes each of the gcc processes to mix their output, which can be confusing!

For this, I wrote a perl script that takes its input, and doesn't output it until it's done reading:

atomicpipe

#!/usr/bin/perl -w
use strict;
my $data="";
while (0 != sysread(STDIN, $data, 1024, length($data))) { }
syswrite(STDOUT, $data);

put that in your $PATH, chmod +x

Now, you need another script to have gcc make use of this script:

atomicgcc

#!/bin/sh
gcc=$(basename "$0")
set -o pipefail
export CGCC_FORCE_COLOR=1
exec colorgcc "$gcc""$@" | atomicpipe

Also put this in your $PATH and chmod +x. You'll notice that it uses colorgcc. Continue to the next section for that!

Make the programs gcc, c++, g++, and cc symlinks to this atomicgcc script. Those symlinks should go somewhere in your $PATH that comes before /usr/bin. I like to create a ~/.local/bin for those purposes.

Some distros have ~/bin in your $PATH by default, but I think that's lame because then you clutter up your home directory with non-hidden directories, *and* it doesn't let you provide an additional $LD_LIBRARY_PATH and $KDEDIRS entry.

Make dirs and symlinks

mkdir -p ~/.local/bin
cd ~/.local/bin
#assumes atomicgcc is in ~/.local/bin
ln -s atomicgcc c++
ln -s atomicgcc g++
ln -s atomicgcc gcc
ln -s atomicgcc cc

Don't forget to add export PATH=$HOME/.local/bin:$PATH to your ~/.bashrc

Colorgcc

Grab colorgcc, apply this patch:

colorgcc.diff

--- colorgcc.dist   2008-02-28 06:21:55.000000000 -0800
+++ colorgcc   2008-03-12 12:15:54.000000000 -0700
@@ -221,7 +221,13 @@
 $0 =~ m%.*/(.*)$%;
 $progName = $1 || $0;

-$compiler = $compilerPaths{$progName} || $compilerPaths{"gcc"};
+if ($progName eq "colorgcc")
+{
+   $progName = shift @ARGV;
+}
+
+$compiler = "/usr/bin/$progName";
+
 @comp_list = split /\s+/, $compiler;
 $compiler = $comp_list[0];
 @comp_args = ( @comp_list[1 .. $#comp_list], @ARGV );

This patch allows you to specify the compiler colorgcc should use on its list of command line parameters. This allows you to use multiple compilers with this same system (just make gcc-4.1 or gcc-3.4 symlinks to atomicgcc as well). It's not absolutely necessary, but it is necessary if you want my "atomicgcc" script to work without modification.

Take your patched version, and put it in your path. chmod +x

A better make

Stick this in your .bashrc:

alias make='nice make -j6'

Instead of "6" on that line, you should specify a number that's approximately twice that of the number of CPUs you have. If your CPUs have a small cache, use a smaller number. If your machine has little memory use a smaller number. If your harddrive is really slow, or you use an NFS drive, use a much larger number.

niceing it will mean that you can multitask on your computer while you wait for make to finish.

More less is more

alias less='less -R'

-R means that if you pipe colorgcc's output to less (which you should totally be preferring over more, because it's way better), the colors still show up.

A better grep

alias grep='grep --color=tty -d skip'

(From Ulrich Drepper's article)

a better ls

You probably know about ls --color, but do you know about ls -F?

alias ls='ls --color -F'

Turns:

dir link exec

Into:

dir/ link@ exec*

Note the cute little symbols.

Update: I added the "set -o pipefail" line to the atomicgcc script, as it makes configure scripts work again

Crazy Things

Tue, 19 Feb 2008 22:37:06 GMT

Warning: This post contains computer geekery.

The very first assignment I had in University was just a simple "ask the user for some numbers and print the average". I implemented it in 1300 lines of code by writing a parser for a simple programming language, building a parse tree, and then having the parse tree execute itself. The actual program is a string at the bottom of the source file.

Last night, I went just a little bit crazy, and added an assembler to the program. Now the parse tree spits out the native CPU instructions which it then executes. This is done in 1600 lines of code. Now it runs twice as fast.

If I were really crazy, I'd make it self hosting.

"Believe me, the evidence is there"

Thu, 10 Jan 2008 07:02:50 GMT

"Believe me, the evidence is there" is something you frequently here from Global Warming Preventionists. Then they say they don't know what the evidence is. But they know it's there, because they heard it so.

They're really bad at proving their point.

Well, here's that evidence. If you respond well to pictures, look at page 7. The blue is "expected change in temperature from natural causes" and the purple is "change in temperature with man-made causes".

The following chapters of the IPCC report are all "how do we get Texans to drive smaller cars" and variations on that theme.

My next post might be related to american politics, if I ever get around to writing it.

Debian

Tue, 06 Nov 2007 04:37:11 GMT

I was reading troy_at_kde's journal entry and I got to thinking: I get it pretty good as a Debian testing user.

For one thing, my operating system is always up-to-date; I get all the latest gizmos within week or two of their official release, and in that week, all the little wrinkles in the packaging have been solved. I can "apt-get" my machine without fear of it breaking, and I never ever have to do a revolutionary upgrade that takes hours.

testing is a moving target for Debian, it trails what Debian calls their unstable branch by a few days which results in "not so many upgrades" all the time. Maybe a hundred or two MiBs per week.

Debian unstable is a misnomer - it doesn't mean "likely to crash", it means "likely to change". (Debian also has an experimental branch with "things that are likely to crash").

What's also great about Debian is that the packages are mostly pristine; this means that their version of (for example) KDE is very similar to KDE's version of KDE. Sadly, even Debian can't resist the hubris of "we know KDE better than KDE" and as a result, they also apply some patches which more often than not cause some regressions somewhere. I really wish they'd stop doing that. This disease is hardly unique to Debian, though. (Although their whole "IceWeasel" thing has me with really mixed feelings: I can't decide if I support Debian's decision of questioning the Mozilla Foundation's good judgment, or the Mozilla Foundation for having such awful judgment).

Debian also does have a graphical installer, but it's not enabled by default, for some dumb reason for which I'm sure they have a good excuse. Debian's installer is fast because it doesn't install lots of junk; the default is just to give you a working base operating system. Then you boot into your new operating system and install anything else you want. You can install the essential stuff to begin with (kdebase) and then have it install the rest while you're being productive.

I think the most refreshing thing about Debian testing is the combination of up-to-dateness and rock solid stability. No other distro has ever managed that while still providing a huge number of packages.

So, to summarize: try Debian. It might be three clicks to give you a whole bunch of stuff in some distros, but apt-get puts you one command away from anything you want.

I would like to make a few suggestions to the Debian team:

obviously, enable the graphical installer by default, it will make it more sexy.
Please stop applying so many patches to the packages, especially on libraries used by many applications. Frequently, software depends on behavior that you can't possibly test for. You don't know what you may be breaking
Make a "moving target stable" suitable for desktop users; it would be immune to the problem mentioned by Troy. Desktop users are also willing to tolerate slightly less reliability (testing) in favor of features than server (stable) users.
Respond to bug reports promptly, be polite, and provide timeframes for fixes; reaching out to your users is Debian's greatest flaw

Guest Journal: What if pears were lemons?

Mon, 10 Sep 2007 09:21:42 GMT

This is a guest journal written by Frederik Schwarzer.

What if pears were lemons?

Would you still like them?

Once in a while I read weblogs clarifying linux users are too ignorant and arrogant to let others be part of the family. The assumption is that Linux users have spent years learning to type all the cryptic commands in white letters on black screens that they do not want others to benefit from the advantages of Linux. Thus they laugh at newbies, mock them and send them back to Windows.

I see several problems in those arguments. First of all they do not respect the fact that the Linux community is not a monolithic chump with one opinion and one voice. At least they have to be separated into two groups today. Those who understand the basics and those who do not. It is often said that you do not have to know how an engine works to drive a car, so why should basic knowledge be important to run Linux? It is not. But you have to bring your car to the repair shop every time you hear sounds you do not know. And so you have to do with your Linux box as well. So where is the point of such comparison? If you do not know your equipment, you have to ask others who do (and pay for it). I do not see many of those who are familiar with the basics of Linux usage complaining about insufficient number of users migrating to Linux. They were satisfied with what they had for years and they will be in the future. I do not know where the majority of those stand who want to see Windows users migrating to Linux. But they are not the Linux community. And anyway, what goals would the Linux community achieve when more and more Windows users would switch?

In my opinion there are two things: First, the bigger the user base, the bigger the company support. The second thing would be the growing voice of users who want everything easier and simpler and "more like Windows, but free" (as in free beer). I hear those voices every week and they indeed get louder. And they are heard. I use Debian GNU/Linux and I install it from scratch and as lean as possible. That takes its time. But for me it takes as much time to purify e.g. a Kubuntu installation I would want to work with.

I chose Linux nine years ago and my motives were not a shiny desktop or the ease of use. In fact I was bound to the console for about two years because I did not get X working on my hardware. But I learned things that I can use today. I learned to use the manpages, to read documentation and to reach my goals by trial and error. Granted, I got lazy and now I rather ask than read for hours. =) But I can, if I want to. So what is wrong with it? Nobody needs to do that. Not everybody has the time and not everybody wants that. But what will remain if Linux gets simpler and easier for GUI users? I fear that the really simple backend structure will suffer from that long-term. Switching to Linux because Windows sucks is not the right motive. "Hey, I already dumped Windows, so fucking tell me how Linux works and show me something shiny, or I just go back and you will lose me again." That's the spirit I often pick up.

Is it really necessary to change Linux to better meet their needs?
Maybe. And maybe it is necessary for those who like simple and clean structures in the background to switch to another operating system as well from time to time. It is not the name that keeps me using Linux at the moment. And call me ignorant and arrogant but I like the way Linux works and I do not like revolutionary changes or the guys that scream for that every day.

Faith+WebKit

Wed, 05 Sep 2007 06:09:02 GMT

(clickie for biggie)

So starting Saturday in the vaguely early morning (by weekend standards) and progressing into the wee hours of the night, followed by the sunday and the three-day-weekend-monday. I made a number of amazing milestones in my new project: WebKit (née KHTML) ported over to Faith.

Then I tacked on support for images today after getting home from work.

I've learned a few things about WebCore, especially compared to KHTML. First, the the code has even fewer comments than KHTML, and the functions have even more ambiguous names. It's a jungle out there, I thought. I'm not sure if to blame WebCore, or just that it supports multiple platforms, unlike KHTML. And I did manage to get this done in 3 days.

At the end of the day, WebCore's code might be a chaotic, but hey, at least it doesn't have the Denial of Service attack vulnerability I found in FireFox and IE last week.

Anyway, rounding up to the nearest whole percent, I still have 100% of the work to do before this could be a usable web browser. Let's start with putting spaces between words and then maybe work up to letting you follow links.

I'm not in Glasgow, but I'm in the UK

Wed, 04 Jul 2007 17:58:28 GMT

I'm currently in Nottingham, England until the 11th. Thus I'm not at akademy anymore. Just FYI.

Charles's KDE Journal

Debian

Port Wine

KDE at LugRadio Live USA

perfecting gcc's output

Contents

make -j

atomicpipe

atomicgcc

Make dirs and symlinks

Colorgcc

colorgcc.diff

A better make

More less is more

A better grep

a better ls

Crazy Things

"Believe me, the evidence is there"

Debian

Guest Journal: What if pears were lemons?

Faith+WebKit

I'm not in Glasgow, but I'm in the UK