It was with much pleasure that I received this mail, Ken!
Em 20-06-2012 18:25, Ken Moffat escreveu:
> On Wed, Jun 20, 2012 at 01:07:17PM -0700, Fernando de Oliveira wrote:
>> Em 19-06-2012 23:29, Ken Moffat escreveu:
>>
>> But to keep it technical, until this Xorg release thanks to DJ, we have
>> been behind the edge in Xorg. This is a fact, if you need, I can produce
>> some release dates for xorg-server in other distros.
>
> But do you see any identifiable benefits from newer packages (apart
> from fixing the cairo issues in some of the video drivers) ?
>>
>>> And who has the time to do this ?
>>
>> It takes not longer than gnome or kde, but I agree it takes longer than
>> firefox, for example.
>>
>
> So, you agree it takes a significant amount of time.
Yes, but much less than for a complete Xorg upgrade as is done presently.
>
>> But it does not take that long. Just replace the packages individually,
>> as they are released. Just as with other packages. That is the way I do:
>> I see a new server version is out, so I go to Xorg.org, search which
>> packages are newer than the installed ones, and replace in the wget and
>> md5 lists and individual packages. As I did before, I can provide them
>> to this list.
>>
> And then, at least if the package is individual, check for new
> options and measure its time and space. And for preference always
> *use* it [ no need to rebuild anything that hasn't changed, unless
> it uses headers from this package ].
Agree. My scripts always measure time and space. As they are for me, not
for the book, only increase size after removing older and installing
newer is given, but it is simple, I think, to modify this. Build dir
size is correct.
> Actually, *using* the important packages is also a limiting factor
> for the drivers. I'm still subscribed to a nouveau list (in case I
> have another go at trying to build on my ppc64), and I see a lot of
> reports of breakage, but I've no idea how common or serious they
> are, so no idea if a random checkout is likely to work. For my own
> hardware I can at least say "well, it works for me" or, occasionally
> "I've got a problem here, not sure if it is ready for the book".
>
>>> *if* you can get out of your
>>> virtual machines and run BLFS on real hardware, I would be fairly
>>> happy about suggesting you get privileges. Meanwhile, there is more
>>> than enough to do :)
>>>
>>> ĸen
?
>>>
>>
>> Perhaps you do not know, but not only I *can*, but already have done
>> that. You can find reference to this fact in the archives.
>>
>> This is sen rom my hp lfs6.7
>>
>
> OK, I thought you had said that you were running in VMs until you
> were willing to give up on your host system. My mistake.
>
> 6.7 is now so old that it isn't useful for editors :-(
Actually, that machine is a living-dead thing, I gave to someone when
still worked almost alwaysys, and it was returned after dead for
Windows. It can run Lubuntu, but is not stable. Took nme several days to
upgrade to Lubuntu 12.04-LTS. I could make it work for some moments
yesterday in LFS6.7"svn", just to send that message. I should send it
for service, as i think it is just the fan that stopped working.
After reading your kind reply, this morning, I felt encouraged to
implement LFS7.1 "svn" in my newer machine. Having had success (small
things, some perhaps difficult, still missing).
The following data is obtained on this new system (where I am writing this):
$ lspci | grep -i nvidia
01:00.0 VGA compatible controller: nVidia Corporation GT215 [GeForce GT 240]
(rev a2)
01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev
a1)
$ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
model name : Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz
$ free -tm
total used free shared buffers cached
Mem: 3997 1327 2669 0 41 66
-/+ buffers/cache: 718 3278
Swap: 4102 0 4102
Total: 8099 1327 6772
I don't understand this memory results, as I have in Conky:
RAM usage: 718MiB/3.90GiB
and in GKrellM:
3997M - 688M usado [used]
I still do not have 3D acceleration (?), but have direct rendering:
$ grep DRI2 /var/log/Xorg.0.log
[ 280.135] (II) Loading extension DRI2
[ 281.748] (II) NVIDIA(0): [DRI2] Setup complete
[ 281.748] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia
$ glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: GeForce GT 240/PCIe/SSE2
$ glxinfo | grep rendering
direct rendering: Yes
GL_NV_parameter_buffer_object2, GL_NV_path_rendering,
>
>> Subjacent to your sentence there seems to be an assumption that people
>> use *FS in VM because they are not capable of doing it in the "real"
>> machine". I quite think the opposite is true. People not capable of
>> using VM, goes on with something they find more "real", less abstract.
>>
>
> I know that VMs are in some ways harder. But those of us running
> on real hardware have shown our commitment to use our own 'product'.
Even agree with this sentence, with a small modification:
"But those of us running on our real or virtual 'hardware' have shown
our commitment to use our own 'product'". :-).
> In the LFS area, I know that VMs can be very different. I will
> accept that not much is different in the BLFS area, if that is what
> you tell me.
Ok.
[...]
>>
>> I [...] like your posts very much [...]
>>
>
> Thank you. My overriding point on this is that we are *all* short
> of time. You suggested something, with frequent updates, which I
> think will use a lot of editorial time whenever there are significant
> numbers of packages released by xorg. I'm still doubtful that many
> of the updates will be beneficial to us (looking at release
> announcements, often the fixes are for non-linux systems).
Yes, but for almost all other BLFS, it does not matter, just upgrade
them. I remember that this was not the case of Gimp. Other than that, I
feel it is simpler than a major upgrade.
> I see that DJ is suggesting something slightly different.
BTW, I read his post, but have to do it again, to better understand - DJ
is a very dense writer :-), before trying to reply. So, I am not sure if
what I am writing here is in contradiction with his suggestion.
> Your
> suggestions are often useful, but in your post you proposed that
> other people use their own time to update things which they have not,
> so far, felt to be their top priority. Now do you see why I
> suggested that you might be a good person to tackle this, since you
> care about it ?
>
> ĸen
>
I would like to try an accord with you and, of course, DJ. Next time,
instead of just reporting I upgraded Xorg, I will do in more detail,
with times, sizes, and you tell me what should I do or redo, in order
for it to be accepted as a commitment to the book. If everything goes
right, I will ask you and your pairs privileges to commit it and be
responsible for minor Xorg upgrades (not major ones).
Pleased to have received so kind a reply from you,
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
