On May 30, 6:06 pm, [EMAIL PROTECTED] (Russ Cox) wrote:
> If you want to violate a convention, Plan 9 won't stop you,
> but in doing so you give up compatibility with programs that
> depend on that convention (bind /net/tcp /proc; ps).
> Sure, you could replace ctl and clone and other special files
All should be back online, if there are any remaining issues please let me know.
I'm sorry for the inconveniences, but I have been unwell and have not
been able to give cat-v.org much attention for some time.
uriel
P.S.: By the way, the werc repository is back online and patches are
always welco
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 m
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!
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 m
On Mon, Jun 2, 2008 at 2:55 PM, ron minnich <[EMAIL PROTECTED]> 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 la
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
> 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 Applicati
> 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,
Here's an interesting thing I'm learning about the kind of
optimizations that might be in the EU of the newer machines. This
started out as a pretty simple 'measure the branch penalty' exercise.
Given this program:
int b(int i){
return i+1;
}
main(){
int i;
for(i = 0; i <
> Don't try this with 8a. 8a is too damn smart
no, it's simply following instructions.
> OK, let's modify b: a little as follows;
> b:
> #if JMP > 0
> jmp bb
> #if JMP > 1
> callb
> #if JMP > 2
> callb
> #if JMP > 3
> callb
> #endif
> #endif
> #endif
> #endif
> bb:
I'm lost. So the calls never get called--they
On Mon, 2008-06-02 at 14:55 -0700, ron minnich wrote:
> now I time the run 10 times (I can run longer but it seems good enough
> to establish behavior). I should get some rough idea of the cost of
> the branch.
I hate to say it: but these days you can't time anything in isolation.
The CPU is just
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 st
On Mon, Jun 2, 2008 at 3:13 PM, Brantley Coile <[EMAIL PROTECTED]> wrote:
>> OK, let's modify b: a little as follows;
>> b:
>> #if JMP > 0
>> jmp bb
>> #if JMP > 1
>> callb
>> #if JMP > 2
>> callb
>> #if JMP > 3
>> callb
>> #en
On Mon, Jun 2, 2008 at 3:04 PM, Charles Forsyth <[EMAIL PROTECTED]> wrote:
>> Don't try this with 8a. 8a is too damn smart
>
> no, it's simply following instructions.
>
>
i meant that as praise for 8a if that came across wrong.
ron
> not at all: i meant that as a description of 8a's algorithm to eliminate
> branches
to be more accurate, it's not 8a at all, because 8a is stupid, but 8l does the
work.
i missed that point the first time until i re-read the messages.
On Mon, Jun 2, 2008 at 7:32 PM, Roman Shaposhnik <[EMAIL PROTECTED]> 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
>>> Don't try this with 8a. 8a is too damn smart
>>
>> no, it's simply following instructions.
>>
>>
>
> i meant that as praise for 8a if that came across wrong.
not at all: i meant that as a description of 8a's algorithm to eliminate
branches
On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <[EMAIL PROTECTED]> 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 poi
On Mon, Jun 2, 2008 at 3:50 PM, Charles Forsyth <[EMAIL PROTECTED]> wrote:
Don't try this with 8a. 8a is too damn smart
>>>
>>> no, it's simply following instructions.
>>>
>>>
>>
>> i meant that as praise for 8a if that came across wrong.
>
> not at all: i meant that as a description of 8a's a
On Mon, Jun 2, 2008 at 8:21 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <[EMAIL PROTECTED]> 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
> 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
> 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
24 matches
Mail list logo
