Simon Stelling

Hi all,

I'm retiring. The reason is quite simple: It's not fun anymore. I look
at Gentoo and I see no common spirit, no trust but lots of fighting and
cabal calling. I really don't feel like putting time in something so
horribly broken anymore.

Have a nice day,

Simon

AMD64 has less then 100 bugs! Given that we had >340 at the beginning of this month, that's quite good. Also, this is exactly the second time in my dev-career that I see so few bugs on my todo list. Worth celebrating it with a good beer. Cheers!

Since Feb 1st I'm officially back in Gentooland, even if only for 1 1/2 months before I have to serve the Swiss army (yes, we DO have one). Time to squash lots of bugs, the AMD64 port is not exactly bleeding edge anymore: 346 bugs, among them 160 stablization requests on end of January! beandog and me spent the better part of yesterday and today fixing old bugs and marking java stuff stable, or getting rid of all these long-overdue keywording requests, so we're down to 227 bugs at the moment. So for all those poor maintainers that are waiting just for amd64 to get their work done (hi Flameeyes ) there is some hope. That being said, we still could need some helping hands, so if you want to help, join us in #-amd64-dev.

...is a truly fascinating language. So simple, so sexy. It's Turing-complete, so there's literally nothing you can't do with it. Well, at least as far as theory goes. Sure, there's nothing you can't do with it, but there's nothing you can do easily with it either, unfortunately. One thing that has always bothered me whenever I attempted to write an application in BF is that all the addresses are relative. Relative in the sense of that you can't say "go to register 3" but only "go 2 registers up". Another thing that really bothered me is that all the addresses are absolute. Absolute in the sense of that they are all in the same array, that you can't have your seperate set of registers for a sub-program.

So I tinkered a bit around and ended up with something I would call a "functional brainfuck compiler". It lets you define functions and takes care of the variable<->register mappings for the whole program. An example:

main(0) {
	$0++
	$1+++
	power(0;1;2)
	asciify(2)
	$2.
}

power(3) {
	// a ^ b = c

	copy(0;2)
	copy(1;3)
	$3-[
		multiply(0;2;4)
		copy(4;2)
		$3-
	]
}

multiply(3) {
	// a * b = c
	
	clear(2)
	copy(1;3)
	$3[
		add(0;2)
		$3-
	]
}

copy(2) {
	// $0 = source
	// $1 = dest

	clear(1)
	add(0;1)
}

move(2) {
	// $0 = source
	// $1 = dest
	
	$0[-$1+$0]
}

add(2) {
	clear(2)
	$0[-$1+$2+$0]
	move(2;0)
}

clear(1) {
	$0[-]
}

asciify(1) {
	// only works for 0 >= numbers >= 9
	clear(1)
	clear(2)
	clear(3)
	$1+++++++
	copy(1;2)
	multiply(1;2;3)
	$3-
	add(3;0)
}

You can see the language is pretty close to C in some ways. The syntax is roughly:

function-specifier(argc) { code block }

A main() function is required and must have zero arguments given (should be evident ;-)). Function definitions are the only thing that is allowed in global scope, C/C++-like comments are supported. Function calls are of the form

function-specifier(arg1;arg2;argN) where arg1...argN are the numbers of the variables given as arguments. The character $ followed by a number is interpreted as a "go to the register assigned to that variable" and replaced with the necessary amount of < or > at compilation time.

So, running the code above through the compiler gives you this:

$ ./fbf bf.b
++>+++>[-]>>>[-]<<<<<[->>+>>>+<<<<<]>>>>>[-<<<<<+>>>>>]<<[-]>>[-]<<<<[->>+>>+
<<<<]>>>>[-<<<<+>>>>]<<-[>[-]>[-]>[-]<<<<[->>>+>+<<<<]>>>>[-<<<<+>>>>]<[>[-]<
<<<<<[->>>>+>>+<<<<<<]>>>>>>[-<<<<<<+>>>>>>]<-]<<<[-]>>>[-]<[-<<+>>>+<]>[-<+>
]<<-][-]>[-]>[-]<<+++++++>[-]>>[-]<<<[->+>>+<<<]>>>[-<<<+>>>]<[-]>[-]>[-]<<<[
->>+>+<<<]>>>[-<<<+>>>]<[>[-]<<<<[->>+>>+<<<<]>>>>[-<<<<+>>>>]<-]<->[-]<[-<<<
+>>>>+<]>[-<+>]<<<<.

This looks already whole dimensions more geeky. ;-) As you can see from the main() above, it calculates 2^3 and uses asciify() to then print the result.

To verify everything, i used dev-lang/bff, the fastest BF interpreter I could find:

$ bff bf.bc
8

Now, if you have a closer look at the output, you see that there is quite a lot of crap that could be just left out. For example, the first two [-]s are completely redundant. This comes from the fact that most functions clear() their local variables prior to usage to ensure that the result is correct.

So, the code could be optimized quite a bit, and I decided to write another app that cleans up the code the compiler throws out. It's still a bit buggy and doesn't work on every piece of code, but it's progressing. The really hard problem is to debug that beast, though. Currently it only drops code that is not needed, it does not rearrange nor re-write code, so the easiest method to verify that it works correctly is to replace the dropped code with blanks. The outcome happens to look rather funny:

Cool, eh?

Just about half an hour ago a user entered #gentoo-portage and asked for old sources (portage 1.0 or so). So we've done some digging and found 1.5's sources. My god, what a world!

Just for fun I've put together a snapshot of the tree from March 24 2001, the day after drobbins added 1.5 to the tree. (It's in sys-apps/portage/files/1.5, btw.). The tarball is 11M "big", featuring 1134 ebuilds and 648 packages in 51 categories. W00t!

Between all the preparations for my graduation I've finally found the time to xml-ify the content listing for the emul-linux-x86-* packages. It looks far nicer than the old plain text file and makes it a lot easier to figure out what changed between the different versions. At least that's what I think ;)

Inspired by the current discussion on the gentoo-dev mailing list about an overall vision, I took a short break to reflect what the Gentoo/AMD64 team did during the year 2005. As an arch team, it's our main job to just keep everything up to date -- nothing one would consider 'moving mountains'. However, there were far more things that kept us busy:

• We have fixed nearly 1500 bugs that were either assigned to amd64@g.o or amd64-test@g.o
• Beside those, there were (of course) plenty of stablization requests that were "fixed".
• Thanks to the AT project, we managed to recruit 22 active ATs, of which 6 became devs
• We had two releases, 2005.0 and 2005.1, plus the bugfix-release 2005.1-r1, all beeing a success.
• With 2005.0, we introduced a complete new way of handling multilib, which allows to handle dependancies in a far easier way for the user. Yes, many had problems with the upgrade from 2004.x to 2005.0 as it was pretty complex, but after all, it was possible. Somewhen in the second half of the year, we finally deprecated 2004.3.
• The multilib-strict FEATURE helped us to find almost all packages that install libraries into the wrong directory. While it was really only usable for development in the beginning (I'd say every 4th package was broken), it turned into a very nice QA tool and only a few packages still fail because of multilib-strict.
• The stable tree was dramatically improved. I would say it is now possible to run a stable amd64 system without having a huge package.keywords filled up with ~amd64 entries: we're nearly as up to date as x86. The change of the keywording policy helped a lot to improve the situation: We're now notified through a bug whenever a maintainer thinks his package is stable enough to go stable.
• We got several boxes sponsored by different companies. With these boxes, we could provide accounts for other Gentoo developers that wanted to test their patches and/or new versions of their packages.
• Documentation has improved too of course: We got a FAQ and a HOWTO briefly explaining how to set up a 32bit chroot for those who still need one. Also, we put together a list of libraries covered by the emul-x86-linux-* packages. With this list we can guarantee that vulnerabilities are not only fixed in the real packages but also in the emul packages. We also wrote new documentation as part of the Unofficial Gentoo Development Guide.
• Gentoo/AMD64 became easier to install! As a consequence of this, we were able to deprecate the now no-longer needed technotes. The handbook should be enough to cover everything a user wants to know at install time, multilib has become far easier and lots of packages were fixed so that the list of popular apps that don't run natively on amd64 was cut down to 'Flash & OpenOffice'.
• Last but not least, we've improved the user<->developer communication a LOT. I can't show you any figures, this is just my personal impression :)
• But the most important of all: We had lots of fun.

Now have a look at this list and tell me that we didn't do anything exciting during the last year.

Today, I had a funny conversation with a user. He popped into #gentoo-portage and asked how he could compile a whole system with static binaries.

<user> how exactly, do i build static binaries using portage?

well, and since I couldn't think of a FEATURE or something, I just said

<blubb> user: you don't at all
<blubb> because nobody would want that ;)

Which he didn't seem to like very much:

<user> well clealry, i do

Why the hell would one want to have a whole system with only static binaries? It seems like a huge overhead to me. I thought perhaps there's another, more elegant way to fix his problem. Asking why he wanted static binaries, I got this reply:

<user> you do not need to know why.
<user> this is irrelevant

Bummer. Am I working for the NSA now? "I can't tell you, otherwise I'd have to kill you" comes to mind.

Anyway, I told him that I can't help him then. He asked whether hacking CFLAGS would work, which I negated. After that, he finally told me what he wanted:

<user> i am placing a single application in a chroot
<user> i would like a single binary for that application
<user> so i dont have to write perl scripts to copy library dependencies into the chroot
<user> when it is, as i understand it, totally redundant
<user> and even if they do share the same memory space, maybe i dont want that?
<user> (the libraries outside and inside the chroot)

I still didn't get why this guy wanted static libraries, but I pointed him to ROOT. Then, I thought I knew why this guy didn't want to tell me his obscure reasons:

<user> as i understand it, it is also slower to dynamically link an executable than to statically link it

A-Ha. A ricer. Take a deep breath and tell him that it'll only eat up his memory and hd space but not making anything really faster. Oh, and don't forget the

<blubb> that's why really nobody would want static linking :P

<user> however, maybe i dont want this application to share the same executable memory space as other applications?

Now I started to feeling assed. This guy wanted me to tell him how to do something that is not possible, and he didn't want to tell me why he wanted it, so screw him.

<blubb> maybe. but then you'll have to go your own paths
<blubb> gentoo is not about beeing the users' slave, it's about beeing useful :P

Obviously, he didn't like my last statement at all.

<user> as ever
<user> if you actually want to make a vague attempt at securing a gentoo system
<user> which is really rather embarising
<user> y'know?
* user has quit ("leaving")

It seems that certain people didn't get that open source developers aren't their personal slaves but free people with their own needs.

GLEP 41 got rejected in it's current state (CVS revision 1.2). I'm quite happy about that, since it wasn't just a 'No, go home'. The council pointed out a few flaws and told us, that if we update it properly, they'll vote on it again. In contrary to my last blog entry, I'm pretty optimistic, as I see space for improvements again. Also, the meeting was fun, I expected it to be much more formal and boring.

Back to GLEP 41 again. The updates we need are:

* ATs get a user@${notyetknown}.gentoo.org. When they become devs, they'll just get a forward to the @gentoo.org address, so that shouldn't be a big issue.

* Longer probation period: The council asked that the probation doesn't get shortened, i.e. it should be at least 1 month. This is a valid point, and since most of our current ATs already have more than a month, this isn't a big issue either. Also, a probation period should be introduced before the user gets AT, to see whether they will actually stick around or just go fetch a cool email address and then disappear.

* A clarification on the 'r/o access to gentoo-x86' term: ATs shouldn't need an account on dev.g.o or cvs.g.o

So, we'll get into round 2 next month.

So long,

Looking at my environment, global warming seems to get more and more noticeable. Not only because we had one of the warmest autumns this year, where you could actually still go (sun-)bathing, but also because people seem to be everything else but cool.

When I joined Gentoo, I was shocked how many arguments there were between Gentoo developers on the -core mailing list. One told me that it always was like that and that it's hard to ever change that. "You'll get used to it." some embittered devs told me. They were right, i got used to it. But still, after a bit more than a year, I'm shocked how fast people can get aggressive, how little is needed to make everybody throw slum at each other. Instead of beeing technical, people get personal, instead of staying on-topic, they start to discuss absolutely unrelated things like how one does have to understand the terms 'open source' and what the difference is between free software and open source software.

I've never posted much to -core, as I always hated it. Sometimes more, sometimes less. At the moment, there's nothing I could think of which I hate more, except drip coffee. When reading -core, it rather reminds me of a talk show than of a mailing list where technical issues are discussed in an appropriate manner.

What I find very irritating is, that on other mailing lists, devs usually are friendly, stay on-topic and don't get personal. Why is this? Is it because -core isn't public? It looks like some people do know what good manners are, but only use them in public. I really wonder whether these people fart when eating at home too, just because there's nobody looking at them.

There is evidence that Gentoo is slowly falling apart. If you don't think so, just have a look at the project listing. Gentoo is cut apart in all kinds of projects, which don't really interact. To be honest, I know nearly nothing about other projects and their environment.
Another point is, that we can't trust each other anymore. Gentoo is far too big to be a family, it's probably rather a corporate group. None of both is bad per-se, but it's definitively bad when you want to be a big family, but are a corporate group. What can we do about it? First, people should probably ask themselves "do I really care?" when replying to a thread. Second, people should ask themselves "do I know the context of the problem?" If both questions can be answered with 'yes' without hesitation, then go send your mail. I think that would massively improve the signal/noise ratio on lists like -core or -dev.

Another, probably easier solution would be to split the general mailing lists. That way, people would have to subscribe themselves to a specific mailing list, before suggesting ideas that don't affect themselves but do affect other people. I still can't understand why MIPS devs 'ask that the amd64 and x86 keywords are merged to improve the quality of the x86 tree' on a huge mailing list without first talking to the people will have to bear the consequences afterwards. Perhaps it's just me, but I don't find this very smart.

The above is just one example out of thousands. Are we unable to communicate accurate? It seems so. What can we do about it? I don't know, beside stopping to communicate at all.

Interestingly, the same problem seems to affect user<->developer communication as well. A very nice example is this one: http://gentoo-stats.org/. But that's by far not the only one. Again, just one example out of thousands.

Before writing this blog entry I thought about retiring as a dev. But still, I don't feel bitter enough to do so. So I just continue to try to ignore all these problems, since I don't know a solution to them.

...because it harms our economy.

It's been quite a long time since my last post, but yes, I'm still alive.

In the meantime, some things have changed:

• The unofficial Dev Guide now contains arch specific notes for AMD64. Thanks plasmaroo!
• I completely reinstalled my server which now also manages all my mails.
• I finally have more time again for Gentoo. School sometimes sucks.
• I began to work on the preparations for my university-entrance diploma.
• Summer's back!

Lately, I often came across packages which really would benefit from USE based DEPEND atoms. I really wonder when portage will get this feature.

Also, if somebody figures out how to turn a day into 30 hours or so, I'd really appreciate your tip. I have some neat ideas in my mind, but I don't know how to realize them without cutting down on other projects :(

When I became a dev about 9 months ago, the amd64 team had 8 developers and a bug list of about 250 issues, most of them beeing keywording requests, but nevertheless there were lots of real problems that didn't even made it into bugzilla. A few months later AMD64 apparently was used by much more people: We had over 300 bugs for only ~10 devs. Today, we're about to reach the 150 bugs mark with 21 developers and some active arch testers. It's really great to see how the distribution "grows up". Go Team, go!

Herbie compiled and assembled new emul-linux-x86-*-packages. emul-linux-x86-gtklibs-2.0 now includes gtk-engines so that 32bit-apps, especially firefox-bin, are usable again: The color-scheme is as expected. Since we also needed newer -baselibs and -xlibs we thought it'd be best to update all packages at the same time.

Have fun with flash and co ;)

Frank Schmitt asked me to include Andres Salomon's kernel patches in portage, so here they are. Currently there is only =sys-kernel/as-sources-2.6.10-r7, marked testing for x86 and amd64. If you use the as patches anyway, please help me testing them, especially on other arches. As I'm not in the kernel team, please assign bugs directly to me.

Happy kernel baking!

A few days ago I received a copy of a mail from an unsatisfied user who couldn't install Gentoo/AMD64 on his box:

I recently purchased Gentoo Linux 2005.0 for Amd 64, and i'm having a real
hard time just installing it. To me it seems to be impossible to install,
just using an text-based environment, even though i've been doing computers
for about 12 years.

He told us that he feels cheated because the copy he purchased is too cheap to send it back. I feel sorry for him. The only, cold comfort is that he didn't loose much money.

Then followed a little rant that made me pretty thoughtful the last days:

The real reason why people don't use these kind of operating-systems is
that it's impossible to install without a phd. And there is no support to
help you, what so ever. I have tried many linux versions, but they are all
the same. So from now on, i will probably never try anything that isn't
made by microsoft. And that is a shame. Cause we all know how horriffic
windows is.
I really wish you could have made Gentoo for people that does'nt have 2
years to learn how to install it before they can use it.
Too bad.

Is Linux still in an experimental stage? What about the support? How could we improve?

Looking at our handbooks, mailing lists, irc channels, forums, wikis, bugzilla etc. I think you get much more support with a Linux system than with a commercial one, at least as end user. Gentoo currently has about 312 more or less active developers, and I don't like the thought that only one had to sit on a hotline ($3.12 per minute/first 10min free), but that's what some people obviously call support. We have lots of great users that spend a lot of their free and rare time to help other users. Why don't they get credit? Just because they are users and not developers? They help us making Gentoo a better distribution.

In this spirit I'd like to thank all the users who help us every day even when I break the tree ;)

I really wish you could have made Gentoo for people that does'nt have 2
years to learn how to install it before they can use it.

This probably will change in future, when GLI will be out.
I really like the GLI project and the idea of automate another step. Nevertheless I feel queasy whenever I think of such users that ask for "support". Will they support other users afterwards? Will they help fixing bugs? Or will they just prevent developers from fixing bugs for those who provide support?

Today I nearly went mad while trying to get gdb and ddd working. Every program i wanted to debug just gave me this:

(gdb) run
Starting program: /root/hello
Cannot exec : No such file or directory

Program exited with code 0177.

After trying several versions, searching on bugs.g.o, asking in multiple irc channels and a lot of swearing i had the flash of genius that I could actually google for this cryptic message... Perhaps I should change firefox' homepage back to google instead of my favourite news portal.

Finally, I got gdb working, I just had to export SHELL=/bin/bash i.e. echo "SHELL=/bin/bash" >> /etc/profile.env. Why on earth does gdb need $SHELL?

The last time I installed Gentoo, devfsd was the standard device-fs daemon. This time, I had several problems: First, I didn't get a console, because udev failed to create /dev/ttyX. Then, it did create /dev/md0 but didn't bother about /dev/md1 where all my data is stored. So i had to browse around in /dev and symlink the files myself. As a result of these experiences I'm back at devfsd, even if it's considered obsolete. It may be obsolete, but it works. Why do we have to use dynamically generated /dev dirs anyway? An old static mknod.sh or so would have done the same job as well as udev. Why do things have to be more complicated than necessary?