apache php mysql blog gentoo sicurezza

==============================================================================
TOPIC: reiserfs mount time
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/2663f1aa7932312f
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 8 2006 11:31 pm
From: Lee Revell

On Sun, 2006-01-08 at 23:24 +0100, Jan Engelhardt wrote:
> Hi,
>
>
> brought to attentino on an irc channel, reiser seems to have the largest
> mount times for big partitions. I see this behavior on at least two
> machines (160G, 250G) and one specially-crafted virtual machine
> (a 1.9TB disk / 1.9TB partition – took somewhere over 120 seconds).
> Here’s a dig http://linuxgazette.net/122/misc/piszcz/group001/image002.png
> from http://linuxgazette.net/122/TWDT.html#piszcz
> So, any hint from the reiserfs developers how come reiserfs takes so long?
> Standard mkreiserfs options (none extra passed).
>

reiser3 or reiser4?

Lee
kernel perche usiamo linux lo dice linus
==============================================================================
TOPIC: improve .text size on gcc 4.0 and newer compilers
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/9b120f647546b4d9
==============================================================================
Date: Thurs, Jan 5 2006 2:16 pm
From: Linus Torvalds

On Thu, 5 Jan 2006, Matt Mackall wrote:
>
> I think it’s a mistake to interleave this data into the C source. It’s
> expensive and tedious to change relative to its volatility.

I don’t believe it is actually all _that_ volatile. Yes, it would be a
huge issue _initially_, but the incremental effects shouldn’t be that big,
or there is something wrong with the approach.

> What I was proposing was something like, say, arch/i386/popularity.lst,
> which would simply contain a list of the most popular n% of functions
> sorted by popularity. As text, of course.

I suspect that would certainlty work for pure function-based popularity,
and yes, it has the advantage of being simple (especially for something
that ends up being almost totally separated from the compiler: if we’re
using this purely to modify link scripts etc with special tools).

But what about the unlikely/likely conditional hints that we currently do
by hand? How are you going to sanely maintain a list of those without
doing that in source code?

Linus

== 1 of 2 ==
Date: Thurs, Jan 5 2006 8:18 pm
From: Linus Torvalds

On Thu, 5 Jan 2006, Martin Bligh wrote:
>
> Hmm. if you’re just going to do it as binary on/off …is it not pretty
> trivial to do a crude test implementation by booting the kernel, turning
> on profiling, running a bunch of different tests, then marking anything
> that never appears at all in profiling as rare?

Yes, I think “crude” is exactly where we want to start. It’s much easier
to then make it smarter later.

> Not saying it’s a good long-term approach, but would it not give us enough
> data to know whether the whole approach was worthwhile?

Yes. And it’s entirely possible that “crude” is perfectly fine even in the
long run. I suspect this is very much a “5% of the work gets us 80% of the
benefit”, with a _very_ long tail with tons of more work to get very minor
incremental savings..

> OTOH, do we have that much to gain anyway in kernel space? all we’re doing is
> packing stuff down into the same cacheline or not, isn’t it?
> As we have all pages pinned in memory, does it matter for any reason
> beyond that?

The cache effects are likely the biggest ones, and no, I don’t know how
much denser it will be in the cache. Especially with a 64-byte one..
(although 128 bytes is fairly common too).

There are some situations where we have TLB issues, but those are likely
cases where we don’t care about placement performance anyway (ie they’d
be in situations where you use the page-alloc-debug stuff, which is very
expensive for _other_ reasons

Linus
-

== 2 of 2 ==
Date: Thurs, Jan 5 2006 8:23 pm
From: Linus Torvalds

On Thu, 5 Jan 2006, Linus Torvalds wrote:
>
> The cache effects are likely the biggest ones, and no, I don’t know how
> much denser it will be in the cache.

Oh, but validatign things like “likely()” and “unlikely()” branch hints
might be a noticeably bigger issue.

In user space, placement on the macro level is probably a bigger deal, but
in the kernel we probably care mostly about just single cachelines and
about branch prediction/placement.

Linus

From: Matt Mackall

On Thu, Jan 05, 2006 at 02:08:06PM -0800, Linus Torvalds wrote:
>
> On Thu, 5 Jan 2006, Matt Mackall wrote:
> >
> > I think it’s a mistake to interleave this data into the C source. It’s
> > expensive and tedious to change relative to its volatility.
>
> I don’t believe it is actually all _that_ volatile. Yes, it would be a
> huge issue _initially_, but the incremental effects shouldn’t be that big,
> or there is something wrong with the approach.

No, perhaps not. But it would be nice in theory for people to be able
to do things like profile their production system and relink. And
having to touch hundreds of files to do it would be painful.

> > What I was proposing was something like, say, arch/i386/popularity.lst,
> > which would simply contain a list of the most popular n% of functions
> > sorted by popularity. As text, of course.
>

Dunno. Those bits are all anonymous so marking them in situ is about
the only way to go. But we can do better for whole functions.

Date: Thurs, Jan 5 2006 11:19 pm
From: Matt Mackall

+0100, Ingo Molnar wrote:
>
> * Matt Mackall mpm@selenic.com> wrote:
>
> > > I don’t believe it is actually all _that_ volatile. Yes, it would be a
> > > huge issue _initially_, but the incremental effects shouldn’t be that big,
> > > or there is something wrong with the approach.
> >

Yeah, we’ve been talking about –gc-sections for years. It’d be nice
if we could work the build system in that direction with this
profiling concept.

(I suspect something silly happened in your test like dropping the
fixup table, btw.)

> i think all that is needed to reorder the functions is a build-time

I’m still not sure about in-source annotations for popularity. My
suspicion is that it’s just too workload-dependent, and a given
author’s workload will likely be biased towards their code.

–
Mathematics is the supreme nostalgia of our time.

Date: Thurs, Jan 5 2006 11:27 pm
From: Jesse Barnes

On Thursday, January 5, 2006 3:11 pm, Matt Mackall wrote:
> I’m still not sure about in-source annotations for popularity. My
> suspicion is that it’s just too workload-dependent, and a given
> author’s workload will likely be biased towards their code.

To some extent that’s true, but like Linus implied with his “5% work gets
us 80% there” I think there are a ton of obvious cases, e.g. kmalloc,
alloc_pages, interrupt handling, etc. that could be marked right away
and put into a frequently used section.

Jesse
Date: Thurs, Jan 5 2006 11:34 pm
From: Ingo Molnar
* Linus Torvalds torvalds@osdl.org> wrote:

> On Thu, 5 Jan 2006, Linus Torvalds wrote:
> >
> > The cache effects are likely the biggest ones, and no, I don’t know how
> > much denser it will be in the cache. Especially with a 64-byte one..
> > (although 128 bytes is fairly common too).
>
> Oh, but validatign things like “likely()” and “unlikely()” branch
> hints might be a noticeably bigger issue.

i frequently validate branches in performance-critical kernel code like
the scheduler (and the mutex code , via instruction-granularity
profiling, driven by a high-frequency (10-100 KHz) NMI interrupt. A bad
branch layout shows up pretty clearly in annotated assembly listings:

c037313c:     1715 :
c037313c:     1715 55                   push   %ebp
c037313d:      264 b8 00 f0 ff ff       mov    $0xfffff000,%eax
c0373142:      150 89 e5                mov    %esp,%ebp
c0373144:        0 57                   push   %edi
c0373145:      852 56                   push   %esi
c0373146:      215 53                   push   %ebx
c0373147:        0 83 ec 30             sub    $0×30,%esp
c037314a:      184 21 e0                and    %esp,%eax
c037314c:      120 8b 10                mov    (%eax),%edx
c037314e:        0 83 ba 84 00 00 00 00 cmpl   $0×0,0×84(%edx)
c0373155:       83 75 2b                jne    c0373182
c0373157:      104 8b 48 14             mov    0×14(%eax),%ecx

the second column is the number of profiler hits. As you can see, the
branch at c0373160 is always taken, and there’s a hole of 32 bytes in
the instruction stream. It is relatively easy to identify the
likely/unlikely candidates for various workloads. (It would probably be
even better to have a visual tool that also associates the source code
with the data.)

i’ve seen alot of such profiles on alot of different workloads, and my
guesstimate would be that with ‘perfect’ likely/unlikely hints, and with
‘perfect’ function ordering, we could roughly halve (!) the current
icache footprint of the kernel on complex workloads too.

Especially with 64 or 128 byte L1 cachelines our codepaths are really
fragmented and we can easily have 3-4 times of the optimal icache
footprint, for a given syscall. We very often have cruft in the hotpath,
and we often have functions that belong together ripped apart by things
like e.g. __sched annotators. I havent seen many cases of wrongly judged
likely/unlikely hints, what happens typically is that there’s no
annotation and the default compiler guess is wrong.

the dcache footprint of the kernel is much better, mostly because it’s
so easy to control it in C. The icache footprint is alot more elusive.
(and also alot more critical to execution speed on nontrivial workloads)

so i think there are two major focus areas to improve our icache
footprint:

- reduce code size
- reduce fragmentation of the codepath

fortunately both are hard and technically challenging projects, and both
will improve the icache footprint – and they will also bring other
benefits. [ We usually have much more problems with the easy and boring
stuff ]

icache fragmentation reduction is also hard because it has to deal with
fundamentally conflicting constraints: one workload’s ideal ordering is
different from another workload’s ideal ordering, and such workloads can
be superimposed on a system.

I think the only sane solution [that would be endorsed by distributions]
is to allow users to reorder function sections runtime (per boot). That
is alot faster and more robust (from a production POV) than a full
recompilation of the kernel. Recompilation is always risky, it needs too
much context, and has too many tool dependencies – and is thus currently
untestable. And we dont really need a recompilation of the kernel
technically – we need a relinking. Relinking is much safer from a
testability POV: reordering of the functions doesnt change their
internal instruction sequence or their interactions.

and we could use mcount() to gather function-cohesion data runtime. The
mcount() call could be patched out from the image runtime, when no data
gathering is happening. Given that the average function size is ~100
bytes, and an mcount call costs 5 bytes, the overhead would be +5% of
size and an extra 5-byte NOP per function. That’s not good, but it is
still at least an order of magnitude smaller than the possible gain in
icache footprint. (Also, people could run mcount()-less kernels as well,
once the data has been gathered, and the relink was done.)

one problem are modules though – they could only be reordered within
themselves. On an average system which has ~100 modules loaded, the
average icache fragmentation is +100*128/2 == 6.4K [with 128 byte L1
cachelines], which can be significant (depending on the workload). OTOH,
modules do have strong internal cohesion – they contain functions that
belong together conceptually. So by reordering functions within modules
we’ll likely be able to realize most of the icache savings possible. The
only exception would be workloads that utilize many modules at a high
frequency. Such workloads will likely trash the icache anyway.

Ingo

Date: Thurs, Jan 5 2006 10:55 pm
From: Martin Bligh

>>But what about the unlikely/likely conditional hints that we currently do
>>by hand? How are you going to sanely maintain a list of those without
>>doing that in source code?
>
>
> Dunno. Those bits are all anonymous so marking them in situ is about
> the only way to go. But we can do better for whole functions.

Would also make it easier to rank it as a percentage, or group by
locality of reference to other functions, rather than just a binary
split of “rare” vs “not-rare”.

Of course it’s all very dependant on workload, which drivers you’re
using too, etc, etc. So a profile that’s separate also makes it much
easier to tweak for one machine than the source base in general, which
theoretically represents everyone (and thus has little info ).

Which also makes me think it’s easier to mark hot functions than cold
ones, in a more general maintainance sense.

Date: Thurs, Jan 5 2006 10:59 pm
From: Ingo Molnar
* Matt Mackall mpm@selenic.com> wrote:

> > I don’t believe it is actually all _that_ volatile. Yes, it would be a
> > huge issue _initially_, but the incremental effects shouldn’t be that big,
> > or there is something wrong with the approach.
>
> No, perhaps not. But it would be nice in theory for people to be able
> to do things like profile their production system and relink. And
> having to touch hundreds of files to do it would be painful.

we can (almost) do that: via -ffunction-sections. It does seem to work
on both the gcc and the ld side. [i tried to use this for --gc-sections
to save more space, but that ld option seems unstable, i couldnt link a
bootable image. -ffunction-sections itself seems to work fine in gcc4.]

i think all that is needed to reorder the functions is a build-time
generated ld script, which is generated off the ‘popularity list’.

so i think the two concepts could nicely co-exist: in-source annotations
help us maintain the popularity list, -ffunction-sections allows us to
reorder at link time. In fact such a kernel could be shipped in
‘unlinked’ state, and could be relinked based on per-system profiling
data. As long as we have KALLSYMS, it’s not even a big debuggability
issue.

the branch-likelyhood thing is a separate issue from function-cohesion,
but could be handled by the same concept: if there was a
–ffunction-unlikely-sections option in gcc (there’s none currently,
AFAICS), then those could be reordered in a smart way too. (We wouldnt
get the 8-byte relative jumps back though, gcc would always have to
assume that the jump is far away.)

Ingo

Date: Thurs, Jan 5 2006 11:11 pm
From: Matt Mackall

On Thu, Jan 05, 2006 at 02:49:21PM -0800, Martin Bligh wrote:
>
> >>>What I was proposing was something like, say, arch/i386/popularity.lst,
> >>>which would simply contain a list of the most popular n% of functions
> >>>sorted by popularity. As text, of course.

> >
> >Dunno. Those bits are all anonymous so marking them in situ is about
> >the only way to go. But we can do better for whole functions.
>
> Would also make it easier to rank it as a percentage, or group by
> locality of reference to other functions, rather than just a binary
> split of “rare” vs “not-rare”.
>
> Of course it’s all very dependant on workload, which drivers you’re
> using too, etc, etc. So a profile that’s separate also makes it much
> easier to tweak for one machine than the source base in general, which
> theoretically represents everyone (and thus has little info ).
>
> Which also makes me think it’s easier to mark hot functions than cold
> ones, in a more general maintainance sense.

Yes, I think it definitely makes sense to think in terms of hot
functions. We surely have a nice long tail on the popularity
distribution and only the first 5% or so are actually worth sorting
and packing.

–
Mathematics is the supreme nostalgia of our time.
Date: Fri, Jan 6 2006 12:05 am
From: Linus Torvalds

On Fri, 6 Jan 2006, Ingo Molnar wrote:
>
> i frequently validate branches in performance-critical kernel code like
> the scheduler (and the mutex code , via instruction-granularity
> profiling, driven by a high-frequency (10-100 KHz) NMI interrupt. A bad
> branch layout shows up pretty clearly in annotated assembly listings:

Yes, but we only do this for routines that we look at anyway.

Also, the profiles can be misleading at times: you often get instructions
with zero hits, because they always schedule together with another
instruction. So parsing things and then matching them up (correctly) with
the source code in order to annotate them is probably pretty nontrivial.

But starting with the code-paths that get literally zero profile events is
definitely the way to go.

> Especially with 64 or 128 byte L1 cachelines our codepaths are really
> fragmented and we can easily have 3-4 times of the optimal icache
> footprint, for a given syscall. We very often have cruft in the hotpath,
> and we often have functions that belong together ripped apart by things
> like e.g. __sched annotators. I havent seen many cases of wrongly judged
> likely/unlikely hints, what happens typically is that there’s no
> annotation and the default compiler guess is wrong.

We don’t have likely()/unlikely() that often, and at least in my case it’s
partly because the syntax is a pain (it would probably have been better to
include the “if ()” part in the syntax – the millions of parenthesis just
drive me wild).

So yeah, we tend to put likely/unlikely only on really obvious stuff, and
only on functions where we think about it. So we probably don’t get it
wrong that often.

> the dcache footprint of the kernel is much better, mostly because it’s
> so easy to control it in C. The icache footprint is alot more elusive.
> (and also alot more critical to execution speed on nontrivial workloads)
>
> so i think there are two major focus areas to improve our icache
> footprint:
>
> – reduce code size
> – reduce fragmentation of the codepath
>
> fortunately both are hard and technically challenging projects

That’s an interesting use of “fortunately”. I tend to prefer the form
where it means “fortunately, we can trivially fix this with a two-line
solution that is obviously correct”

Linus

Date: Fri, Jan 6 2006 12:08 am
From: Martin Bligh

– the sound of my eyeballs popping out and splatting against
the opposite wall.

So … recompilation is not testable, but boot time reordering of the
code somehow is? Yes, I understand the distro toolchain issues, but
it’s still a scary solution …

Personally, I’d think the sane thing is not to try to optimise by
workload, but get 80% of the benefit by just reordering on a more
generalized workload. Doing boot-time reordering for this on non-custom
kernels just seems terrifying .. it’s not that huge a benefit, surely?

> one problem are modules though – they could only be reordered within
> themselves. On an average system which has ~100 modules loaded, the
> average icache fragmentation is +100*128/2 == 6.4K [with 128 byte L1
> cachelines], which can be significant (depending on the workload). OTOH,
> modules do have strong internal cohesion – they contain functions that
> belong together conceptually. So by reordering functions within modules
> we’ll likely be able to realize most of the icache savings possible. The
> only exception would be workloads that utilize many modules at a high
> frequency. Such workloads will likely trash the icache anyway.

I was thinking about that with modules earlier, and whether modular
kernels would actually be faster because of that than a statically
compiled one. But don’t you get similar effects from the .o groupings by
file we get? or does the linker not preserve those groupings?

Date: Fri, Jan 6 2006 12:16 am
From: Ingo Molnar
* Linus Torvalds torvalds@osdl.org> wrote:

> Also, the profiles can be misleading at times: you often get
> instructions with zero hits, because they always schedule together
> with another instruction. So parsing things and then matching them up
> (correctly) with the source code in order to annotate them is probably
> pretty nontrivial.

yeah, but schedules-together isnt a big problem in terms of branch
predictions: unused branches really stick out with their zero counters.
Especially if there enough profiling hits, it’s usually a quick glance
to figure out the hotpath:

c0119e1f:   582904 :
c0119e1f:   582904 57                   push   %edi
c0119e20:   312621 56                   push   %esi
c0119e21:       29 53                   push   %ebx
c0119e22:        0 50                   push   %eax
c0119e23:   285471 50                   push   %eax
c0119e24:       15 8b 74 24 18          mov    0×18(%esp),%esi
c0119e28:       21 8b 7c 24 1c          mov    0×1c(%esp),%edi
c0119e2c:   325688 89 f0                mov    %esi,%eax
c0119e2e:       26 89 fa                mov    %edi,%edx
c0119e30:        0 e8 86 fe ff ff       call   c0119cbb
c0119e35:   377758 83 f8 01             cmp    $0×1,%eax
c0119e38:   384539 75 3f                jne    c0119e79

c0119e3a: 0 85 f6 test %esi,%esi
c0119e3c: 0 74 19 je c0119e57

c0119e3e:        0 89 e0                mov    %esp,%eax
c0119e40:        0 e8 4b c6 fe ff       call   c0106490
c0119e45:        0 b9 08 00 00 00       mov    $0×8,%ecx
c0119e4a:        0 89 f0                mov    %esi,%eax
c0119e4c:        0 89 e2                mov    %esp,%edx
c0119e4e:        0 e8 3e f2 0b 00       call   c01d9091
c0119e53:        0 85 c0                test   %eax,%eax
c0119e55:        0 75 19                jne    c0119e70

c0119e57: 0 85 ff test %edi,%edi
c0119e59: 0 74 1c je c0119e77

c0119e5b:        0 b9 08 00 00 00       mov    $0×8,%ecx
c0119e60:        0 ba 88 3e 53 c0       mov    $0xc0533e88,%edx
c0119e65:        0 89 f8                mov    %edi,%eax
c0119e67:        0 e8 25 f2 0b 00       call   c01d9091
c0119e6c:        0 85 c0                test   %eax,%eax
c0119e6e:        0 74 07                je     c0119e77

c0119e70: 0 b8 f2 ff ff ff mov $0xfffffff2,%eax
c0119e75: 0 eb 02 jmp c0119e79

c0119e77:        0 31 c0                xor    %eax,%eax
c0119e79:      308 5e                   pop    %esi
c0119e7a:   749654 5f                   pop    %edi
c0119e7b:   415831 5b                   pop    %ebx
c0119e7c:      744 5e                   pop    %esi
c0119e7d:   361201 5f                   pop    %edi
c0119e7e:   373195 c3                   ret

here at the top you can see that the CPU is a nice 3-issue design and
that in this workload the branch at c0119e38 is untaken and returns from
the function afterwards. A branch instruction followed by more than 2
zero profile-count instructions (that are not jumps) is a good sign of
an untaken branch. This would be a pretty strong heuristics as well i
think. We could really make the requirement be ‘zero profiling hits’,
and the branch instruction would have to get ‘enough’ hits, to conclude
that the branch is a candidate for likely/unlikely.

Ingo

==============================================================================
TOPIC: improve .text size on gcc 4.0 and newer compilers
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/9b120f647546b4d9
==============================================================================

== 1 of 3 ==
Date: Fri, Jan 6 2006 12:32 am
From: Linus Torvalds

On Fri, 6 Jan 2006, Ingo Molnar wrote:
>
> Especially if there enough profiling hits, it’s usually a quick glance
> to figure out the hotpath:

Ehh. What’s a “quick glance” to a human can be quite hard to automate.
That’s my point.

If we do the “human quick glances”, we won’t be seeing much come out of
this. That’s what we’ve already been doing, for several years.

I thought the discussion was about trying to automate this..

Linus

From: Ingo Molnar
* Martin Bligh mbligh@mbligh.org> wrote:

> >I think the only sane solution [that would be endorsed by distributions]
‘testable’ in the sense that the stability and reliability of the system
is alot less dependent on function ordering, than it is dependent on
compilation. It’s not ‘testable’ in the sense of being able to cycle
through all the 60000-factorial function combinations – but that’s not
really a problem, as long as the risk of the worst-case effect of
function reordering can be judged and covered. The kernel stopped being
‘fully testable’ sometime around version 0.2 already

> Personally, I’d think the sane thing is not to try to optimise by
> workload, but get 80% of the benefit by just reordering on a more
> generalized workload. Doing boot-time reordering for this on
> non-custom kernels just seems terrifying .. it’s not that huge a
> benefit, surely?

i’m not so sure, see the ballpark figures below.

> >one problem are modules though – they could only be reordered within
> >themselves. On an average system which has ~100 modules
>
> I was thinking about that with modules earlier, and whether modular
> kernels would actually be faster because of that than a statically
> compiled one. But don’t you get similar effects from the .o groupings
> by file we get? or does the linker not preserve those groupings?

they are mostly preserved (except for things like __sched which move
functions out of .o), but look at a call-chain like this:

| new stack-footprint maximum: khelper/1125, 2412 bytes (out of 8140 bytes).
————|
{   40} [] debug_stackoverflow+0xb6/0xc4
{   60} [] __mcount+0×47/0xe0
{   20} [] mcount+0×14/0×18
{ 116} [] __down_mutex+0xe/0×87b
{   28} [] _spin_lock+0×24/0×49
{   36} [] kmem_cache_alloc+0×40/0xe9
{   16} [] mempool_alloc_slab+0×1d/0×1f
{

[readers beware, quick & dirty and possibly wrong guesstimations: ]

these 30 functions involve roughly 10-15 .o files, so we’ve got 2-3
functions per .o file only. And that’s typical for VFS, IO, networking
and lots of other syscall types. So if the full kernel image is 3MB, and
we’ve got 30 functions totalling to 3000 bytes, they are spread out in
10-15 groups right now – creating 10-15 split icache lines. (in reality
we have in excess of 20 split icache-lines, due to weak cohesion even
within .o files) With 64-byte lines that’s 320-480 bytes ‘lost’ due to
fragmentation alone, with 128-byte lines it’s 640-960 bytes – which is
10%-21% in the 64-byte case, and 21%-42% in the 128-byte case. I.e. the
icache bloat just due to the placement is quite significant. Adding
o-level fragmentation plus inter-function inactive code to the mix can
easily baloon this even higher. Plus the current method of doing
unlikely() means the unlikely instructions are near the end of the
function – so they still ’spread apart’ the footprint and thus have a
nontrivial icache cost.

[ now the above one is a random example out of my logs that is also a
really bad example: in reality would win little from better icache
footprint: an execve() takes 100,000-200,000 cycles even when
everything comes from the pagecache, and most of those cycles are
spent in very tight codepaths. ]

Ingo

== 1 of 5 ==
Date: Fri, Jan 6 2006 12:58 am
From: Martin Bligh
> these 30 functions involve roughly 10-15 .o files, so we’ve got 2-3
> functions per .o file only. And that’s typical for VFS, IO, networking
> and lots of other syscall types. So if the full kernel image is 3MB, and
> we’ve got 30 functions totalling to 3000 bytes, they are spread out in
> 10-15 groups right now – creating 10-15 split icache lines. (in reality
> we have in excess of 20 split icache-lines, due to weak cohesion even
> within .o files) With 64-byte lines that’s 320-480 bytes ‘lost’ due to
> fragmentation alone, with 128-byte lines it’s 640-960 bytes – which is
> 10%-21% in the 64-byte case, and 21%-42% in the 128-byte case. I.e. the
> icache bloat just due to the placement is quite significant. Adding
> .o-level fragmentation plus inter-function inactive code to the mix can
> easily baloon this even higher. Plus the current method of doing
> unlikely() means the unlikely instructions are near the end of the
> function – so they still ’spread apart’ the footprint and thus have a
> nontrivial icache cost.

mmm. will take me a little time to digest that.

But we were just discussing here … wouldn’t it be worth moving
“unlikely” sections of code completely out of line? If they were calls
to separate functions, all this optimisation stuff could just work at a
function level, and would be pretty trivial to do?

ie instead of:

if (unlikely(conditon)) {
do;
some;
stuff;
BUG();
error();
oh_dear();
}
we’d have
if (unlikely(conditon)) {
call_oh_shit();
}

__rarely_called void call_oh_shit()
{
do;
some;
stuff;
BUG();
error();
oh_dear();
}

depends how long they are, I suppose. Moving that out of line would seem
to make more difference to icache footprint to me than just cacheline
packing functions.

M.
-

== 2 of 5 ==
Date: Fri, Jan 6 2006 12:58 am
From: Ingo Molnar
* Linus Torvalds torvalds@osdl.org> wrote:

> > Especially if there enough profiling hits, it’s usually a quick glance
> > to figure out the hotpath:
>
> Ehh. What’s a “quick glance” to a human can be quite hard to automate.
> That’s my point.
>
> If we do the “human quick glances”, we won’t be seeing much come out
> of this. That’s what we’ve already been doing, for several years.
>
> I thought the discussion was about trying to automate this..

i think it could be automated reasonably well. An 80% effective “which
condition is judged incorrectly” decision could be made based on:

branch instruction with more than 10% of the average per-instruction
cycle count, followed by an at least 4-instruction sequence of
non-branch (and non-jump) instructions that have exactly zero
profiling hits. (‘few hits’ we are not interested in – those are not
likely/unlikely candidates)

another part is to feed this back into .c, automatically. I’ve done
DEBUG_INFO, gdb vmlinux and list *0×12341234 based scripts before, but
they are not always reliable. They could probably do something like: “if
the resulting source code contains a clear ‘if (‘ sequence, modify it to
‘if __unlikely (‘, or something like that.

i’d expect such a method to catch ~50-60% of the interesting cases, not
more. (the rest would be stuff the heuristics doesnt catch, and it would
also be stuff like ‘while’ or ‘break’ or ‘goto’, which are much harder
to rewrite automatically.

but it does feel quite a bit fragile.

Ingo
From: Ingo Molnar
* Mitchell Blank Jr mitch@sfgoth.com> wrote:

> I actually did that in a project once (an “unlikely

a better syntax would be:

if __unlikely (cond) {
…
}

since it’s the extra parantheses that are causing the visual complexity.

Ingo
From: Mitchell Blank Jr

Ingo Molnar wrote:
> a better syntax would be:
>
> if __unlikely (cond) {
> …
> }

Well you could just throw an extra set of parenthesis around the expansion
of the current “unlikely()” macro and get this effect now.

-Mitch

== 5 of 5 ==
Date: Fri, Jan 6 2006 1:49 am
From: Mitchell Blank Jr

Martin Bligh wrote:
> But we were just discussing here … wouldn’t it be worth moving
> “unlikely” sections of code completely out of line? If they were calls
> to separate functions, all this optimisation stuff could just work at a
> function level, and would be pretty trivial to do?

..assuming that they don’t need to access many local variables. And don’t
have any “goto” statements… and… etc, etc.

> we’d have
>
> if (unlikely(conditon)) {
> call_oh_shit();
> }
>
> __rarely_called void call_oh_shit()
> {
> do;
> some;
> stuff;
> BUG();
> error();
> oh_dear();
> }

As I described in my other mail on this thread, the _ideal_ solution would
be to tell the compiler that BUG() is a __rarely_called function (well, it’s
a macro now but it could be made into an inline function) and let the
compiler figure the rest out without further annotation

> Moving that out of line would seem
> to make more difference to icache footprint to me than just cacheline
> packing functions.

Assuming “-funit-at-a-time” (which all archs will probably be using soon)
you’d probably get exactly the same opcodes either way.

-Mitch

==============================================================================
TOPIC: ALSA userspace API complexity
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/659e65d9316accdd
==============================================================================

== 1 of 5 ==
Date: Fri, Jan 6 2006 12:58 am
From: Marcin Dalecki
On 2006-01-06, at 01:29, Martin Drab wrote:

> Because as much as we all don’t like it, it is
> a realistic fact. There’s just NO WAY you can responsibly say about
> any
> piece software, that it is completely error free.

You would be for example surprised to see how complex the software
controlling the breaks
of a reasonable modern car turns out to be… This is just a
technical example running contrary
to your “wisdom”. In numerical computations you can find reasonable
amounts of software
which is precisely just that – bug free. There are mathematical
proofs running for hundreds of pages,
which are just valid. Do you think this kind of guys doesn’t ever sit
down and write
some piece of software to help out well for example in determining
some aerodynamics of a plane?
Are you assuming this kind of applications is trivial and by virtue
of a natural law bug ridden?

And by the way: the zero program which has nothing to do is bug free.
QED.

Date: Fri, Jan 6 2006 1:25 am
From: Zan Lynx

On Fri, 2006-01-06 at 01:14 +0100, Marcin Dalecki wrote:
> On 2006-01-06, at 00:40, Lee Revell wrote:
> > Hey, interesting, this is exactly what dmix does in userspace. And we
Funny that you should mention bug-free code and ABS.

Just a few months ago, Subaru updated the ABS controller code for the
WRX. They sent me the notice in the mail. It was an optional upgrade,
the change was only needed to fix some very odd corner cases.

The point being that even critical micro-controller software has bugs.

Even software that has been mathematically proofed can have bugs. Knuth
uses it as a joke: “Beware bugs in the above code. I have
proven it correct; I have not actually tried it.”

It’s so funny because it’s so true.
–
Zan Lynx zlynx@acm.org>

== 3 of 5 ==
Date: Fri, Jan 6 2006 1:31 am
From: Olivier Galibert

On Fri, Jan 06, 2006 at 01:22:48AM +0100, Joern Nettingsmeier wrote:
and rather offensive.

You know, having the problem of device blocking between the oss api
kernel support (emulation is not a very good term in that context) and
the alsa api kernel support being meet by -EWONTFIX and “Don’t use
OSS, use Alsa-lib, it’s infinitely better” is somewhat offensive too.
You want me to file a bug report on that to see how far it’s going to
go?
> then somebody started an api discussion, where *oss* was represented
> quite fairly. it does have its nice sides. but to me it looks like most
> of the people bashing *alsa* for its complexity have not understood the
> problems it tries to (and does) solve.

The “the documentation is perfect, you just not have read it”
fanboyism after having needed 2 or 3 days using that same
documentation to write a simple dynamic sound streaming in an
application I’m doing grates a little. Also, I notice that all my
comments about the numerous problms as seen in the windows world that
come with having a kernel api defined as a shared library have gone
beautifully ignored.
> shuffle 16 tracks of 24bit 48k audio in and out of the machine at a
> latency where a professional drummer will not complain, with routing
> options adequate for professional work, and then let’s see how simple
> your API is.

I’ve done 64-channel microphone array capture, source tracking,
beamforming, speaker id and feeding an ASR over a network of computers
with a rather low latency. I wrote or participated in the complete
chain, from programming the capture dsp in assembly and debugging it
with a ’scope, writing the linux driver to get the data on the pci, or
writing the data transmission infrastructure. And the API is still
simple enough that it is becoming a de facto standard for smart space
applications and the comments are of the order of “there still are
some bugs (indeed there is, no doubts about that), but it allowed us
to having things working rather easily and fast”.

Is that enough audio-unchallenged for you? Oh, it does video too.
> in audioland, you have all kinds of funky shit going on in the hardware,
> and you can’t say, no we don’t support that, to inelegant, because then
> your stuff just can’t compete.

That’s why you want a clean core and an extension mechanism, and add
the extensions in the core once they’re general enough. See OpenGL.
> hardware peculiarities cannot be abstracted away without sacrificing
> efficiency, and this makes for a complicated api.

No, it doesn’t. Again, see OpenGL. Audio hardware variability is
laughable compared to video hardware variability nowadays.

But you need to designed your API starting from what people want to
do, not from what the hardware does in detail.

OG.
From: Hannu Savolainen

On Fri, 6 Jan 2006, Marcin Dalecki wrote:

>
>
> No I do not. How do you dare to assume I do?
> I never ever did ask for any support on behalf of the ALSA bunch…
> We are just discussing the merits of one sound system design
> over another one (without design).
Which is really a good subject to discuss about (LKML may not be the right
place for this). ALSA has been in the official kernel for two years now so
might this be a good time to look back?

There are two very opposite approaches to do a sound subsystem. The ALSA
way is to expose every single detail of the hardware to the applications
and to allow (or force) application developers to deal with them. The OSS
approach is to provide maximum device abstraction in the API level (by
isolating the apps from the hardware as much as practically possible).

Both ways have their good and bad sides. During past years the ALSA
advocates have been dictating that the ALSA approach is the only available
way to go (all resistance is futile). But after all what is the authority
who makes the final decision? Is it the ALSA team (who would like to think
in this way)? Or do the Linux/Unix users and audio application developers
have any word to say?

Btw, about the current OSS drivers in the kernel. They are really obsolete
because they are based on some 10 years old API version. For this reason
it’s necessary to remove them in the nearish future (maybe at the same
time when we release the OpenOSS version). Comparing ALSA against the
kernel OSS drivers is pointless because current OSS has very little
common with that code.

Best regards,

Hannu

== 1 of 6 ==
Date: Thurs, Jan 5 2006 11:41 pm
From: Lee Revell

On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> We have not received any single bug report that is caused
> by the concept of kernel mixing.
> Kernel mixing is not rocket science. All you need to do is picking a
> sample from the output buffers of each of the applications, sum them
> together (with some volume scaling) and feed the result to the
> physical
> device.

Hey, interesting, this is exactly what dmix does in userspace. And we
have not seen any bug reports caused by the concept of userspace mixing
(just implementation bugs like any piece of software).

Lee

From: Tomasz Kloczko

On Thu, 5 Jan 2006, Joern Nettingsmeier wrote:
[..]
> i look forward to hearing back from you, in, oh, 2015 or so?

Now we have 2006. Four years ALSA is in kernel tree.
2015 – 2006 = 9
4 kloczek@rudy.mif.pg.gda.pl*

== 3 of 6 ==
Date: Thurs, Jan 5 2006 11:50 pm
From: Olivier Galibert

On Thu, Jan 05, 2006 at 11:39:43PM +0100, Joern Nettingsmeier wrote:
> modem dialup users know better than to chime in to networking core
> discussions and complain they don’t need all that complexity. why do
> professional audio users always have to put up with people who only
> listen to mp3s whining about a complicate API?

Funnily enough, people who added SIGIO and epoll did not remove
select nor limited its capabilities.

The ALSA api has issues, whether you want to acknowledge them or not.
The OSS api has issues too, of course. But it is there to stay, and
it has advantages in some situations, like when simplicity or not
depending on a shared library matters. Ignoring it is stupid. Doing
your best to cripple it is stupid. The OSS api is an entrypoint in
the sound system as valid and important than others.

OG.

From: Hannu Savolainen

On Thu, 5 Jan 2006, Lee Revell wrote:

> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > – PCM with 3-bytes-packed 24bit formats
> > Applications have no reasons to use for this kind of stupid format so
> > OSS translates it to the usual 32 bit format on fly. In fact OSS API
> > does have support for this format.
>
> What about hardware that only understands this format?
There is no such hardware. Or is there?

Best regards,

Hannu
—–
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM

From: Marcin Dalecki
On 2006-01-05, at 23:39, Joern Nettingsmeier wrote:

> Tomasz Kloczko wrote:
>> of all soundcard vendors.

First and fore most users want simple things like for example playing

an mp3 file to just work.
Your concept that very many of them are interested in the high end
“features” of hardware you assume to be modern is wrong. Did you ever
notice that sound cards got just reduced to a simple AD/DA converter
combination? Modern hardware is frequently actually MUCH MUCH simpler
then old one used to be in this area.

> please have a look at, say, the rme hammerfall cards, compare them
> with ye olde sblive, then take a look at usb audio devices and for
> dessert, take a peek into current firewire hardware.

The existence of /dev/sound doesn’t prohibit the existence of
/dev/bells_and_wistles (without any chance to work with anything else
then the vendors specific software).
That was precisely the situation with my sam9700 card….

> then push up your sleeves, design a small and elegant little
> abstraction mechanism that is maximally effective in all
> circumstances and makes all hardware features usable, wrap it up
> nicely and submit it to linus.
>
> i look forward to hearing back from you, in, oh, 2015 or so?

Your assumption about “all circumstances” is misguided. There is no
requirement for one size fits all here.
Look most people drive cars and not space shuttles.
> jaroslav, takashi and the other alsa developers have been toiling
> with this for years, and i hate to see them having to take shit
> from people who don’t do anything more with their sound hardware
> than listen to mp3s in stereo and can’t imagine anything else.

If hearing just the mp3 would just simply work with the alsa drivers
without getting in to too much hassle
with AC97 sound cards, which usually don’t even include hardware
based volume controls nowadays, I’m pretty sure they wouldn’t have to
“take this shit”. And you should remember the bold announcements they
did make in first place.

> granted, there is always room for improvement. the alsa guys are
> very receptive towards constructive criticism, when it is backed
> with a little insight. many linux audio developers have criticised
> the API for the high initial barrier, and ALSA certainly does not
> score that high in the “making simple things simple” department.
> but it does make *complicated things possible*, and all those rants
> of “gimme back me oss” usually ignore this.
>
> modem dialup users know better than to chime in to networking core
> discussions and complain they don’t need all that complexity. why
> do professional audio users always have to put up with people who
> only listen to mp3s whining about a complicate API?
> i’ll always grant you far better taste and insight into kernel
> matters than i will ever have, but hey: the library is in
> userspace. it does not clutter the kernel. so rrreeelaax!

It clutters the application programming part very successfully.

BTW. Designing a sound API toward DMA, like ALSA does, is just plain
well beyond any hope…
-
To unsubscribe from this list: send the line “unsubscribe linux-kernel”
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 6 of 6 ==
Date: Fri, Jan 6 2006 12:03 am
From: Hannu Savolainen

On Thu, 5 Jan 2006, Lee Revell wrote:

> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > We have not received any single bug report that is caused
> > by the concept of kernel mixing.
> > Kernel mixing is not rocket science. All you need to do is picking a
> > sample from the output buffers of each of the applications, sum them
> > together (with some volume scaling) and feed the result to the
> > physical
> > device.
>
> Hey, interesting, this is exactly what dmix does in userspace. And we
> have not seen any bug reports caused by the concept of userspace mixing
> (just implementation bugs like any piece of software).
Having dmix working in user space doesn’t prove that kernel level mixing
is evil. This was the original topic.

Best regards,

Hannu
—–
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
-
== 1 of 3 ==
Date: Thurs, Jan 5 2006 9:06 pm
From: Edgar Toernig

Lee Revell wrote:
>
> If you’d like to help debug this:
>
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585
>
> There’s a workaround patch available. We still don’t know the exact
> nature of the bug.

Well, the problem I had was not exactly the same (I get loud noise, as
if the samples are byte-swapped) but

alsa-usbaudio-2.6.15-revert-008.patch

seems to fix that. Thanks.

But now (alsa-1.0.9 userspace):

alsaplayer -i text -d hw:0 …    –> ok
alsaplayer -i text -d hw:1 …    –> ok
alsaplayer -i text -d dmix:0 … –> ok
alsaplayer -i text -d dmix:1 … –> no error, no sound, just total
                                        silence. But the clock’s running.

with 2.6.13 all 4 are ok.

Ciao, ET.

PS: Someone reported on bugzilla that his usb-audio is not always detected.
Just for the record – happens here too, usually when cold-booting.

Date: Thurs, Jan 5 2006 9:10 pm
From: Lee Revell

On Thu, 2006-01-05 at 22:05 +0100, Edgar Toernig wrote:
> Lee Revell wrote:
> >

>
> But now (alsa-1.0.9 userspace):
>
> alsaplayer -i text -d hw:0 … –> ok

> with 2.6.13 all 4 are ok.
>
> Ciao, ET.
OK. This is getting a bit much for LKML, can you open a new bug and set
it related to #1585?

Lee

From: Jan Engelhardt
>> historical and political reasons, not technical ones. When
>> performance raises its ugly head and you end up having to listen to
>> engineers again you end up with DRI and that:
>>
>> Module Size Used by
>> nvidia 3464380 12
What nvidia version number is that? I remember it being over 5 megs in size. Oh
BTW, that’s one GOOD REASON for me to believe having certain parts in userspace
(e.g. X was mentioned) being a good thing – after all, you can’t swap kernel
memory. If nvidia continued like that, their kernel module would eventually
exceed the amount of RAM that is apparently installed.
Jan Engelhardt
== 1 of 12 ==
Date: Thurs, Jan 5 2006 8:13 pm
From: Tomasz Kloczko

[..]

Soft mixing is performed by writing to allocated shared memory block.
Try to use SELinux on dissalow use SHM only for mixing souds.
In case performing ALL (possible) mixing tricks you have SINGLE point of
entry from any application. Using SHM with r/w permission allow one
allicattions dump sound streams writed by other applications.
Moment .. are you want to say: there is no compact mixing abstraction
layer in ALSA because because ALSA is developed by believers ? (not
technicians/enginers ?)
Sorry .. be so kind and try to answer on my question using only stricte
*technical arguments*.

> (snip)
>> In case ALSA now questions are very basic:
>>
>> – all hardware mixers are very simillar with very izomorphic interface
>>    (read this as: this can be very easy abstracted) and we have only one
>>    other case with soft mixing when this hardwware must be emulated in
>>    software .. so all this details can be rolled to one leyer on kernel
>>    level.
>>    So: why all mixing details are not in kernel space ?
>
> The problem is not the interface but the implementation.

Hmm .. if “ALSA is developed by belivers” slowny now I undestand .. all
this :>
> – Split of channels to concurrent accesses
> – Handling of floating pointer samples
> – Post/pre-effects (like chorus/reverb)

Are you want say something like: architesture of OSS is so bad there is no
civilized way for extending this ? (except: chorus/reverb are now handled
by comercial OSS).
Correct me if I’m wrong: his not true.

> Forcing OSS API means to force to process the all things above in
> the kernel. I guess many people would disagree with it.

Completly disagee.
And another argument: comercial OSS have ALSA emulation and ALSA have OSS
emulation.
So .. there is no general architecture problems on implemting both varians
(in both variants sits only some implementation bugs).

This unhides one fact: *ALSA and OSS are mostly izomorphic* (look on
similarities ALSA and OSS device drivers architecture).

And if it is true there was/is no strong arguments for droping OSS and
replace this by ALSA. As I sayd ALSA is only on Linux. Using OSS allow
easier develpment soud support in user space applications for some group
of currently used unices. This is IMO strong argument .. much stronger
than existing or not group of belivers. For me now switching to ALSA have
only *political groud* .. nothing more. Interesting .. how long Linux can
survive without looking on some economic aspects ?

If you allow .. EOT

kloczek
–
———————————————————–
*Ludzie nie maja problemów, tylko sobie sami je stwarzaja*
———————————————————–
Tomasz Kloczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

== 2 of 12 ==
Date: Thurs, Jan 5 2006 8:19 pm
From: Marcin Dalecki
On 2006-01-05, at 21:05, Lee Revell wrote:

> On Thu, 2006-01-05 at 21:03 +0100, Marcin Dalecki wrote:
>> On 2006-01-05, at 19:33, Lee Revell wrote:
>>
>>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
>>>> Second – you still didn’t explain why this allows you to conclude
>>>> that sound mixing should in no way be done inside the kernel.
>>>
>>> It works perfectly right now in userspace.
>>
>> Yeah – for you maybe…
>>
>
> Please rephrase your comment in the form of a useful bug report.

Yes I will. But only after you stop spreading BS about how fine and
generally dandy the situation about sound support in Linux is thanks
to ALSA.
One reports bugs only if one expects that the situation will improve.
Glaring problems on average commodity hardware one expect the
developers to take
care of without any notice.

However since the beginning the situation with ALSA has always been a
lot of
advertisement how well it will work but the results where always less
then stellar
if one looked at them from the functional side.

Date: Thurs, Jan 5 2006 8:19 pm
From: Lee Revell

On Thu, 2006-01-05 at 14:29 -0500, Lee Revell wrote:
> > And btw, with 2.6.15 the usb-speakers only produce noise most of the

If you’d like to help debug this:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585

There’s a workaround patch available. We still don’t know the exact
nature of the bug.

Lee

== 4 of 12 ==
Date: Thurs, Jan 5 2006 8:25 pm
From: Edgar Toernig

Lee Revell wrote:
>
> Edgar Toernig wrote:
> > Lee Revell wrote:
> > >
> > > If it does not Just Work it’s a bug and we need to hear about it.
> >
> > So then: xawtv4 (dvb-app) works with hw:0 but not with 1.0.9’s dmix default.
> > It works with /dev/dsp1 (usb-speakers) but not with /dev/dsp0 (atiixp ac’97).
> > vdr’s softdevice (another dvb-app) works with dmix-default but not with hw:0.
>
> Come on, this is LKML, you should know that “it doesn’t work” is not a
> useful bug report.

xawtv4 with dmix is just silent and aborts when its queue of outstanding pcm
data is filled up.

Trying to use /dev/dsp0 starts fine for a fraction of a second but then
either stays silent or stutters until its audio-queue overflows again.

With vdr its similar: when using hw:0 it only stutters (and fills the log
with xrun errors). I had a short look once – it uses a very small buffer
(iirc about 4kb) and gets constant underruns which it tries to handle
via prepare-something but it’s unable to recover. With dmix it works fine,
probably because of the bigger mixing buffer.

> Sure, maybe badly written apps but there must be something wrong if so
> many developers have problems with Alsa. I’ve even resigned to grok
> the config files
Date: Thurs, Jan 5 2006 8:28 pm
From: Lee Revell

On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 21:05, Lee Revell wrote:
I’m not spreading BS, I’m trying to identify the real problems and get
them fixed. Unfortunately people like to bitch and moan a lot more than
they like to report bugs.

> One reports bugs only if one expects that the situation will improve.

Um, look at the alsa-devel archives or the ALSA CVS commit mailing list.
We close dozens of bugs each week. I personally closed more than 50
last week (most had been fixed months ago). 90% of ALSA development
happens through the bug tracker.
HAHA, “average commodity hardware”, that’s a good one. I think you
VASTLY underestimate the difficulty of maintaining good ALSA drivers.
There are hundreds of times more sound chipset/codec combinations than
there are ALSA developers. This is not like network or disk controller
drivers where having the datasheet is the norm – in ALSA reverse
engineered drivers are the norm and there can be dozens of variations on
a single chipset all of which the driver must handle. It would be one
thing if the vendors helped but they don’t – sound is considered desktop
stuff and they don’t consider the Linux desktop market worth their time.
Check out the linux-audio-dev and linux-audio-user archives. ALSA has
been working perfectly for all of those users for years.

Lee

Date: Thurs, Jan 5 2006 8:29 pm
From: Lee Revell

On Thu, 2006-01-05 at 21:24 +0100, Edgar Toernig wrote:
> Lee Revell wrote:
Broken app. It needs to set a sane buffer size and not rely on the
driver default.

Lee

== 7 of 12 ==
Date: Thurs, Jan 5 2006 8:33 pm
From: Marcin Dalecki
On 2006-01-05, at 21:28, Lee Revell wrote:
bug tracker.
> Check out the linux-audio-dev and linux-audio-user archives. ALSA has
> been working perfectly for all of those users for years.

You are aware of how self contradicting this sounds?!
-

== 8 of 12 ==
Date: Thurs, Jan 5 2006 8:33 pm
From: Lee Revell

On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> Glaring problems on average commodity hardware

A good first step would be to mention which driver, ALSA version and
soundcard you are using.

Lee

== 9 of 12 ==
Date: Thurs, Jan 5 2006 8:39 pm
From: Lee Revell

On Thu, 2006-01-05 at 21:32 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 21:28, Lee Revell wrote:
>
> > We close dozens of bugs each week. I personally closed more than 50
> > last week (most had been fixed months ago). 90% of ALSA development
> > happens through the bug tracker.
>
> …
>
> > Check out the linux-audio-dev and linux-audio-user archives. ALSA has
> > been working perfectly for all of those users for years.
>
> You are aware of how self contradicting this sounds?!
>

Not at all. By “working perfectly” I obviously didn’t mean that ALSA
hasn’t had a bug in years – I meant that when we DO get an actionable
bug report we fix it.

Lee
Date: Thurs, Jan 5 2006 8:48 pm
From: Patrizio Bassi

Lee Revell ha scritto:
>
yes i am the one (testing lots of voip solutions) in the bug report.

i told you that kiax has a similar problem

i think this sort of mail flood in kml is not productive.
As Lee asked, let’s use their mantis system and leave kml free.

this is going OT…from OSS removal, to Alsa bad design, to Alsa
bugs…what else?

Patrizio
Date: Thurs, Jan 5 2006 9:01 pm
From: Lee Revell

Are you going to fucking help or should I just killfile you now?

Lee

https://bugtrack.alsa-project.org/alsa-bug/login_page.php?
stenografia e linux
http://www.mcdonald.org.uk/StegFS/
blog di bottone
http://laspinanelfianco.wordpress.com/

numeri di telefono
http://welcome.hp.com/country/it/it/contact_us.html
http://welcome.hp.com/country/it/it/contact/phone_assist.html#section2
PC e Notebook Pavillion e Presario, HP Deskjet, HP Photosmart, Scanner,
prodotti All-in-one e Print-Scan-Copy, HP Digital Scanner, Proiettori,
Masterizzatori, DVD, materiali di consumo 848 800 871 Lunedì-Venerdì
ore 8:00 – 18:00
esclusi giorni festivi

Business Personal Computer Desktop e portatili, tablet PC,
HP Jornada, HP Ipaq, Workstation, Stampanti Laserjet,
plotter Designjet, prodotti di Networking, Print-server,
Storage, Server Unix, HP Openview 02 92607330
Lunedì-Venerdì
ore 9.00-13.00 / 14.00- 18:00
esclusi giorni festivi
http://www.benq.it/wheretobuy/spotlocator/index.cfm?city=Roma&regionid=294&countryid=102&filter=
http://www.ar2001.com/
da kernel di linuxche carta del suono usi
http://www.4front-tech.com/download.cgi
http://www.4front-tech.com/oss.html
http://www.tldp.org/HOWTO/Software-RAID-HOWTO-5.html#ss5.8
Gentile cliente,

grazie per la sua e-mail e Buon Anno, siamo spiacenti ma nella sua zona non abbiamo
un punto vendita che rivende il prodotto da lei richiesto in oggetto.
In attesa di una sua gradita risposta, la saluto.

Marilena
ass. clienti
marilena@cosvalitaly.com
linux sulla memoria cache che non ha bisogno di () ma di spazi piu grandi..
==============================================================================
TOPIC: Fw: crash on x86_64 – mm related?
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/606439b30ee68397
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 5 2006 9:19 pm
From: Linus Torvalds

On Thu, 5 Jan 2006, Ryan Richter wrote:
>
> Another one. I can’t keep running this kernel – nearly all of our
> backup tapes are erased now. If a drive were to fail today, we would
> lose hundreds of GB of irreplacible data. I’m going back to 2.6.11.3
> until we have a full set of backups again.

Yeah, don’t trash your backups.

If/when you try something again, how about these two trivial one-liners?

I’m not 100% sure the mapcount sanity check is strictly speaking right (no
locking between mapcount/pagecount comparison), but the page count really
should never fall below the mapcount, so aside from races that I don’t
think can be triggered in practice, this might be very useful to find
where those pesky page counts suddenly disappear..

Right now we get the oops “too late” – something has decremented the page
count way too far, but we don’t know what it was, and the actual function
that triggers it _seems_ to be harmless.

The other part of the patch is to clear “page” when it’s being free’d, in
case somebody tries to free the same thing twice. I don’t see how that
could happen either, but…

The patch is untested in every way. No guarantees.

Linus

—
diff –git a/drivers/scsi/st.c b/drivers/scsi/st.c
index c4aade8..18e60e1 100644
— a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -4481,6 +4481,7 @@ static int sgl_unmap_user_pages(struct s
for (i=0; i _count); \
})

==============================================================================
TOPIC: mutex subsystem, -V14
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/4c8c90ef08c343fd
==============================================================================

== 1 of 2 ==
Date: Thurs, Jan 5 2006 2:36 pm
From: Ingo Molnar
* Joel Schopp jschopp@austin.ibm.com> wrote:

> Took a glance at this on ppc64. Would it be useful if I contributed
> an arch specific version like arm has? We’ll either need an arch
> specific version or have the generic changed.

feel free to implement an assembly mutex fastpath, and it would
certainly be welcome and useful – but i think you are wrong about SMP
synchronization:

> Anyway, here is some disassembly of some of the code generated with my
> comments:
>
> c00000000049bf9c :
> c00000000049bf9c:       7c 00 06 ac     eieio
> c00000000049bfa0:       7d 20 18 28     lwarx   r9,r0,r3
> c00000000049bfa4:       31 29 ff ff     addic   r9,r9,-1

> The eieio is completly unnecessary, it got picked up from
> atomic_dec_return (Anton, why is there an eieio at the start of
> atomic_dec_return in the first place?).

a mutex is like a spinlock, it must prevent loads and stores within the
critical section from ‘leaking outside the critical section’ [they must
not be reordered to before the mutex_lock(), nor to after the
mutex_unlock()] – hence the barriers added by atomic_dec_return() are
very much needed.

Ingo

== 2 of 2 ==
Date: Thurs, Jan 5 2006 2:41 pm
From: Ingo Molnar
* Linus Torvalds torvalds@osdl.org> wrote:

> Well, if the generic one generates _buggy_ code on ppc64, that means
> that either the generic version is buggy, or one of the atomics that
> it uses is buggily implemented on ppc64.
>
> And I think it’s the generic mutex stuff that is buggy. It seems to
> assume memory barriers that aren’t valid to assume.

in those headers i’m only using atomic_dec_return(), atomic_cmpxchg()
and atomic_xchg() – all of which imply a barrier. It is
atomic_inc/add/sub/dec() that doesnt default to an implied SMP barrier.

but it’s certainly not documented too well. If atomic_dec_return() is
not supposed to imply a barrier, then all the affected architectures
(sparc64, ppc64, mips, alpha, etc.) are overdoing synchronization
currently: they all have barriers for these primitives. [They also have
an implicit barrier for atomic_dec_test() - which is being relied on for
correctness - no kernel code adds an smp_mb__before_atomic_dec() barrier
to around atomic_dec_test().]

the patch below adds the barriers to the asm-generic mutex routines, so
it’s not like i’m lazy , but i really think this is unnecessary.
Adding this patch would add a second, unnecessary barrier for all the
arches that have barrier-less atomic ops.

it also makes sense: the moment you are interested in the ‘previous
value’ of the atomic counter in an atomic fashion, you very likely want
to use it for a critical section. (e.g. all the put-the-resource ops
that use atomic_dec_test() rely on this implicit barrier.)

Ingo

Index: linux/include/asm-generic/mutex-dec.h
===================================================================
— linux.orig/include/asm-generic/mutex-dec.h
+++ linux/include/asm-generic/mutex-dec.h
@@ -19,6 +19,7 @@
*/
#define __mutex_fastpath_lock(count, fail_fn)    \
do {         \
+ smp_mb__before_atomic_dec();     \
  if (unlikely(atomic_dec_return(count) http://www.gentoo.org/doc/en/vserver-howto.xml
quindi cerca “howto apache” su google..
quindi cerca “howto apache” su google..

[17:39] *** AzzurraCGI742 [~AzzurraCG@Azzurra=421FB3F1.pool871.interbusiness.it] ????? ?? ????? #gentoo
[17:39] *** ???? ??????: www.gentoo.org | Se dovete incollare piu’ di 3 righe usate nopaste | puniremo l’uso delle scritture tachigrafiche, se non vi piace cambiate canale | www.no1984.org leggete e diffondete | comandi dati ed output richiesti vanno forniti *verbatim et literatim* | perl sempre perl è iTunes gira con Wine?
[17:40] guru unix
[17:40] *** AzzurraCGI742 ??????(?) ??? ?? chiudigliocchi
[17:40] AzzurraCGI742, ti diverti?
[17:41] era una mia frase happy
[17:41] ceccoggi: .Xdefaults nella tua home
[17:41] com’e’ possibile che io senta l’audio?
[17:41] ALSA device list:
[17:41]    No soundcards found.
[17:41] è in dmesg tongue
[17:41] non cel’ho
[17:41] ceccoggi: ad esempio, XTerm*reverseVideo:     true
[17:41] ceccoggi: crealo
[17:41] bsolar a me funge cd
[17:42] cdcache no
[17:42] peccato
[17:42] happy
[17:42] tongue
[17:42] perfetto
[17:42] wink
[17:43] ora un’ultima cosa
[17:43] esistono drivers wireless per sk usb roper freelan?
[17:44] *** dercba [~hfghf@Azzurra-7BC7B954.pool8253.interbusiness.it] ???????(?) ????? [Quit: ]
[17:45] *** gianx [~gianx@Azzurra=5E01CE04.37-151.net24.it] ???????(?) ????? [Quit: Sto andando via]
[17:47] *** fanal1 [~xaero@87.10.Azzurra-41D38A67] ????? ?? ????? #gentoo
[17:52] *** dr_gogeta86 [~dr_gogeta@Azzurra-467C5A29.29-151.libero.it] ???????(?) ????? [Ping timeout]
[17:54] *** iAlbertoz [~morpheusz@Azzurra=78A93D96.f5.ngi.it] ???????(?) ????? [Read/Dead Error: Connection reset by peer]
[17:54] *** Varg`Away [~vargas@Azzurra=72996CE3.pool8252.interbusiness.it] ????? ?? ????? #gentoo
[17:57] *** messia [~juve@Azzurra-15C82C85.pool8257.interbusiness.it] ????? ?? ????? #gentoo
[17:57] /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la
[17:58] ragazzi, ho un problemino
[17:58] temo che questo dipenda da quando ho fatto casino togliendo le gcc-3.3.6
[17:58] quando erano ancora attive
[17:58] ho provato a riavviare e non parte + il login
[17:58] ho riemerso le libstdc++
[17:58] ma una ebuild me le cerca ancora li e si pianta perche’ non le trova
[17:58] cosa posso fare?
[17:59] in realtà non ho nemmeno la directory gcc-lib
[17:59] vedo che il monitor lampeggia per 3 volte
[17:59] ma poi non parte xdm
[17:59] rimane in shel
[17:59] e mi chiede di loggarmi da qua
[18:00] orvuar
[18:00] *** fe [~f@Azzurra-3711C82F.f4.ngi.it] ???????(?) ????? [Quit: Leaving]
[18:00] su linux esiste un modo per uccidere una connessione ?
[18:00] se faccio starx mi da un po’ di errori
[18:00] lol
[18:00] Shocker580, perche’ su windows esiste?
[18:00] su
[18:00] si
[18:01] sì: la scorciatoia ctrl+alt+canc ripetuta due volte
[18:01] quindi la risposta ? no ?
[18:01] Shocker580: la risposta è: cosa intendi?
[18:01] bom bom
[18:01] Thrain: non intendo killare il processo, intendo la connessione
[18:01] tipo “XIO: fatal IO error 104 (Connection reset by peer) on X server”:0.0″
[18:01] Shocker580: spiegati cazzo
[18:02] Shocker580, vuoi sapere l’equivalente di cosa per windows?
[18:02] oppure “Fatal server error: no screen found”
[18:02] Shocker580: comunque io farei una cosa molto facile: vado da root e /etc/init.d/net.eth0 stop
[18:02] ceccoggi, hai mai lanciato xorgcfg?
[18:02] ho una connessione ftp con pincopallino al mio pc, vorrei disconnettere pincopallino dal mio pc senza terminare il processo ftp
[18:02] lol
[18:02] ah
[18:02] eh, l’avevo lanciato da fluxbox
[18:02] Shocker580, usare ettercap
[18:02] vedi che non ti sei spiegato cheesy ?
[18:02] bene, cosa diavolo ? ?
[18:02] Shocker580, oppure iptraf
[18:03] o anche vfnc
[18:03] l’unica cosa su cui non ero sicuro era la freq verticale del monitor
[18:03] emerge vfnc
[18:03] Shocker580, o anche antani
[18:03] !google vfnc
[18:03] http://smart.uiah.fi/home/one-dimensional_usability/6_results.doc
[18:03] me ne basta uno
[18:03] ip-traf
[18:03] !google ip-traf
[18:03] http://iptraf.seul.org/
[18:04] emerge ip-traf nel caso
[18:04] ok, grazie gente happy
[18:05] configure: error: no acceptable Java compiler found in $PATH
[18:05]     come risolvo?
[18:05] *** Wolfheart [~azzurra@Azzurra-49074A7D.pool8256.interbusiness.it] ???????(?) ????? [Quit: Leaving]
[18:05] StaCk_, se hai un java compiler installato aggiungi il suo path in $PATH
[18:05] altrimenti installalo
[18:05] mh
[18:06] ma io stavo facendo il revdep-rebuild per aggiornare gcc
[18:06] ma sto iptraf killa pure una connessione ?
[18:06] fico
[18:06] non mi serve un java compiler
[18:06] -.-
[18:06] Shocker580: no
[18:06] sta compilando(cercando di compilare) db
[18:06] Shocker580, scusa errore mio allora tongue
[18:06] *** fanal1 ???????(?) #gentoo []
[18:06] ok, alternativa ?
[18:06] *** duanp [~asdrubale@Azzurra=6989A3A4.pool8253.interbusiness.it] ????? ?? ????? #gentoo
[18:07] salve
[18:08] non mi parte nemmeno + il muose
[18:08] Shocker580, ettercap
[18:08] da xorgcfg
[18:08] come faccio a sapere dove è collegato
[18:08] a quale dev?
[18:08] cat /dev/che/pensi/ci/sia/il/mouse
[18:08] e poi muovi il mouse
[18:08] ceccoggi, che mouse hai?
[18:08] avevo provato a far funzionare l’usb con gentoo, perch? non funzionava ho seguito l’how-to su gentoo.org
[18:09] se spara caratteri è quello
[18:09] prova con cat /dev/input/mice
[18:09] un mouse normalissimo con scroll
[18:09] ps2
[18:09] ceccoggi, si ma ps2 usb ?
[18:09] /dev/psaux
[18:09] e ho scoperto che nella cofigurazione del mio kernel ci manca prorpio la voce “USB Mass Storage Write-Protected Media Detection (EXPERIMENTAL)”
[18:09] non ‘? proprio
[18:10] ma se faccio cat /dev/psaux non mi da niente
[18:10] duanp, ti manca anche UTF?
[18:10] ceccoggi, prova con /dev/input/mice
[18:10] ? mai capitato a qualcun altro?
[18:10] ah ok
[18:10] ho capito
[18:10] devo muovere il mouse
[18:10] ragazzi una domanda, c’? una minima possibilit? di far partire una distribuzione linux (ben ricompilata per la piattaforma) su una playstation2 modificata ?
[18:11] bsolar, sei un guru unix te?
[18:11] UTF? non mi sembra
[18:11] ora controllo
[18:11] duanp, non è inerente al tuo problema
[18:11] bah, ora mi mette i caratteri a cazzo
[18:12] provo a riavviare
[18:13] *** nomadsoul [~nomadsoul@Azzurra-2859F2DD.pool8250.interbusiness.it] ???????(?) ????? [Read/Dead Error: Input/output error]
[18:14] ragazzi sto impazzendo
[18:14] da xorgcfg non riesco a fare niente
[18:14] non mi parte + xdm
[18:14] come faccio?!:-(
[18:15] *** deneb11111 [~bdanieleb@Azzurra=76B3D66C.pool876.interbusiness.it] ????? ?? ????? #gentoo
[18:16] bsolar aiutami tu, ti prego!
[18:17] *** deneb11111 [~bdanieleb@Azzurra=76B3D66C.pool876.interbusiness.it] ???????(?) ????? [Quit: ]
[18:17] ceccoggi che capita?
[18:17] vim /etc/rc.conf
[18:18] sapreste dire coma mai uname -a dice questo??
[18:18] Linux lsd 2.6.14-gentoo-r5 #8 Fri Jan 6 13:10:58 CET 2006 i686 AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux
[18:18] che hai come DISPLAYMANAGER
[18:18] #8 che non ho 8 cpu?
[18:18] xdm
[18:18] e come xsession fluxbox
[18:18] StaCk_ ottava volta che compili il kernel
[18:18] e nemmeno [ ] Symmetric multi-processing support nel kenel
[18:18] lu_zero: eh ok -.-
[18:18] prima funzionava perfettamente
[18:18] ora, riavviando, nada
[18:19] cosa potrebbe essere??idee?
[18:19] se provo a fare /etc/init.d/xdm start mi dice che xdm è già “startato”
[18:20] *** duanp [~asdrubale@Azzurra=6989A3A4.pool8253.interbusiness.it] ???????(?) ????? [Quit: Leaving]
[18:20] *** duanp [~asdrubale@Azzurra=6989A3A4.pool8253.interbusiness.it] ????? ?? ????? #gentoo
[18:20] *** duanp [~asdrubale@Azzurra=6989A3A4.pool8253.interbusiness.it] ???????(?) ????? [Quit: Leaving]
[18:21] nessuno riesce ad aiutarmi?
[18:22] *** Manuelix [~Manu@Azzurra=6F6C39F2.42-151.net24.it] ????? ?? ????? #gentoo
[18:22] ceccoggi, /etc/init.d/xdm stop
[18:22] ceccoggi, /etc/init.d/xdm zap
[18:22] ciao a tutti
[18:22] ceccoggi, /etc/init.d/xdm start
[18:23] niente
[18:23] lampeggia 3 volte ma non entra
[18:23] poi ritorna in shell
[18:24] X e’ configurato per bene?
[18:24] eh, boh…
[18:28] *** marijuana [~marijuan@Azzurra-7DDAF8F2.pool8259.interbusiness.it] ????? ?? ????? #gentoo
[18:28] bsolar, ci sei?
[18:31] *** sawk`away ??????(?) ??? ?? sawk
[18:35] *** nihil39 [~nihil39@Azzurra=513BB2A8.pool877.interbusiness.it] ???????(?) ????? [Quit: KVIrc 3.2.0 'Realia']
[18:36] *** Manuelix [~Manu@Azzurra=6F6C39F2.42-151.net24.it] ???????(?) ????? [Ping timeout]
[18:38] *** Guglie [~Guglie@195.190.Azzurra=13303269] ???????(?) ????? [Quit: ciauz..]
[18:39] in pratica ora ho cancellato il file xoeg,conf e parte
[18:40] *** SiLent`Man [~uhm@Azzurra=115ABC7B.pool871.interbusiness.it] ????? ?? ????? #gentoo
[18:40] *** Manuelix [~Manu@Azzurra=6F6C39F2.42-151.net24.it] ????? ?? ????? #gentoo
[18:40] *** IlPresidente [studenti@2001:1638:306:209::132] ???????(?) ????? [vogon.azzurra.org itgate.azzurra.org]
[18:41] come faccio a memorizzare la risoluzione?
[18:41] e impostarla, soprattutto?
[18:41] da fluxbox?
[18:42] editi xorg.conf
[18:43] ora non l’ho +
[18:43] ma non appena lo creo non parte + niente
[18:43] *** marijuan [~marijuan@Azzurra=326D83D0.pool8259.interbusiness.it] ????? ?? ????? #gentoo
[18:43] O_o
[18:43] interessante
[18:44] eh?
[18:44] già
[18:44] a me non parte X senza xorg.conf tongue
[18:44] io ho solo xorg.conf.example
[18:44] *** IlPresidente [studenti@2001:1638:306:209::132] ????? ?? ????? #gentoo
[18:46] ceccoggi, hai letto questo? http://www.gentoo.org/doc/en/xorg-config.xml
[18:46] grazie, gli drò una letta
[18:47] prego happy
[18:47] chi sa come mai durente l’emerge di db mi da errore durante il configure che non trova un compilatore java in $PATH?a che gli serve?devi davvero installarne uno??cosa consigliate?
[18:47] StaCk_: te ne hai installato uno?
[18:47] direi di no
[18:48] ma la prima volta come ha fatto??
[18:48] è perché sono partito da stage3?
[18:48] forse la prima volta non era abilitata l’USE java
[18:48] mh
[18:49] *** marijuana [~marijuan@Azzurra-7DDAF8F2.pool8259.interbusiness.it] ???????(?) ????? [Ping timeout]
[18:49] e non dovrebbe tirarsela dietro come dipendenza?
[18:49] si
[18:49] ma devi impostarla poi con java-config
[18:49] java-config –list-available-vms
[18:49] ti dice nulla
[18:49] ?
[18:49] ah ecco perché ora mi chiede di emergere blackdown
[18:49] *** marijuan [~marijuan@Azzurra=326D83D0.pool8259.interbusiness.it] ???????(?) ????? [Quit: Sto andando via]
[18:49] pe
[18:50] ma bsolar ma tu hai tutta la documentazione con comandi eccetera in mente? tongue
[18:50] che memoria
[18:50] più intuitivo di quello…
[18:50] http://www.rafb.net/paste/results/nZ0F7B90.html
[18:50] bsolar, io pensavo a java -version
[18:50] happy
[18:50] Manuelix: che non funzionerebbe
[18:51] StaCk_: sebra che non hai installato quella roba
[18:51] StaCk_: installa un jre
[18:51] sì io partivo dalla verifica della presenza o meno del compilatore
[18:51] l’ho presa larga
[18:51] Manuelix: il compilatore anche se c’è, non è detto sia in PATH
[18:51] il suo problema è proprio che non è in PATH, per un motivo o per l’altro
[18:51] appunto… l’ho presa molto larga
[18:51] gh
[18:51] talmente larga che eri fuori strada happy
[18:52] infatti wink
[18:52] ho sbagliato all’incorcio
[18:52] be bsolar se non era installato nulla sicuramente in path non c’era
[18:52] *** gesar [~gesar@Azzurra=6D5F5DA9.pool8259.interbusiness.it] ????? ?? ????? #gentoo
[18:54] ciao
[18:54] Manuelix: ok, ma non è vero il contrario
[18:54] Manuelix: cioè, se non è in PATH non è detto non sia installato
[18:54] bsolar: Rf ] dev-java/sun-jre-bin-1.4.2.10
[18:54] direi che lo ho installto
[18:55] *** Arbiter [~arbiter@Azzurra=12417BEA.41-151.net24.it] ???????(?) ????? [Client closed connection]
[18:55] ook
[18:55] sì bsolar io non ho detto quello
[18:55] e perché list-available-vms non te lo mostra?
[18:55] vediamo…
[18:55] mh
[18:55] booh
[18:55] happy
[18:55] http://gentoo-wiki.com/Java_FAQ
[18:55] o meglio non c’ho proprio pensato ero molto prima
[18:55] guarda qui: http://gentoo-wiki.com/Java_FAQ
[18:55] *** Dorog [~lll@Azzurra-1391CC55.pool8254.interbusiness.it] ???????(?) ????? [Quit: Sto andando via]
[18:55] la soluzione e’ un python-updater
[18:56] mh
[18:56] StaCk_: vabbé prova java-config –set-system-vm sun-jdk-1.4.2.10
[18:56] ci guardo
[18:56] aah
[18:56] e se vuoi anche qui: http://www.gentoo.org/doc/en/java.xml
[18:56] ImportError: No module named java_config
[18:56] nulla
[18:56] se devi aggiornare python può essere
[18:56] in sostanza e’ una cappella di python non di java, proprio nel “java-config” di gentoo
[18:56] basta lanciare un python-updater e si rimette tutto a posto.
[18:57] *** Fiz [sgrunt@Azzurra=6D87375D.pool8261.interbusiness.it] ????? ?? ????? #gentoo
[18:57] *** Fiz ???????(?) #gentoo []
[18:57] vediamo
[18:59] ma sto cavolo di anti-nick lunghi
[18:59] non potete toglierlo ?
[18:59] sawk: potere, si
[18:59] …
[18:59] il problema è, è la cosa migliore?
[18:59] non serve a nulla tutto ci
[18:59] a me non danno fastidio, tanto irssi li tronca…
[18:59] ad altri danno fastidio
[18:59] appunto
[18:59] *** ceccoggi [~ceccoggi@Azzurra-3D36AAD4.cust-adsl.tiscali.it] ???????(?) ????? [Quit: Sto andando via]
[18:59] comunque il fondatore è federico, quindi chiedi a lui
[18:59] vabb? allora me ne esco ogni volta che devo cambiare nick
[19:00] sai che roba
[19:00] sawk: no
[19:00] sawk: cioè
[19:00] vabb? non importa
[19:00] sawk: cambiare nick puoi
[19:00] non posso
[19:00] ma se è più lungo di 15 caratteri non ti lascia
[19:00] eh appunto
[19:00] e comunque con un nick così lungo non ti lascerebbe più entrare
[19:00] *** Praise ??????(?) ??? ?? Sawkbrutto
[19:00] visto che si può?
[19:00] sawk: ma soprattutto, che nick vorresti mettere?
[19:00] *** Sawkbrutto ??????(?) ??? ?? Praise
[19:00] ? colpa dell’inglese
[19:01] cheesy
[19:01] non importa comunque
[19:01] sawk: sono curioso
[19:01] happy
[19:01] *** sawk ??????(?) ??? ?? sawkLovesGuitar
[19:01] volevo mettere `
[19:01] -_-
[19:01] ma vabb? happy
[19:01] a dopo
[19:01] ahaha
[19:01] XD
[19:01] sawkLovesGuitar: dopo mi spieghi a chi importa se ami la tua chitarra o meno happy
[19:02] *** doctorzoidberg [~doctorzoi@Azzurra=6D96305E.37-151.net24.it] ????? ?? ????? #gentoo
[19:04] *** Guest74631 [~kvirc@217.201.Azzurra=58E68E02] ????? ?? ????? #gentoo
[19:04] *** SteelRage [~kaeel@Azzurra-674DA6C0.47-151.net24.it] ????? ?? ????? #gentoo
[19:11] *** Arbiter [~arbiter@Azzurra=12417BEA.41-151.net24.it] ????? ?? ????? #gentoo
[19:12] *** doctorzoidberg [~doctorzoi@Azzurra=6D96305E.37-151.net24.it] ???????(?) ????? [Ping timeout]
[19:14] *** zast\study [~zast@Azzurra-BF69A9.mi2.albacom.net] ???????(?) ????? [Quit: C'era scritto "Richiesto WIN98 o Superiore.... " Io ho messo Gentoo =)     "]
[19:14] *** doctorzoidberg [~doctorzoi@Azzurra=2A5FD626.37-151.net24.it] ????? ?? ????? #gentoo
[19:15] * Manuelix is away: Doccia
[19:15] se java-config –list-available-vms mi dice [sun-jre-bin-1.4.2.10] devo poi dare ava-config –set-system-vm sun-jre-bin-1.4.2.10
[19:15] giusto?
[19:16] si
[19:16] ah era solo un warning credo
[19:16] nopaste
[19:16] pe
[19:16] tutto quel rosso mi distraeva
[19:16] http://www.rafb.net/paste/results/bHi94v77.html
[19:17] è perciò andato a buon fine giusto?
[19:17] mhhh
[19:17] * StaCk_ perplesso
[19:17] *** theeldar [~finrod@Azzurra=5C101C0.255-23.fastweb.fw] ???????(?) ????? [Quit: leaving]
[19:18] *** SteelRage [~kaeel@Azzurra-674DA6C0.47-151.net24.it] ???????(?) ????? [Client closed connection]
[19:19] StaCk_: si
[19:19] non penso visto che ti da un errore: ma c’e’ la JVM installata?!?
[19:19] o meglio
[19:19] considerando che non è un jdk, si
[19:19] beh perciò vado senza problemi vero??
[19:19] prova
[19:19] non so se gli serve solo il RE
[19:20] beh
[19:20] se non va installo pure il jdk
[19:20] grazie mille a tutti
[19:23] *** grasso [~grasso@Azzurra=7D3F5A61.38-151.net24.it] ????? ?? ????? #gentoo
[19:27] *** disabled [~disabled@Azzurra=2C6B1E92.pool876.interbusiness.it] ???????(?) ????? [Read error: Connection reset by peer]
[19:32] *** Varg`Away [~vargas@Azzurra=72996CE3.pool8252.interbusiness.it] ???????(?) ????? [Ping timeout]
[19:34] *** tuxman [~caesar@Azzurra=2D215E73.pool80104.interbusiness.it] ????? ?? ????? #gentoo
[19:34] ciao
[19:34] * tuxman sera
[19:36] *** Dorog [~lll@Azzurra-1391CC55.pool8254.interbusiness.it] ????? ?? ????? #gentoo
[19:38] * sawkLovesGuitar bsolar
[19:38] conta
[19:38] perch? ? come dire “vado a suonare”
[19:38] *** sawkLovesGuitar ??????(?) ??? ?? sawk
[19:38] si chiama filosofia Hendrixiana :-d
[19:39] sawk: devi capire che io seguo una filosofia simile allo sviluppatore di irssi
[19:40] ma lol
[19:40] sawk: http://irssi.org/documentation/faq
[19:40] sawk: cercati la Q: How do I announce that I’m away/back in all channels I’ve joined? Or how do I change my nick when setting myself away/back?
[19:41] …
[19:41] happy
[19:42] cheesyD
[19:42] uso anche io irssi
[19:42] ma non uso mai /away
[19:42] neanche io
[19:42] ma lol
[19:42] infatti a volte trovo una mezza dozzina di query imploranti aiuto
[19:42] quando torno happy
[19:43] si generalmente ti trovi le query importanti quando non sei al pc
[19:43] quando ci sei ti scassano solo i maroni cheesy
[19:43] eh dipende importanti per chi happy
[19:43] *** disabled [~disabled@Azzurra=4F1A680.pool876.interbusiness.it] ????? ?? ????? #gentoo
[19:43] *** SteelRage [~kaeel@Azzurra-674DA6C0.47-151.net24.it] ????? ?? ????? #gentoo
[19:43] si infatti
[19:43] *** lizz [~lizz@Azzurra=7B02A14A.pool80104.interbusiness.it] ????? ?? ????? #gentoo
[19:43] *** Varg`Away [~vargas@Azzurra-449E36E.pool8256.interbusiness.it] ????? ?? ????? #gentoo
[19:44] * lizz salve all
[19:44]
ragazzi in rcupdate cosa vanno i demoni?
[19:44] ?
[19:44] lizz: eh?
[19:44] no i vampiri
[19:44] cosa vanno ?
[19:44] cheesy
[19:45]
rag? non fate caso ma sto na pezza
[19:45] eh ?
[19:45]
allora
[19:45]
in rc-update vanno i servizi che avvia
[19:45]
giusto?
[19:46] rc-update ? una utility che gestisce l’avvio dei demoni di init
[19:46]
ok
[19:46]
allora e come avevo detto io
[19:46] eh non proprio cheesy
[19:46]
mi è sorto un piccolo problema
[19:47]
io per usare l’isdn
[19:47]
ho scaricato i sorgenti li ho compilati
[19:47] I don’t know
[19:47]
make config make e make install
[19:47] isdn = morte
[19:47] gh
[19:47] a dopo
[19:47] * sawk usa /away
[19:47] cheesy
[20:38] ok
[20:38] *** [equilibrium] [~equilibri@Azzurra=4996BFA3.sn1.eutelia.it] ????? ?? ????? #gentoo
[20:38] flowolf: era ora
[20:38] gh
[20:38] flowolf: è in ritardo sulla realtà però…
[20:39] ho anche preso il primo romanzo di narnia, e gli do un’occhiata prima di regalarlo a mia cugina happy
[20:39] *** sparker [~sparker@Azzurra=4D388998.pool80180.interbusiness.it] ???????(?) ????? [Quit: Leaving]
[20:40] bsolar: io li ho presi tutti
[20:40] però poi sono usciti su internet
[20:40] e mi volevo tagliare le palle cheesy
[20:41] c’era anche un megatomo con tutti in uno
[20:41] si, quello che ho preso io
[20:41] vicino alla colonna con i libri di potty
[20:41] ma cristo boia
[20:41] gh
[20:41] quelli di gp2x non stanno rilasciando sorgenti
[20:41] ti sei accorto del pacco?
[20:41] :>
[20:42] no
[20:42] non è un pacco
[20:42] ne possono rifiutarti di rilasciare i sorgenti
[20:43] se solo per il nome torvalds si è incazzata come una bestia
[20:43] questo dovrebbe fargli girare abbastanza le palle
[20:43] magari ti trovi il CD allegato alla console >
[20:43] :>
[20:44] no
[20:44] ci sono aggiornamenti da scaricare su internet
[20:44] devono rilasciare il sorgente anche di quelli
[20:46] dannato cdrecord! la key dovrebbe scadere in giugnoe invece col nuovo anno kaput!
[20:47] JimiCH: che cazzo dici?
[20:48] volevo dire Jippocheesy
[20:48] *** IlPresidente [studenti@2001:1638:306:209::132] ???????(?) ????? [Ping timeout]
[20:48] porco e fora hai provato a usare cdrecord dal 1 gennaio in poi?
[20:49] non funziona, bisogna aspettare che schilling se ne accorga e generi una nuova key
[20:49] una KEY di cosa?
[20:49] quella dentro cdrecord-wrapper.sh
[20:50] *** ty [~unix@Azzurra-5B72C75E.pool82105.interbusiness.it] ???????(?) ????? [Quit: ]
[20:50] non hai mai masterizzato un dvd?
[20:50] *** IlPresidente [studenti@2001:1638:306:209::132] ????? ?? ????? #gentoo
[20:50] io fatto montagne di cd e dvd
[20:50] ma non ho mai usato una key che una
[20:50] e cosa usi
[20:50] k3b + cdrecord + un altro po’ d iroba
[20:50] tongue
[20:50] mai anvuto problemi di “Alarm clock”?
[20:50] *** ty [~unix@Azzurra-5B72C75E.pool82105.interbusiness.it] ????? ?? ????? #gentoo
[20:51] Jippo: no ma conosco bene la terapia tapioca
[20:51] Praise: prematurata la supercazzola? happy
[20:51] praise mi se che non hai ancora provato a masterizzare un dvd col nuovo anno
[20:51] aMoNE: solo con lo scappellamento a desrta
[20:53] tongue
[20:54] *** doctorzoidberg [~doctorzoi@Azzurra=550C770E.42-151.net24.it] ???????(?) ????? [Quit: Sto andando via]
[20:56] *** [equilibrium] [~equilibri@Azzurra=4996BFA3.sn1.eutelia.it] ???????(?) ????? [Quit: Sto andando via]
[20:58] *** [ViPer] [~UNIX@Azzurra=4D89BA15.pool8252.interbusiness.it] ????? ?? ????? #gentoo
[20:58] hai installato app-cdr/cdrecord-prodvd o app-cdr/cdrtools?
[20:58] ftp://ftp.berlios.de/pub/cdrecord/ProDVD/README.key
[20:58] non sono su gentoo
[20:58] ftp://ftp.berlios.de/pub/cdrecord/ProDVD/cdrecord-wrapper.sh
[20:59] e che ci fai qui dentro?^
[20:59] infatti, uno pu? joinare solo se usa solo e unicamente gentoo
[20:59] in ogni macchina
[20:59] cellulare compreso -_-
[20:59] i desktop sono tutti suse
[20:59] gentoo lo tengo su un servertongue
[21:00] a ok allora puoi resrtare
[21:00] *** lizz [~lizz@Azzurra=7B02A14A.pool80104.interbusiness.it] ???????(?) ????? [Client closed connection]
[21:01] Key Expires —> 2006 Jun 11 06:26:40
[21:01] ma che sono ste key?
[21:02] siccome l’autore non rilascia i sorgenti, rilascia solo i binari compilatin per ogni architettura ma con una chiave che espira ogni 6 mesi circa
[21:02] Praise non l’ho capito nemmeno io
[21:02] mi sembra una stronzata
[21:03] per questo continuo amasterizzareda CLI
[21:03] tutti si aspettavano che scadesse a giugno ma sto leggendo in giro che molti hanno problemi dal 1 gennaio
[21:03] e cosa usi AxtERicS?
[21:03] AxtERicS: cdrecord è da cli…
[21:03] tongue
[21:04] eh infatti uso cdrecord
[21:04] e coso mmm
[21:06] *** atax [~atax@Azzurra-129DEB1F.pool8259.interbusiness.it] ???????(?) ????? [Client closed connection]
[21:06] growisofs
[21:06] non mi veniva il nome
[21:06] per i dvd
[21:07] *** |Vargas| [~vargas@Azzurra-449E36E.pool8256.interbusiness.it] ????? ?? ????? #gentoo
[21:07] ’sera
[21:08] *** softhack [~softhack@Azzurra-6138A68E.pool871.interbusiness.it] ???????(?) ????? [Quit: Sto andando via]
[21:08] che comando usi da cli: cdrecord, cdrecord-ProDVD o cdrecord-wrapper.sh?
[21:10] Jippo dipendo che devo fare uso combinazioni di mkiso / cdrecord / growisofs
[21:10] c’? una guida sulla wiki
[21:10] o sulle top tips del forum
[21:10] non ricordo
[21:11] hai masterizzato almeno un dvd dopo il 1 gennaio 2006?
[21:13] *** Jippo [~Pong@Azzurra-6B82BBAF.pool870.interbusiness.it] ???????(?) ????? [Quit: Leaving]
[21:14] bene ci siamo quasi
[21:14] (47 of 234) Compiling/Merging
[21:14] -.-
[21:18] *** anacleto44`0uT ??????(?) ??? ?? anacleto44
[21:32] *** StaCk_ ??????(?) ??? ?? StaCk`out
[21:32] quaquaqua
[21:35] * StaCk`out bye at all
[21:35] bom bom
[21:37] canale 5
[21:37] canale 10

[21:38] l’uomo pi? peloso del mondo

[21:53] a che?
[21:53] a calcio
[21:53] io io
[21:53] vengo io
[21:53] ah
[21:53] ottimo Praise ci manca il portiere
[21:53] so che tu con le palle degli altri ci sai fa happy
[21:53] dorog docet

[22:40] * tuxman sera
[22:42] *** ?????? ????? ? IRC

[17:26] ho una domandina facile facile

[17:26] perchÃ¨ le use delle flag delal cpu sono tra parentesi e non si attivano mai?

[17:26] tipo (-mmx) (-3dnow)

[17:26] e cosÃ¬ via

[17:27] perchÃ¨ sono filtrate

[17:27] su alcune architetture

[17:27] immagino che tu usi amd64 =)

[17:28] eh giÃ
[17:28] Manuelix, c6?

[17:28] sÃ¬

[17:29] mi sa che non mi serve

[17:29] *** _soujiro__ was kicked from #Gentoo by fz [evita abbreviazioni]

[17:29] Laiho, la aggiungerÃ²

[17:30] eheheheh

[17:30] *** atax [~atax@Azzurra-129DEB1F.pool8259.interbusiness.it] has joined #gentoo

[17:30] *** _soujiro__ [~soujiro__@Azzurra=542B075.pool873.interbusiness.it] has joined #gentoo

[17:30] Manuelix, ti passo il link del nopaste?

[17:31] ok

[17:31] ’sera

[17:31] *** Fiz is now known as Fiz_OuT

[17:31] bye

[17:31] *** federico [~scheggia@Azzurra-66B6DDF6.pool8252.interbusiness.it] has quit [Quit: Leaving]

[17:32] *** Laiho left #Gentoo [fshh... ]

[17:32] manuelix anche qui

[17:32]

[17:33] che cosa AzzurraCGI388 ?

[17:33] sono chiudi

[17:33] be sÃ¬ cosa intendi?

[17:33] Manuelix, http://www.rafb.net/paste/results/nhozaz96.html

[17:33] io sono solo qui

[17:33] ok ciao

[17:33] ciao

[17:34]

[17:34] _soujiro__, stando a quello che vedo

[17:35] mi sono scordado l’x86?

[17:35] in grub.conf hai messo kernel-2.6.12-gentoo-10

[17:35] si infatti

[17:35] mentre qui hai kernel-genkernel-x86-2.6.12-gentoo-10

[17:35] che Ã¨ ancora errato

[17:35] come mai?

[17:35] se tu dai uname -a ti accorgi che avrai installato il 2.6.14.qualcosa

[17:35] *** silverfix [~cdere@Azzurra-617766D8.pool876.interbusiness.it] has quit [Quit: c u later]

[17:35] ah si

[17:36] che Ã¨ la versione aggiornata credo

[17:36] sarebbe meglio fare le cose corrette

[17:36] uhm perÃ² in quale occasione ho cambiato?

[17:36] qualcuno sa come faccio a capire qual’è il device (sdax sdbx etcc..) associato a una periferica usb attaccata?

[17:36] in nessuna… semplicemente hai fatto copia e incolla senza sapere cosa facevi

[17:37] Asdru: poco dopo aver collegato la periferica, guarda dmesg

[17:37] *** p| [~kvirc@85.119.Azzurra=5D728830] has joined #gentoo

[17:37] l’ho guardato, ma non lo dice

[17:38] ah bene

[17:38] in effetti l’ultima parte Ã¨ stato cosÃ¬

[17:38] forse può dare una mano questa riga che esce in dmesg , “adding 3-1:1.1 (config #1 interface 1)”

[17:38] *** Laiho [~1.6180339@Azzurra=597C71B2.f5.ngi.it] has joined #Gentoo

[17:38] *** mode/#gentoo [+o Laiho] by ChanServ

[17:38] *** p| [~kvirc@85.119.Azzurra=5D728830] has quit [Quit: KVIrc 3.2.0.20051230 'Anomalies' http://www.kvirc.net/]

[17:38] non mi pare proprio sia quella

[17:39] sei sicuro che sia tutto ok nel kernel?

[17:39] il supporto usb storage e tutto il resto dico

[17:39] lo so che non è quella, pensavo che potesse servire

[17:39] si si

[17:39] da root riesco a montare le penne usb

[17:39] e se faccio partire digikam da root riesco ad accedere anche alla mia macchina fotografica

[17:40] ma usi dei programmi di automount?

[17:40] Manuelix, …da live no posso modificare il make.conf?

[17:40] sÃ¬

[17:40] non uso programmi di automount

[17:40] intendi il make.con dopo aver dato chroot?

[17:41] quindi dopo essere entrato nel tuo sistema

[17:41] se vuoi fare tutto a mano, allora devi anche editare fstab a mano

[17:41] Manuelix, quello che si grub

[17:41] le penne le monto col comando mount device punto_di_montaggio

[17:41] e settare i permessi giusti per far montare anche all’utenet

[17:41] http://topolinux.altervista.org/forum/viewforum.php?f=16

[17:41] quelle periferiche

[17:41] Manuelix, quello che si prende grub

[17:41] mmm non credo che grup prenda make.conf

[17:41] ops

[17:41] *grub

[17:41] *** sawk [~sawk@Azzurra=1E5521B2.cust.tele2.it] has quit [Quit: "Non parlare per niente di sé è un'ipocrisia molto raffinata."]

[17:41] huhauauhua

[17:41] *** Laiho [~1.6180339@Azzurra=597C71B2.f5.ngi.it] has quit [Read error: Connection reset by peer]

[17:41] è questo il punto per dare i permessi anche agli utenti normali, mi serve il device della periferica

[17:42] “Ciao utente di Amarok!”

[17:42] xò non so qual’è

[17:42] *** Asdru was kicked from #gentoo by Gentoo [Non storpiare le parole per favore! - (Kick #453)]

[17:42] *** Asdru [Asdru@Azzurra=4CFDCD57.pool8251.interbusiness.it] has joined #gentoo

[17:42] scusate, ho sbagliato

[17:42] *** lavish [~lavish@Azzurra=5EA41311.25-151.libero.it] has quit [Quit: Lost in the "K" hole]

[17:43] Manuelix, si perÃ² montando il boot dalla live

[17:43] comunque, adsru, se è l’unico device usb che colleghi, se non hai hd sata o scsi

[17:43] lui partirà sempre da sda

[17:43] *** Laiho [~1.6180339@Azzurra=597C71B2.f5.ngi.it] has joined #Gentoo

[17:43] *** mode/#gentoo [+o Laiho] by ChanServ

[17:43] *** sawk [~sawk@Azzurra=1E5521B2.cust.tele2.it] has joined #gentoo

[17:43] poi se inizi a scollegare e ricollegare il dispositivo usb di continuo, c’è il rischio che scali man mano ad sdb ecc

[17:44] ho due periferiche usb, la fotocamera e il ricevitore per il mouse

[17:44] beh il ricevitore del mouse non è una periferica di storage

[17:44] dovrebbe andare sotyto HID

[17:44] solo la fotocamera ha una memoria

[17:44] di quello che hai

[17:44] dovrebbe essere sda allora

[17:44] quindi non vedo il problema

[17:45] a meno che non intendi pendrive con periferiche usb

[17:45] Manuelix, posso far partire nano e modificarlo da lÃ¬

[17:45] ho controllato i device sda, vanno da 2 a 15

[17:45] non c’è nemmeno /dev/sda

[17:45] *** Laiho is now known as [Alexi_Laiho]

[17:46] *** [Alexi_Laiho] is now known as Laiho

[17:46] sÃ¬

[17:46] ma devi modificare grub.conf

[17:46] non make.conf

[17:46] la fotocamera è collegato, è normale?

[17:46] dove l’hai montata?

[17:47] non l’ho montata, l’ho solo collegata

[17:47] Manuelix, si scusa

[17:47] comunque prova a scollegarla e ricollegarla

[17:47] Manuelix, so fuso

[17:47] e rivai con dmesg

[17:47] qualcosa dovrà pur dirti

[17:47] se vuoi te lo posso mandare per DCC

[17:47] cosa?

[17:48] le ultime righe di dmesg?

[17:48] !google nopaste

[17:48] il risultato di dmesg

[17:48] http://www.rafb.net/paste/

[17:48] usa questo

[17:48] *** ceccoggi [~ceccoggi@Azzurra-7E1B8726.cust-adsl.tiscali.it] has joined #gentoo

[17:48] salve a tutti!!

[17:48] posso chiedervi una cosa proprio veloce veloce?

[17:48] spara

[17:48] ho appena installato gentoo+fluxbox

[17:49] *** StaCk_ [~davide@Azzurra-30075997.pool8256.interbusiness.it] has joined #gentoo

[17:49] Manuelix, ok sono dentro

[17:49] ok

[17:49] ora volevo installare firefox

[17:49] ceccoggi: bella pe te, io non ce la faccio a staccarmi da kde, troppo attaccato

[17:49] si

[17:49] *** ProT-0-TypE [~Gentoo@Azzurra-5F106AA9.pool8261.interbusiness.it] has joined #gentoo

[17:49] tuxman: eh, ma ho proprio tempo da sbattermi, altrimenti!

[17:49] comunque

[17:49] provo a fare

[17:49] ghgh

[17:50] emerge firefox

[17:50] sii

[17:50] ma mi dice che non ci sono ebuilds per soddisfare la richiesta

[17:50] guarda se ti interessa ci sono pure gli eseguibili di firefox con emerge firefox-bin

[17:50] perchÃ¨

[17:50] sbagli nome

[17:50] ah perfetto

[17:50] in realtÃ

[17:50] Ã¨

[17:50] mozilla-firefox

[17:50] bene bene

[17:51] oppure mozilla-firefox-bin

[17:51] per i binari

[17:51] scegli tu

[17:51] comunque quando non trovi

[17:51] fai

[17:51] emerge -s firefox

[17:51] quindi se scarico i secondi sarÃ molto piÃ¹ veloce, no?

[17:51] (a installare)

[17:51] cosa il programma o a installare?

[17:51] si certo

[17:51] a installare sicuro

[17:51] Manuelix, come modifico i files?

[17:51] e per quanto riguarda la disinstallazione come si fa?

[17:51] emerge -C firefox

[17:51] _soujiro__, nano, vim, vi…ecc

[17:51] perchÃ¨ all’inizio ho scaricato gdm

[17:52] *mozilla-firefox

[17:52] lo vuoi togliere?

[17:52] perÃ² ho pensato che fosse eccessivo per fluxbox

[17:52] allora fai emerge -C gdm

[17:52] Manuelix, no intendevo cosa scrivo? i file di kernel devo scrive com’Ã¨ scritto dentro boot?

[17:52] cosÃ¬ ora uso xdm

[17:52] ok perfetto

[17:52] perÃ² ricordati che questo non toglie le diepndenze

[17:52] comunque sia non mi pare che gdm ne abbia poi tante

[17:52] vabbÃ¨ magari un giorno mi saranno utili

[17:52] ho un dubbio _soujiro__

[17:52] o puÃ² crearmi dei problemi?

[17:53] prova a dare ls /boot/ ora

[17:53] e posta

[17:53] ok

[17:53] ma guarda a me da solo 4 dipendenze

[17:53] comunque sia nessun problema

[17:53] perÃ² se vuoi toglierle

[17:53] dai

[17:53] emerge –depclean

[17:53] aspe

[17:53] scusa

[17:53] no

[17:53] Manuelix, tutto uguale

[17:53] emerge –depclean -p

[17:53] controlla cosa vuole togliere

[17:53] e poi decidi se madarlo o no

[17:54] fiuu…penso d’aver capito cosa intendevi

[17:54] okkio che puÃ² essere distruttivo

[17:54] controlla bene che non toglie cose che servono

[17:54] non sempre c’azzecca

[17:54] eh, ma non sono ancora in grado di distinguere cosa Ã¨ bene togliere da cosa non lo Ã¨

[17:54] quindi per ora rimane cosÃ¬

[17:54] guarda dai emerge -C gdb

[17:54] poi dai il depclean

[17:54] e dimmi

[17:54] cosa vuole fare

[17:54] tanto so pochissimi dipendenze

[17:54] _soujiro__, vai sull’handbook e rileggiti per bene dalla sezione dove si compila il kernel

[17:54] poi torni e chiedi

[17:54] non dovresti avere problemi

[17:54] io devo andare ora

[17:55] emerge -C gdm l’ho giÃ fatto

[17:55] ma credo che tu non abbia ben chiaro cosa hai fatto

[17:55] intendo compilazione del kernel

[17:55] ma dov’Ã¨ che mi dice le dipendenze?

[17:55] e copia del kernel in boot

[17:55] ma guarda

[17:55] ceccoggi: emerge -C non rimuove le dipendenze

[17:55] forse solo i link nel file del grub sono sbagliati

[17:56] ok infatti

[17:56] rimuovere le dipendenze in gentoo Ã¨ un po’ piÃ¹ complesso che con le altre distro

[17:56] perÃ² un salto sulla compilazione del kernel ce lo faccio

[17:57] *** sawk [~sawk@Azzurra=1E5521B2.cust.tele2.it] has quit [Ping timeout]

[17:57] si si ok

[17:57] nessuno che mi aiuta con la nvidia ?

[17:57] per questo per ora non faccio niente

[17:59] *** grasso [~grasso@Azzurra=2CADC5D0.37-151.net24.it] has joined #gentoo

[17:59] Manuelix, ho rivisto

[17:59] Manuelix, e mi diceva di cambiare link se non era come nell’esempio
[18:00] *** Fiz_OuT is now known as Fiz

[18:00] *** Fiz is now known as Fiz_OuT

[18:00] ceccoggi: ora le dipendenze le vedi con emerge –depclean -p

[18:00] il link credo si riferisca a linux che punta ai sorgenti

[18:00] Laiho: mi sembra strano che le prestazioni grafiche rilevate
da glxgears facciano così schifo, mi fa 1400 punti su una nvidia 6500

[18:00] si

[18:00] glxgears non conta come bench

[18:00] be molto diverso da quelli che hai detto tu

[18:00] perÃ² io avevo come da descrizione il link

[18:00] ceccoggi: scusami m’ero assentato un attimo

[18:00] quindi non ho cambiato

[18:00] ho sentito di uno in chat con una fx5500 che fa 4000 punti

[18:00] deve solo dirti se l’opengl funziona o no

[18:00] ceccoggi: sei riuscito?

[18:00] prova con un qualcosa di più decente

[18:00] tipo ?

[18:00] chessò, ut2004 demo

[18:00] ut ce l’ho ma non ho ancora trovato l’opzione per i frame

[18:01] -.-’0

[18:01] sto installando firefox

[18:01] c’è proprio un benchmark basato su ut2004

[18:01] e poi se non ho modo di comparare

[18:01] ah!

[18:01] vado in doccia a dopo

[18:01] si ma pare che comunque glxgears venga usato come software di beach

[18:01] volley

[18:01] bench*

[18:01] lol

[18:01] * Manuelix is away: puzzo quindi mi lavo!!!

[18:01] macché

[18:01] glxgears non va bene come bench

[18:02] un conto è se fai 8 fps

[18:02] ma se sei sopra i mille già il suo lavoro lo ha fatto

[18:02] eh ma tra 1600 punti e 4000 è una bella diff

[18:02] differenza che non conta

[18:02] la 6600gt che ho ora

[18:02] fa meno punti della 5900xt che avevo prima

[18:02] sarebbero ?

[18:02] eppure va almeno un 30% meglio

[18:02] ne facevo boh, 8000

[18:02] ma era iperoverclockata

[18:02] ora ne faccio 6000 non overclockata

[18:02] eppure va meglio

[18:03] Laiho: potrebbe essere la cpu che determina quel valore ?

[18:03] o almeno influisce

[18:04] mah

[18:04] non credo

[18:04] Shocker580, certo che influisce

[18:04] comunque sia, prova con qualche applicazione 3d

[18:04] doctorzoidberg: molto poco

[18:04] ho notato che mi succhia il 50%

[18:04] su glxgears poi

[18:04] io sul portatile quando faccio scalare la frequenza, mi ammazza il framerate

[18:04] framerate su glxgears ?

[18:04] e continua a dimostrarsi che non vale nulla come bench video

[18:05] Laiho io credo che per le applicazioni 3d la cpu abbia un valore molto
importante, sul portatile ho un prescott 3.4 con una x600 e con nfs ms riesoc a giocarci al massimo

[18:05] sul fisso, celeron 2.8 nvidia 6500 il gioco va molto molto peggio

[18:05] eppure la scheda video è molto più potente

[18:05] Shocker580: un conto è un pc che fa da collo di bottiglia

[18:05] ehm

[18:05] una CPU

[18:05] un conto è una CPU che pur bastando abbondantemente

[18:06] addirittura da collo di bottiglia ?

[18:06] fa calare le prestazioni

[18:06] effettivamente è un celeron

[18:06] se fai girare doom3 con due 7800 in sli e poi hai un celeron 1000

[18:06] ci credo che conta

[18:06] ma glxgears non può essere influenzato dalla cpu

[18:07] quindi di loro, senza alcuna impostazione particolare i moduli nvidia già sfruttano al max ?

[18:07] boh

[18:07] ti ho detto

[18:07] prova con un qualcosa di serio

[18:07] installo ut2004 ..

[18:07] anzi, qui ce l’ho già installato, cerco il framerate

[18:07] perché l’opzione non mi pare di averla vista

[18:07] ma vedi intanto come va

[18:07] va be ad occhio non me ne rendo conto

[18:08] se va bene vuol dir che non hai problemi

[18:08] sul fisso ho un 1600 su quello 1400

[18:08] la diff non credo si veda ad occhio

[18:08] la differenza/

[18:08] *

[18:08] ma io non parlo di differenza

[18:08] per fisso intendo la fx5600

[18:08] ti dico per capire se è tutto ok oppure no

[18:08] no ?

[18:08] ah ok

[18:14] *** SoNy [SoNy@Azzurra-5BD2AE2E.241-36.fastweb.fw] has joined #gentoo

[18:15] il client da riga di comando ftp in che pacchetto si trova ?
usare sftp per fare questi spostamenti è terrificante mi ci sta mettendo 10 minuti x 4 gb -.-

[18:15] per*

[18:17] e voi sapete come avere xchat scuro invece di sto cavolo di bianco fastidioso? o_O

[18:18] sl0w: compila irssi ;P

[18:18] sl0w: hai dato un occhiata alle impostazioni?

[18:18] lan, xchat Ã¨ xchat irssi Ã¨ irssi >_

3 Comments »

RSS feed for comments on this post. TrackBack URI

Just checking in. I never installed blog software and need to for my theme on disaster recovery.Can you have multiple blogs on what domain? Is that feasible?. Thank you very much, COURTNEY disaster recovery planning long island

Comment by remote disaster recovery — February 3, 2006 #

Reply
lose weight fast

Comment by Fat Weignt Loss — November 13, 2006 #

Reply
Hi! Very nice site! Thanks you very much! oQSiAeg8lG8J

Comment by FEjWpKAM0L — January 11, 2007 #

Reply

Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.

cybercinema