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:
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 😛
<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 😛
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,