* Re: [9fans] crosstool fails on gentoo [not found] ` <200805282337.11349.yann.morin.1998@anciens.enib.fr> @ 2008-06-01 15:12 ` Enrico Weigelt 2008-06-02 19:25 ` Uriel 2008-06-05 11:11 ` Enrico Weigelt 0 siblings, 2 replies; 16+ messages in thread From: Enrico Weigelt @ 2008-06-01 15:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote: > On Wednesday 28 May 2008 18:52:14 Lance Spaulding wrote: > > I'm trying to use crosstool-ng to build an ARM toolchain but if fails > > with the following error message: > > [ALL ] *** [Gentoo] sanity check failed! *** > > [ALL ] *** libtool.m4 and ltmain.sh have a version mismatch! *** > > [ALL ] *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.24 Debian 1.5.24-1") *** > > This was already reported a few days ago: > http://sourceware.org/ml/crossgcc/2008-05/msg00080.html > > > It looks like several people have ran into this error on gentoo but I > > haven't been able to find a solution anywhere (and got no replies to > > this question in the gentoo forums). Anyone have a fix for this? > > As suggested by Enrico in that message: "we should recreate the autotools+libtool > stuff before compiling." Right, manually running autoreconf -fi && libtoolize on the already uncompressed tree fixed it for me. Of course this manual hack is ugly, it should be done automatically after decompression. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-01 15:12 ` [9fans] crosstool fails on gentoo Enrico Weigelt @ 2008-06-02 19:25 ` Uriel 2008-06-02 19:55 ` ron minnich 2008-06-05 11:11 ` Enrico Weigelt 1 sibling, 1 reply; 16+ messages in thread From: Uriel @ 2008-06-02 19:25 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs Thanks for reminding us how boring and sad life in Plan 9 is without the sadomasochistic joys and pleassures of crosscompiling in the holy gnu/auto*hell land. Specially loved the line: >> > [ALL ] *** [Gentoo] sanity check failed! *** Wonder if they had Einstein's definition of insanity in mind... the (open and closed source) software industry certainly could make a good textbook example... maybe they will use it for the next DSM. uriel On Sun, Jun 1, 2008 at 5:12 PM, Enrico Weigelt <weigelt@metux.de> wrote: > * Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote: > >> On Wednesday 28 May 2008 18:52:14 Lance Spaulding wrote: >> > I'm trying to use crosstool-ng to build an ARM toolchain but if fails >> > with the following error message: >> > [ALL ] *** [Gentoo] sanity check failed! *** >> > [ALL ] *** libtool.m4 and ltmain.sh have a version mismatch! *** >> > [ALL ] *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.24 Debian 1.5.24-1") *** >> >> This was already reported a few days ago: >> http://sourceware.org/ml/crossgcc/2008-05/msg00080.html >> >> > It looks like several people have ran into this error on gentoo but I >> > haven't been able to find a solution anywhere (and got no replies to >> > this question in the gentoo forums). Anyone have a fix for this? >> >> As suggested by Enrico in that message: "we should recreate the autotools+libtool >> stuff before compiling." > > Right, manually running autoreconf -fi && libtoolize on the already uncompressed > tree fixed it for me. > > Of course this manual hack is ugly, it should be done automatically after > decompression. > > > cu > -- > --------------------------------------------------------------------- > Enrico Weigelt == metux IT service - http://www.metux.de/ > --------------------------------------------------------------------- > Please visit the OpenSource QM Taskforce: > http://wiki.metux.de/public/OpenSource_QM_Taskforce > Patches / Fixes for a lot dozens of packages in dozens of versions: > http://patches.metux.de/ > --------------------------------------------------------------------- > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 19:25 ` Uriel @ 2008-06-02 19:55 ` ron minnich 2008-06-02 19:57 ` erik quanstrom 2008-06-02 20:09 ` Eric Van Hensbergen 0 siblings, 2 replies; 16+ messages in thread From: ron minnich @ 2008-06-02 19:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs actually there is a kind of interesting trend I'm noticing in the open source world. Not a good one. The OLPC has managed the accomplishment of booting 2-3x slower on linux than xp, and the environment is slow as snails. open office is bigger, slower, and buggier in my experience than MS office. I keep reviewing papers that want to simplify things by ... adding another layer of software! I just reviewed another paper that was more or less changing something about a process. In Plan 9, you add a new ctl command. In linux, you, what else? add a new system call. The OSS world has built such a complex house of cards that the only thing people know to do is add more stuff to make it simpler. And we can see how well that's working. It's quite a comment on the state of play that the OLPC guys, to improve the system overall, had to dump Linux for Windows. On the other hand, if you've used an OLPC, it makes some sense -- great machine, dog slow. For no reason: inferno runs on it like a bat. ron ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 19:55 ` ron minnich @ 2008-06-02 19:57 ` erik quanstrom 2008-06-02 20:09 ` Eric Van Hensbergen 1 sibling, 0 replies; 16+ messages in thread From: erik quanstrom @ 2008-06-02 19:57 UTC (permalink / raw) To: 9fans > I keep reviewing papers that want to simplify things by ... adding > another layer of software! evidently, someone's only handing you the first halves of papers. the second halves describe how the original layer was simplified by not needing to worry at all about ... oh, wait. my bad. never mind. - erik ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 19:55 ` ron minnich 2008-06-02 19:57 ` erik quanstrom @ 2008-06-02 20:09 ` Eric Van Hensbergen 2008-06-02 20:37 ` Uriel 1 sibling, 1 reply; 16+ messages in thread From: Eric Van Hensbergen @ 2008-06-02 20:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jun 2, 2008 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote: > > I keep reviewing papers that want to simplify things by ... adding > another layer of software! > That's a really great observation. I see it all the time as well, for some reason simplification has come to mean add new layers of abstraction. But it is a false simplification, it may simplify the API, but the overall system complexity increases (and usually lead to a decrease in system efficiency). All productivity factors become harder (development may be easier, but debugging, performance debugging, and management typically become more difficult). Someone really needs to remind folks that "system simplification" involves a reduction in the number of layers, not an increase in them. -eric ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 20:09 ` Eric Van Hensbergen @ 2008-06-02 20:37 ` Uriel 2008-06-02 20:45 ` erik quanstrom 2008-06-02 22:32 ` Roman Shaposhnik 0 siblings, 2 replies; 16+ messages in thread From: Uriel @ 2008-06-02 20:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Oh, but Sun (who else?) has the solution! When I was speaking at FOSDEM I came across a Dtrace guy. He was boasting about how wonderful it was to be able to debug and profile stuff with this huge kernel hack (third biggest subsystem in the Solaris kernel, forgot exactly how many, but a few hundred thousand lines of code). In the end to do stuff 99% of which can be done in Plan 9 with iostat and acid, and the other 1% can be done with print statements and careful thought. But no, he told me, they needed this whole new layer of complexity (IIRC it includes even a bytecode interpreter/compiler inside the kernel), because I didn't understand how hard it had become to debug software this days, you had a bug, and you had to go from apache, to the Java Application Server, to Oracle, to the file system, etc, etc. millions and millions of lines of code, and it had become impossible to debug or profile applications anymore, because the issue could be anywhere in this huge stack... so what they do? they add *yet another layer of complexity so you can look at all that stuff at the same time*. And even more funny was to see the BSD and Lunix folks falling all over themselves to be the first ones to get the same thing for their systems. The idea of simple and sane interfaces between simple and carefully designed components is totally lost, it is all about extensibility (XML!) and 'standards' (more XML!), and if you want to make things faster, of course the solution is to add a huge layer of caches and other magic... (I still laugh every time I think of distcc) But the worst is when they say 'ok, this has got out of hand, we have to go back and start from scratch'. They end with epitomes of 'second system syndrome', as seen in apache 2. which is about a hundred times more complex than apache 1, and adds a dozen new layers of abstraction (in the name of performance, portability and generality, of course!), Firefox (I stopped counting millions of lines of code a while ago), Java, and so many others. But enough ranting and rambling for today, just remember what Gordon Bell said, because nobody else will: "The cheapest, fastest, and most reliable components are those that aren't there." Peace uriel On Mon, Jun 2, 2008 at 10:09 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > On Mon, Jun 2, 2008 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote: >> >> I keep reviewing papers that want to simplify things by ... adding >> another layer of software! >> > > That's a really great observation. I see it all the time as well, for > some reason simplification has come to mean add new layers of > abstraction. But it is a false simplification, it may simplify the > API, but the overall system complexity increases (and usually lead to > a decrease in system efficiency). All productivity factors become > harder (development may be easier, but debugging, performance > debugging, and management typically become more difficult). > > Someone really needs to remind folks that "system simplification" > involves a reduction in the number of layers, not an increase in them. > > -eric > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 20:37 ` Uriel @ 2008-06-02 20:45 ` erik quanstrom 2008-06-02 21:00 ` Uriel 2008-06-02 22:32 ` Roman Shaposhnik 1 sibling, 1 reply; 16+ messages in thread From: erik quanstrom @ 2008-06-02 20:45 UTC (permalink / raw) To: 9fans > But no, he told me, they needed this whole new layer of complexity > (IIRC it includes even a bytecode interpreter/compiler inside the > kernel), because I didn't understand how hard it had become to debug > software this days, you had a bug, and you had to go from apache, to > the Java Application Server, to Oracle, to the file system, etc, etc. > millions and millions of lines of code, and it had become impossible > to debug or profile applications anymore, because the issue could be > anywhere in this huge stack... so what they do? they add *yet another > layer of complexity so you can look at all that stuff at the same > time*. what happened to interfaces? what good is a software layer — or a kernel, even — if i have to chase bugs "through" them. if this is the case they're not hiding anything from me. it used to be that even a function had to hide something to earn its keep. - erik ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 20:45 ` erik quanstrom @ 2008-06-02 21:00 ` Uriel 0 siblings, 0 replies; 16+ messages in thread From: Uriel @ 2008-06-02 21:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > what happened to interfaces? what good is a software layer — > or a kernel, even — if i have to chase bugs "through" them. > if this is the case they're not hiding anything from me. > > it used to be that even a function had to hide something to > earn its keep. We got mmap, ioctl, and xml now, and they are all *extensible* no need for any pesky 'interfaces' anymore. uriel > - erik > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 20:37 ` Uriel 2008-06-02 20:45 ` erik quanstrom @ 2008-06-02 22:32 ` Roman Shaposhnik 2008-06-02 23:00 ` Iruata Souza 1 sibling, 1 reply; 16+ messages in thread From: Roman Shaposhnik @ 2008-06-02 22:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2008-06-02 at 22:37 +0200, Uriel wrote: > He was boasting about how wonderful it was to be able to debug and > profile stuff with this huge kernel hack (third biggest subsystem in > the Solaris kernel, forgot exactly how many, but a few hundred > thousand lines of code). In the end to do stuff 99% of which can be > done in Plan 9 with iostat and acid, and the other 1% can be done with > print statements and careful thought. > > But no, he told me, they needed this whole new layer of complexity > (IIRC it includes even a bytecode interpreter/compiler inside the > kernel), because I didn't understand how hard it had become to debug > software this days, you had a bug, and you had to go from apache, to > the Java Application Server, to Oracle, to the file system, etc, etc. > millions and millions of lines of code, and it had become impossible > to debug or profile applications anymore, because the issue could be > anywhere in this huge stack... so what they do? they add *yet another > layer of complexity so you can look at all that stuff at the same > time*. > > And even more funny was to see the BSD and Lunix folks falling all > over themselves to be the first ones to get the same thing for their > systems. DTrace is an interesting example. I'd be the first one to agree with you, if it wasn't for the fact that it *is* useful for *me*. It just is. And it is useful at exactly the right level -- the level of a simple tool. Like awk or sed. Its like a protective suit for walking in sh^H^Hmud -- all I care about is that it doesn't leak and doesn't make me sweat. If its engineering is complex -- well, it has to interface with that gooey stuff on the outside after all. I think I'll drop this analogy now (too much worrying about ISS and the little accident that they almost had there) but I hope you'll get the idea? Of course, I'd much rather use Plan9 and not need that kind of technology. The guy was right, thought. unless Oracle gets ported to Plan 9 (and somehow magically gets cleansed along the way) there's no way for the simple sane system to shine. I guess it really is a bit of chicken and the egg problem. > The idea of simple and sane interfaces between simple and carefully > designed components is totally lost, it is all about extensibility > (XML!) and 'standards' (more XML!), and if you want to make things > faster, of course the solution is to add a huge layer of caches and > other magic... Agreed 100% > (I still laugh every time I think of distcc) I don't understand this point. Would you like it better it was a services you get out of nodes who export their "compile/link" interface into your namespace? > But enough ranting and rambling for today, just remember what Gordon > Bell said, because nobody else will: > > "The cheapest, fastest, and most reliable components are those that > aren't there." Couldn't agree more! Thanks, Roman. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 22:32 ` Roman Shaposhnik @ 2008-06-02 23:00 ` Iruata Souza 2008-06-02 23:21 ` ron minnich 0 siblings, 1 reply; 16+ messages in thread From: Iruata Souza @ 2008-06-02 23:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jun 2, 2008 at 7:32 PM, Roman Shaposhnik <rvs@sun.com> wrote: > On Mon, 2008-06-02 at 22:37 +0200, Uriel wrote: >> *yet another layer of complexity so you can look at all that stuff >> at the same time*. >> > all I care about is that it doesn't leak I don't have any solaris boxes to play now, but I remember when taking a dtrace course - more or less two years ago - that I managed to see the performance of a nice machine go down only by setting all it's tracing points. I know that this could be considered normal if it wasn't for the fact that, with two xterms opened, the one which started dtrace, after a series of ^C, had 'transfered' to it the command-line history of the other xterm. It was a peculiar situation since the instructor was telling us about the non-intrusiveness of the tool. iru ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 23:00 ` Iruata Souza @ 2008-06-02 23:21 ` ron minnich 2008-06-03 0:50 ` Iruata Souza 0 siblings, 1 reply; 16+ messages in thread From: ron minnich @ 2008-06-02 23:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <iru.muzgo@gmail.com> wrote: > I don't have any solaris boxes to play now, but I remember when taking > a dtrace course - more or less two years ago - that I managed to see > the performance of a nice machine go down only by setting all it's > tracing points. I know that this could be considered normal if it > wasn't for the fact that, with two xterms opened, the one which > started dtrace, after a series of ^C, had 'transfered' to it the > command-line history of the other xterm. It was a peculiar situation > since the instructor was telling us about the non-intrusiveness of the > tool. > it's worth reading the papers. Dtrace is quite capable. But look at the issues. You are taking a piece of code and splicing in another piece of code. It can get fun. What if someone was running the code you are splicing (think: SMP). What about time to remove it: make sure that (a) nobody is running the spliced in code (how do you do that in the general case) and (b) nobody is trying to run where you are putting the code back. What if the original code had an INT instruction? What if it tickled an IRQ? What if code you spliced in takes a fault? Check out the kprobes device in linux to see how nasty it can get. At the same time, people delivering software to end users make good use of dtrace, so it's kind of hard to fault Sun for putting it in there -- they do have paychecks to hand out. And I expect that lots of customers demand that it stay in there ... ron ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-02 23:21 ` ron minnich @ 2008-06-03 0:50 ` Iruata Souza 2008-06-03 0:54 ` erik quanstrom 0 siblings, 1 reply; 16+ messages in thread From: Iruata Souza @ 2008-06-03 0:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jun 2, 2008 at 8:21 PM, ron minnich <rminnich@gmail.com> wrote: > On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <iru.muzgo@gmail.com> wrote: > >> I don't have any solaris boxes to play now, but I remember when taking >> a dtrace course - more or less two years ago - that I managed to see >> the performance of a nice machine go down only by setting all it's >> tracing points. I know that this could be considered normal if it >> wasn't for the fact that, with two xterms opened, the one which >> started dtrace, after a series of ^C, had 'transfered' to it the >> command-line history of the other xterm. It was a peculiar situation >> since the instructor was telling us about the non-intrusiveness of the >> tool. >> > > it's worth reading the papers. Dtrace is quite capable. > > But look at the issues. You are taking a piece of code and splicing in > another piece of code. It can get fun. What if someone was running the > code you are splicing (think: SMP). What about time to remove it: make > sure that (a) nobody is running the spliced in code (how do you do > that in the general case) and (b) nobody is trying to run where you > are putting the code back. What if the original code had an INT > instruction? What if it tickled an IRQ? What if code you spliced in > takes a fault? > > Check out the kprobes device in linux to see how nasty it can get. > > At the same time, people delivering software to end users make good > use of dtrace, so it's kind of hard to fault Sun for putting it in > there -- they do have paychecks to hand out. And I expect that lots of > customers demand that it stay in there ... > just like many people, I have made good use of dtrace myself. but the need for a tool like that seems to me one more evidence of the trend in talk about in your first post. in the pile of layers one has to dig to find/fix/rework something, sometimes dtrace seems like the better - or even the only one at hand - thing to deal with it. put short: dtrace-like tools are good but, in general, having the need for it is not. iru ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-03 0:50 ` Iruata Souza @ 2008-06-03 0:54 ` erik quanstrom 2008-06-03 2:02 ` Nick LaForge 0 siblings, 1 reply; 16+ messages in thread From: erik quanstrom @ 2008-06-03 0:54 UTC (permalink / raw) To: 9fans > just like many people, I have made good use of dtrace myself. but the > need for a tool like that seems to me one more evidence of the trend > in talk about in your first post. in the pile of layers one has to dig > to find/fix/rework something, sometimes dtrace seems like the better - > or even the only one at hand - thing to deal with it. > put short: dtrace-like tools are good but, in general, having the need > for it is not. it's abstractions, all the way down. at least until mack burps. he always does. - erik ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-03 0:54 ` erik quanstrom @ 2008-06-03 2:02 ` Nick LaForge 0 siblings, 0 replies; 16+ messages in thread From: Nick LaForge @ 2008-06-03 2:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > it's abstractions, all the way down. at least until > mack burps. he always does. > > - erik we don't get upset about the complexity within hardware abstractions. i guess, because we don't usually see it? and, because software is cheap, it tends to be optimized for the immediate future, to hack and ask questions later, even if that means exploding complexity into my face later on (did i just argue against source code availability?) though we've come full circle to the original hardware interface with 'tiny horrible not xen' and the like. Only the interface is buggier and slower. but we're all familiar with buggy and slow hardware too.. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-01 15:12 ` [9fans] crosstool fails on gentoo Enrico Weigelt 2008-06-02 19:25 ` Uriel @ 2008-06-05 11:11 ` Enrico Weigelt 2008-06-05 11:21 ` Bruce Ellis 1 sibling, 1 reply; 16+ messages in thread From: Enrico Weigelt @ 2008-06-05 11:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * Enrico Weigelt <weigelt@metux.de> wrote: <snip> uups, seems I've sent my mail to the wrong list ;-o (now it's clear why nobody responded @ crossgcc list) Coffe was out at that day ... Sorry for the confusion. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] crosstool fails on gentoo 2008-06-05 11:11 ` Enrico Weigelt @ 2008-06-05 11:21 ` Bruce Ellis 0 siblings, 0 replies; 16+ messages in thread From: Bruce Ellis @ 2008-06-05 11:21 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs It was good to see Uriel back in action. And the gmail ads never cease to amaze me ... this is what I got for this e-mail. www.constipationMiracleCure.com brucee On Thu, Jun 5, 2008 at 9:11 PM, Enrico Weigelt <weigelt@metux.de> wrote: > * Enrico Weigelt <weigelt@metux.de> wrote: > > <snip> > > uups, seems I've sent my mail to the wrong list ;-o > (now it's clear why nobody responded @ crossgcc list) > > Coffe was out at that day ... Sorry for the confusion. > > > cu > -- > --------------------------------------------------------------------- > Enrico Weigelt == metux IT service - http://www.metux.de/ > --------------------------------------------------------------------- > Please visit the OpenSource QM Taskforce: > http://wiki.metux.de/public/OpenSource_QM_Taskforce > Patches / Fixes for a lot dozens of packages in dozens of versions: > http://patches.metux.de/ > --------------------------------------------------------------------- > > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2008-06-05 11:21 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <483D8DBE.4090005@cableone.net> [not found] ` <200805282337.11349.yann.morin.1998@anciens.enib.fr> 2008-06-01 15:12 ` [9fans] crosstool fails on gentoo Enrico Weigelt 2008-06-02 19:25 ` Uriel 2008-06-02 19:55 ` ron minnich 2008-06-02 19:57 ` erik quanstrom 2008-06-02 20:09 ` Eric Van Hensbergen 2008-06-02 20:37 ` Uriel 2008-06-02 20:45 ` erik quanstrom 2008-06-02 21:00 ` Uriel 2008-06-02 22:32 ` Roman Shaposhnik 2008-06-02 23:00 ` Iruata Souza 2008-06-02 23:21 ` ron minnich 2008-06-03 0:50 ` Iruata Souza 2008-06-03 0:54 ` erik quanstrom 2008-06-03 2:02 ` Nick LaForge 2008-06-05 11:11 ` Enrico Weigelt 2008-06-05 11:21 ` Bruce Ellis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).