Arthur Hagen wrote:

> singsingchow <singsingchow@gmail.com> wrote:
>
>> It's 2008 now.
>
> I'm sure they'll let you know in the GWN (Gentoo Weekly Newsletter)...

I'm afraid there hasn't been any GWN anymore since October 15th 2007, nor
has the news section of the Gentoo website been updated since. :-/

P.S.: Happy New Year to all! :-)

--
Aragorn

On 2008-01-02, Aragorn <aragorn@chatfactory.invalid> wrote:
> Arthur Hagen wrote:
>
>> singsingchow <singsingchow@gmail.com> wrote:
>>
>>> It's 2008 now.
>>
>> I'm sure they'll let you know in the GWN (Gentoo Weekly
>> Newsletter)...
>
> I'm afraid there hasn't been any GWN anymore since October
> 15th 2007,

Once again, sarcasm on Usenet proves fails.

--
Grant Edwards grante Yow! AIEEEEE! I am having
at an UNDULATING EXPERIENCE!
visi.com

J.O. Aho <user@example.net> wrote:
> Aragorn wrote:
>
>> I did indeed find this inactivity worrying, particularly as I'm
>> about to install a machine worth USD $~20'000/€~16'000 with Gentoo,
>> spread out as individually customized installations in virtual
>> machines on top of the Xen hypervisor (including the /dom0/ virtual
>> machine)...
>
> You should be able to switch to Sabayon with a little work, in case
> Gentoo would come to an end.

Doesn't Sabayon build on, and thus require, Gentoo? If so, if Gentoo dies,
won't Sabayon die too?

I tried it quickly, but gave up due to the dark colour scheme infusing
everything, which is especially bad on a screen with a high gamma value (low
gamma correction value). Completely unusable for business use, where
legibility is paramount. Fiddling with all the settings myself to get
everything to become legible would have been possible, but the maintainers
have already proven ineptness by not understanding how contrast issues
affect people and affect them differently.

Regards,
--
*Art

Aragorn wrote:
> J.O. Aho wrote:
>> Aragorn wrote:

>>> Still, the packages for the "stable" repositories all still seem to be
>>> maintained up to a pretty actual level, and the forum does still see its
>>> usual load of GLSA posts. On the other hand however, the Live CD I've
>>> downloaded not too long ago still has an older kernel on it - 2.6.18, I
>>> think - so apparently it's been a while again since they've updated those
>>> images.
>> They don't make new image on each released kernel, and it's not needed, it
>> requires a lot to make a machine not to boot the .18 kernel.
>
> No, I didn't mean to imply that they did, but I was under the impression
> however that they updated the installation media on a regular basis, not
> because of the kernel but maybe because of some other things like a bugfix

They do if there is a severe bug, think they did that for the amd64 release
last year.


> - the AMD64 Live CD I have for instance goes haywire on my two different
> videocards[1] - and then this would automatically include a newer kernel,
> or so I imagine.
> [1] I've got two videocards in the new machine I spoke of earlier. One is a
> brandnew Asus GeForce 8800 GTS PCIe card with 640 MB of memory, which will
> be driving my two SGI 21" monitors for X11 in an unprivileged Xen domain.

Use the VESA driver during install of the Gentoo and then install the nVidia
driver when all is finished. In your case it may be better to just use the
VESA until nVidia has released a Xen compatible driver.



> I don't need those on the installation media themselves, of course. I am
> however currently still waiting until the official release of 2.6.24, as
> that kernel has several new features that I really want - the new
> scheduler, for one - and I don't plan on compiling a kernel now and
> configuring/compiling one again in one or two weeks.

It's rc6 at the moment, so it should come out soon, and you need only to
configure it once even if you try out the rc6 first, as all you need to do is
to copy the .config to the final version and run "make oldconfig".

Can even be so that all the changes between rc6 and final version will be for
other architectures than yours, then it won't make any difference for you irf
you run a rc or final. But of course if there will be a load of x86/amd64
changes in last minute, then it may feel a bit dumb, but the amd64 should
compile things quite fast, at least mine does.


--

//Aho

De Vliegende Hollander wrote:

> The sentient life form Aragorn posted the following:
>
>> Arthur Hagen wrote:
>>
>>> singsingchow <singsingchow@gmail.com> wrote:
>>>
>>>> It's 2008 now.
>>>
>>> I'm sure they'll let you know in the GWN (Gentoo Weekly Newsletter)...
>>
>> I'm afraid there hasn't been any GWN anymore since October 15th 2007, nor
>> has the news section of the Gentoo website been updated since. :-/
>
> Worrying that is! Hope not a prelude to 'The End Of Gentoo' ®, this is...

Have no worries mate...

Even if the impossible happens and Gentoo completely disappears from the
face of the earth... there's a veritable host of other distributions to
pick from. The one that would probably be the next step from Gentoo is LFS.
I've worked with it before and liked it a lot. If not for Gentoo, I would be
an LFS supporter. Much like Gentoo, LFS has it's derivatives to... it has
an embedded group, hardend group, and automated install group and one that
proposes a way to "polish off" your new LFS install.

Change is always hard to accept, but Life and Linux goes on.

--

Jerry McBride (jmcbride@mail-on.us)

J.O. Aho wrote:

> Aragorn wrote:
>
>> [...] - the AMD64 Live CD I have for instance goes haywire on my two
>> different videocards[1] - and then this would automatically include a
>> newer kernel, or so I imagine.
>>
>> [1] I've got two videocards in the new machine I spoke of earlier. One
>> is a brandnew Asus GeForce 8800 GTS PCIe card with 640 MB of memory,
>> which will be driving my two SGI 21" monitors for X11 in an unprivileged
>> Xen domain.
>
> Use the VESA driver during install of the Gentoo and then install the
> nVidia driver when all is finished. In your case it may be better to just
> use the VESA until nVidia has released a Xen compatible driver.

Sure, I have no problems installing the system via the character mode
commandline console, as I stated earlier. It's just that the Live CD
attempted to start up X11 - which I had not expected it to do - and then
went a little crazy on the fact that there is a PCI Radeon card (which
always takes precedence as the primary videocard) and a PCIe GeForce card.

It attempted to load the nVidia driver, or so the error messages said, and
then it b0rk3d on loading the GLX module. I still need to properly connect
that machine to the internet hardwarewise, so my attempt to boot from the
Live CD was just a test, not an actual installation attempt.

As for nVidia releasing a Xen-compatible driver - or let us have a wild
dream for a moment: having them open up their source code - that is not
going to happen. The best they will do is offer a driver that no longer
needs to be patched in order to run it inside a GNU/Linux system in a
Xen /dom0./

For those not familiar with Xen, /dom0/ is the management virtual machine,
i.e. the operating system started on top of the Xen hypervisor at
(hardware) boot time, and from which other virtual machines are created,
started, stopped, paused and saved. /dom0/ has direct access to the
hardware via special drivers. The other virtual machines are called /domU/
(the unprivileged domain) and in this environment, the kernels of the
respective operating systems use only front-end drivers, which access the
hardware via the back-end drivers in the /dom0/ kernel.

At least, that's how it works for paravirtualization. Xen also supports
hardware virtualization on Intel CPUs with Vanderpool technology (VT) or
AMD CPUs with Pacifica technology (SVM), in which case the "guest"
operating systems in a /domU/ can make use of their native drivers.

As I wrote above, nVidia's latest driver now no longer requires patching for
it to be able to work inside a /dom0/ Linux kernel - it previously required
patching because the presence of Xen in memory broke the driver's ability
to access the videocard's physical address space correctly. Allegedly - or
so one of the nVidia developers wrote on a forum, passing "IGNORE_XEN" as a
parameter to the building of the driver's kernel interface code should fix
this.

However - and despite the rather popular tendency to run X11 in /dom0/ - the
nVidia driver still does not have access to the adapter's 3D hardware
acceleration from within an unprivileged virtual machine. Hence my need to
hide the adapter from /dom0,/ which will then subsequently make the
adapter's hardware directly available to /domU./

On account of running X11 inside /dom0/ - again, however popular it may be -
this totally defeats the purpose of running Xen at all, in my humble
opinion. /dom0/ has access to the memory of each /domU/ and we all know
that (especially proprietary) video drivers are the number one cause for
stability problems in the Linux kernel.

The idea behind Xen is that you can shield off the less stable environments
from the normally stable ones, so that mission-critical virtual machines
can remain uncompromised. Ergo, if you run X11 inside /dom0/ and you run a
few servers in unprivileged virtual machines, then an eventual crash or
need to reboot in /dom0/ will compromise all those other servers as well.
Running X11, especially with a proprietary video driver, inside /dom0/ is
like doing your daily work as root, i.e. that's a definite Don't_Do_That
(TM). ;-)

>> I don't need those on the installation media themselves, of course. I am
>> however currently still waiting until the official release of 2.6.24, as
>> that kernel has several new features that I really want - the new
>> scheduler, for one - and I don't plan on compiling a kernel now and
>> configuring/compiling one again in one or two weeks.
>
> It's rc6 at the moment, so it should come out soon, and you need only to
> configure it once even if you try out the rc6 first, as all you need to do
> is to copy the .config to the final version and run "make oldconfig".

If they don't shuffle around configuration options anymore in the meantime,
that is... :-/ Typically, when Linus announces a feature freeze, everyone
will be squeezing in last-minute feature patches again... :-/

> Can even be so that all the changes between rc6 and final version will be
> for other architectures than yours, then it won't make any difference for
> you irf you run a rc or final.

Could be, but life has taught me not to be so optimistic... ;-)

> But of course if there will be a load of x86/amd64 changes in last minute,
> then it may feel a bit dumb, but the amd64 should compile things quite
> fast, at least mine does.

Well, it's a twin socket (ccNUMA) dualcore Opteron 2218 HE (2.6 GHz), with a
SAS RAID 5 and 32 GB of pc5300 DDR-2 memory - with maximum ECC protection,
so that'll slow it down a bit - so it should indeed be fast enough, but I
have a habit of going over each and every kernel configuration option
integrally upon each configure, and this takes up far more time than the
actual compile. :-)

And then of course, as I said, I will be custom-configuring each virtual
machine's designated kernel and installation. For instance, there's no
need to have 32-bit (multilib) support in a 64-bit-only server environment,
but my X11 environment will need 32-bit support. I'm also still
contemplating the hardening stuff like RBAC and/or PAX.

In addition, I have very little knowledge of iptables and routing, and I'll
have to set up everything using a custom routing table, as I'll only have
one public IP address, but all virtual machines should have access to the
internet. For /dom0,/ this only need be /ssh/ access, but I might set up
a /ssh/ DMZ inside one of the other virtual machines, so that one
must /ssh/ into that virtual machine first and then from there /ssh/ into
the /dom0./ This is probably the wisest solution. ;-)

Oh, and I have lots of other precautions in mind as well. For starters, I
intend to run every virtual machine with a read-only root filesystem during
normal system operation. Other filesystems will be read-only as well - but
I've already been using that set-up for many years now - and some
filesystems will be shared over the network via NFS, "the network" being
not just the virtual machines but also the LAN for which this new machine
will be the gateway.

Lots of work to do...

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:
> J.O. Aho wrote:
>> Aragorn wrote:

>> Use the VESA driver during install of the Gentoo and then install the
>> nVidia driver when all is finished. In your case it may be better to just
>> use the VESA until nVidia has released a Xen compatible driver.
> It's just that the Live CD
> attempted to start up X11 - which I had not expected it to do - and then
> went a little crazy on the fact that there is a PCI Radeon card (which
> always takes precedence as the primary videocard) and a PCIe GeForce card.

At least on older machines you could set the primary graphics card in the
BIOS, wouldn't surprise me if there is a PCIe/PCI option in your BIOS.


> As for nVidia releasing a Xen-compatible driver - or let us have a wild
> dream for a moment: having them open up their source code - that is not
> going to happen. The best they will do is offer a driver that no longer
> needs to be patched in order to run it inside a GNU/Linux system in a
> Xen /dom0./

No, they will not open up the source and the majority of distros won't have it
as a default driver due the license.


> In addition, I have very little knowledge of iptables and routing, and I'll
> have to set up everything using a custom routing table, as I'll only have
> one public IP address, but all virtual machines should have access to the
> internet. For /dom0,/ this only need be /ssh/ access, but I might set up
> a /ssh/ DMZ inside one of the other virtual machines, so that one
> must /ssh/ into that virtual machine first and then from there /ssh/ into
> the /dom0./ This is probably the wisest solution. ;-)

I did setup Xen on a test machine running CentOS, had no need of configuring
iptables rules to access internet with domU. Of course if you want to protect
ports, you have to do something. I would have recommended you to take a look
at FireStarter, but it hasn't been maintained for a while and has some
troubles with later kernels and gnome2 libs.

One of the disadvantages I see is the high load on the domU while making disk
access, even if you have dedicated slices for them. I have been thinking of
testing KVM instead and see if it's kinder on the load or not, but been too
busy with other things.

--

//Aho

On Jan 6, 5:16 am, "J.O. Aho" <u...@example.net> wrote:
> Aragorn wrote:
>
> //Aho
Cartwright or as you know him (Aho) has been trying to shut down a
good google group.
http://groups.google.com/group/alt.callahans/about
http://groups.google.com/group/alt.c...dfa0fbeb950cb4
http://groups.google.com/group/alt.c...8d386873c74bb9
http://groups.google.com/group/alt.c...d2a4f59c86cc9d

He has been doing this by posting what looks to be replies to adult
content material, but in doing so he is one of the leading posters of
adult content material to this usually nice group. The material
replied to does not originate in our group and may be made up by him.
He has also been known to post replies to his replies in ways that
just dump more crud on the newsgroup.
http://groups.google.com/group/alt.c...74c23845ee285f
http://groups.google.com/group/alt.c...63749c641bf90a
http://groups.google.com/group/alt.c...8e75117487deed


Please do something, even if you just kill file him, to this troll.

Now I may have this poster mixed up with him, as he seems to use
Brandon D Cartwright on alt.callahans and Aho here. But I followed the
Google past post link and this poster has an identical post history as
the despised Cartright

He does limit his posts to 6 or fewer days. Those posts up there are
likely to be gone soon. But just go to alt.callahans and search
cartwright, something will come up and that person will have the same
posting history as Aho.

Sean Cleary wrote:

> Cartwright or as you know him (Aho) has been trying to shut down a
> good google group.
> http://groups.google.com/group/alt.callahans/about
>
> [...]
> He has been doing this by posting what looks to be replies to adult
> content material, but in doing so he is one of the leading posters of
> adult content material to this usually nice group. The material
> replied to does not originate in our group and may be made up by him.
> He has also been known to post replies to his replies in ways that
> just dump more crud on the newsgroup.

Forgive my scepticism, but I'm not new to this newsgroup, even though it has
been a long time since I've posted anything here, prior to my first reply
in this thread here, and so I'm familiar with the posting history (on this
group) of most of the regulars here.

As such, I have found no foul whatsoever in any posts made by J.O. Aho. On
the contrary, he seems to be a very helpful and polite person. ;-)

> [...]
> Please do something, even if you just kill file him, to this troll.
>
> Now I may have this poster mixed up with him, as he seems to use
> Brandon D Cartwright on alt.callahans and Aho here. But I followed the
> Google past post link and this poster has an identical post history as
> the despised Cartright

A posting history does not mean anything on an internet with hundreds of
millions of users. I've been the subject of mistaken identity myself as
well a few times, simply because of my habit of posting long articles,
which were - as it just so happened to be - pro-GNU/Linux articles in
comp.os.linux.advocacy, the group that the person with whom I was confused
was also posting GNU/Linux advocacy to.

I believe this is a clear case of mistaken identity.

> He does limit his posts to 6 or fewer days. Those posts up there are
> likely to be gone soon. But just go to alt.callahans and search
> cartwright, something will come up and that person will have the same
> posting history as Aho.

Again, this does not prove anything. Besides, you seem to be unaware that
Usenet is not the same thing as Google Groups - but then again, that
applies to most Google Groups users.

Google offers you an archive of and posting method to Usenet, but this is
not some forum, and if you were to use a real newsreader rather than a
browser, then you would be able to see the message IDs and hostname or IP
address of the poster - Google Groups hides these from you. These tags
would give you a much clearer indication of where a poster is from or
whether two posters going by a different name are really one and the same
person.

Hope this helps... ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Sean Cleary wrote:
> On Jan 6, 5:16 am, "J.O. Aho" <u...@example.net> wrote:
>> Aragorn wrote:
>>
>> //Aho
> Cartwright or as you know him (Aho) has been trying to shut down a
> good google group.

Please, before you start to accuse people, do better research and you will
notice that there are more than one person using user@example.net/.com. The
person whom you accuse me to be uses "no cache" header, so that his posts will
be deleted after a while from the NNTP, you don't find this on my posts.

Please cancel all your posts where you accuse me to be someone whom I'm not.


--

//Aho