Ping CentOS users
Mike Jones
Anybody using CentOS?
--
*===( http://www.400monkeys.com/God/
*===( http://principiadiscordia.com/
*===( http://www.slackware.com/
J.O. Aho
> Anybody using CentOS?
Not privatly, but at work we use CentOS on some of our Dell
servers/blades. At the moment it's quite outdated, we are waiting for
CentOS 5.4 which will bring a more up to date kernel and KVM.
CentOS ain't anything I would recommend for desktop use, you want
something which is more up to date and not as on the edge as Fedora (of
course much of the stuff you find in Fedora will one day end up in RHEL
and thous into CentOS too).
--
//Aho
Aragorn
as J.O. Aho wrote...
More or less the same scenario here. We're currently running CentOS 5.3
on our servers, but I'm not really a fan of it - nor of Fedora or
RedHat for that matter, due to their installer refusing to support any
other types filesystems than ext2, ext3 or ext4 for installation of the
system itself. It - i.e. the installer - doesn't allow you to create
any reiserfs, XFS or JFS partitions or mount them anywhere in the tree
if they already exist.
For a workstation installation, I would rather recommend Mandriva or any
of its spinoffs - although PCLinuxOS is rather conceived as a
typical "home desktop"-kind of system by default - or maybe (Open)SuSE
or Sabayon, which is Gentoo-based. For the more experienced user, I
would perhaps suggest Gentoo itself, Slackware - provided that you're
happy settling with a 32-bit only operating system - or Debian.
CentOS is pretty stable and reliable for server use, and that's why my
colleagues prefered it, and why I consented to using it on our servers,
but it's definitely not quite what you would want for a workstation.
--
*Aragorn*
(registered GNU/Linux user #223157)
trse...@start.no
> On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
Slackware comes in both 32-bit and 64-bit flavour now.
Mike Jones
I'm actually a huge fan (and user) of Slackware (note the sigline).
However, I'm just playing around with a few distros, trying to see if
there is anything easier to install'n'use than my prototype SlackMods.sh
customising package for Slackware. I think, based on my fun'n'games with
CentOS so far, and as CentOS was the last-to-check in my list of non-
Slackware OSs, I'll finish polishing up my SlackMods package.
Thanks for the info you guys. Cheers.
Kevin Collins
> Responding to trselmer:
>
>> Aragorn wrote:
>>> On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody
>>> identifying as J.O. Aho wrote...
>>>
>>> Slackware - provided that you're happy settling with a 32-bit only
>>> operating system.
>>
>> Slackware comes in both 32-bit and 64-bit flavour now.
>
>
> I'm actually a huge fan (and user) of Slackware (note the sigline).
> However, I'm just playing around with a few distros, trying to see if
> there is anything easier to install'n'use than my prototype SlackMods.sh
> customising package for Slackware. I think, based on my fun'n'games with
> CentOS so far, and as CentOS was the last-to-check in my list of non-
> Slackware OSs, I'll finish polishing up my SlackMods package.
>
> Thanks for the info you guys. Cheers.
Just a note from the other point of view: I do use CentOS at home, and RHEL at
work. I *like* the shelf-life of CentOS compared to Fedora and I am running a
server at home that manages mail, dhcp, bind, web, etc for the home computers.
Because of that, I don't want to be upgrading every 6-12 months...
Kevin
J.O. Aho
> On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <us...@example.net>
> wrote:
>
>> On Wed, 21 Oct 2009, Mike Jones wrote:
>>
>>> Anybody using CentOS?
>> Not privatly, but at work we use CentOS on some of our Dell
>> servers/blades. At the moment it's quite outdated, we are waiting for
>> CentOS 5.4 which will bring a more up to date kernel and KVM.
>>
>
>
> http://lists.centos.org/pipermail/centos-announce/2009-October/016195.html
>
We got really disappointed, no kernel 2.6.27 with xen dom0 support, and Xen
3.0.3... this forces us to build own RPMs to be able to run BSD based VMs.
KVM just 0.83...
--
//Aho
Mike Jones
Thats one of the things I like about Slackware. You don't need to be
doing that constant upgrade thing. Just slap in the odd security patch
when they come up for critical things, which isn't often.
Aragorn
as J.O. Aho wrote...
> dreaded wrote:
>
>> On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <us...@example.net>
>> wrote:
>>
>>> On Wed, 21 Oct 2009, Mike Jones wrote:
>>>
>>>> Anybody using CentOS?
>>>
>>> Not privatly, but at work we use CentOS on some of our Dell
>>> servers/blades. At the moment it's quite outdated, we are waiting
>>> for CentOS 5.4 which will bring a more up to date kernel and KVM.
>>
>> Wait no more!!
>>
>> [long URL]
>
> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
> and Xen 3.0.3... this forces us to build own RPMs to be able to run
> BSD based VMs. KVM just 0.83...
Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also a
RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0 - so
my advice for Xen would be to wait until either the distribution
carries a 2.6.30 or later kernel, or else - which is what I recommend -
build a 2.6.30 or newer kernel with dom0 support from sources. And
while you're at it, get Xen 3.3 from xen.org directly - it comes as
either sources or as an .rpm or .deb package.
Desktop-oriented distributions typically mess up a lot by means of the
additional "enhancement" patches they apply to the vanilla kernel -
this is something you will not see with CentOS or Slackware - which may
and often do introduce instabilities in the kernel, making it less
suitable for use on a server. [1]
This is one of the reasons why I prefer building a kernel from the
vanilla sources, and in this particular case, you would have a kernel
that supports all of your hardware and that can be used as a Xen dom0 -
2.6.18 is stable but is really outdated with regard to hardware
support.
YMMV... :-)
[1] By the same token, I also hate stuff like /hald/ and the whole
automounting of storage devices. In my humble opinion - or maybe
not so humble in this particular case - that stuff is just more
Windows'ism creeping into GNU/Linux.
Grant
...
>Desktop-oriented distributions typically mess up a lot by means of the
>additional "enhancement" patches they apply to the vanilla kernel -
>this is something you will not see with CentOS or Slackware - which may
>and often do introduce instabilities in the kernel, making it less
>suitable for use on a server. [1]
>
>This is one of the reasons why I prefer building a kernel from the
>vanilla sources, and in this particular case, you would have a kernel
>that supports all of your hardware and that can be used as a Xen dom0 -
>2.6.18 is stable but is really outdated with regard to hardware
>support.
First thing I do after an install is create the custom kernel to suit
the hardware -- been working well for me for a dozen years :)
>
>YMMV... :-)
So true -- one has to put in a little more effort to get what one
wants out of linux. I've been happy with slackware since 9.0, before
that I stayed with redhat 6.2 for some years, skipping the worsening
7, 8 and 9 series, and disappointed by fedora.
>
>
>[1] By the same token, I also hate stuff like /hald/ and the whole
> automounting of storage devices. In my humble opinion - or maybe
> not so humble in this particular case - that stuff is just more
> Windows'ism creeping into GNU/Linux.
Automounting can be turned off in custom kernel. I don't have too
many portable devices to care about anyway. Happy to see USB sticks
and my cameras as mass storage, manually mounted.
Grant.
--
http://bugsplatter.id.au
Aragorn
as Grant wrote...
Well, insofar as I know, automounting is not a kernel issue - there are
some implementations of automounting in the kernel for networked
filesystems on servers which may not always be available, but this is
generally not the approach used for removable storage devices - but
rather a /udev/ and /hald/ issue.
For my "project" - I might as well call it that, since it pertains to a
machine that still requires hardware that still needs to be delivered,
et al; long and frustrating story... - I am contemplating read-only
root filesystems - it'll be a Xen machine - and for that I would
need /udev./ However, I would be more than happy to do without /udev/
altogether if I could get away with it.
Hmm... <brain at work> Maybe I could create a minimal number of static
device nodes in the */dev* directory on the root filesystem for when
the system boots up and then have the root filesystem mounted
read-only, with an additional on-disk device filesystem mounted on
*/dev,* similar to how /udev/ does it, but without the "conditional"
nature of the existence of the device special files...
Hmm... Intriguing thought... :-)
Grant
>On Thursday 22 October 2009 12:50 in alt.os.linux, somebody identifying
>as Grant wrote...
>
>> On Thu, 22 Oct 2009 12:34:08 +0200, Aragorn
>> <ara...@chatfactory.invalid> wrote:
>>
>>> [1] By the same token, I also hate stuff like /hald/ and the whole
>>> automounting of storage devices. In my humble opinion - or maybe
>>> not so humble in this particular case - that stuff is just more
>>> Windows'ism creeping into GNU/Linux.
>>
>> Automounting can be turned off in custom kernel. I don't have too
>> many portable devices to care about anyway. Happy to see USB sticks
>> and my cameras as mass storage, manually mounted.
>
>Well, insofar as I know, automounting is not a kernel issue - there are
>some implementations of automounting in the kernel for networked
>filesystems on servers which may not always be available, but this is
>generally not the approach used for removable storage devices - but
>rather a /udev/ and /hald/ issue.
>
>For my "project" - I might as well call it that, since it pertains to a
>machine that still requires hardware that still needs to be delivered,
>et al; long and frustrating story... - I am contemplating read-only
>root filesystems - it'll be a Xen machine - and for that I would
>need /udev./ However, I would be more than happy to do without /udev/
>altogether if I could get away with it.
I think you still can, turn off udev and populate /dev with the nodes
you need and do the 'classic' /etc/fstab partition mount control.
You might intercept the kernel's callouts to /sbin/(i forget name of
handlers) for udev and hald too.
>
>Hmm... <brain at work> Maybe I could create a minimal number of static
>device nodes in the */dev* directory on the root filesystem for when
>the system boots up and then have the root filesystem mounted
>read-only, with an additional on-disk device filesystem mounted on
>*/dev,* similar to how /udev/ does it, but without the "conditional"
>nature of the existence of the device special files...
Yes. The older methods are still available, perhaps look at the
kernel's embedded options to turn off some of the desktop support
'smarts'?
Grant.
--
http://bugsplatter.id.au
J.O. Aho
> On Thursday 22 October 2009 06:27 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
>> dreaded wrote:
>>
>>> On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <us...@example.net>
>>> wrote:
>>>
>>>> On Wed, 21 Oct 2009, Mike Jones wrote:
>>>>
>>>>> Anybody using CentOS?
>>>> Not privatly, but at work we use CentOS on some of our Dell
>>>> servers/blades. At the moment it's quite outdated, we are waiting
>>>> for CentOS 5.4 which will bring a more up to date kernel and KVM.
>>> Wait no more!!
>>>
>>> [long URL]
>> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
>> and Xen 3.0.3... this forces us to build own RPMs to be able to run
>> BSD based VMs. KVM just 0.83...
>
> Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
> the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also a
> RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0 - so
> my advice for Xen would be to wait until either the distribution
As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the 2.6.30
had been nice, but don't have time to maintain a kernel RPMs myself and I
wouldn't be surprised that RHEL/CentOS 5.x will be forever stuck with the 2.6.18.
> carries a 2.6.30 or later kernel, or else - which is what I recommend -
> build a 2.6.30 or newer kernel with dom0 support from sources. And
> while you're at it, get Xen 3.3 from xen.org directly - it comes as
> either sources or as an .rpm or .deb package.
As depending on 3rd party application to run on the dom0, can't just install
what ever I would like, or else they won't care with as much support as they
do today and I think I would have gone with 3.4 instead, better to run bsd domu.
> Desktop-oriented distributions typically mess up a lot by means of the
> additional "enhancement" patches they apply to the vanilla kernel -
> this is something you will not see with CentOS or Slackware - which may
> and often do introduce instabilities in the kernel, making it less
> suitable for use on a server. [1]
RHEL/CentOS glibc depending on gd, which in it's turn depends partly on
X-libs. There are tons of applications I don't think should be installed on a
server and CentOS does that, even starting with suggesting that you should
installed over bloated gnome2.
> This is one of the reasons why I prefer building a kernel from the
> vanilla sources, and in this particular case, you would have a kernel
> that supports all of your hardware and that can be used as a Xen dom0 -
> 2.6.18 is stable but is really outdated with regard to hardware
> support.
We experienced real instability and random crashes and reboots with Dom0 using
iscsi.
> [1] By the same token, I also hate stuff like /hald/ and the whole
> automounting of storage devices. In my humble opinion - or maybe
> not so humble in this particular case - that stuff is just more
> Windows'ism creeping into GNU/Linux.
I have to agree and hald has made device configuration far more difficult than
before, for example my desktop had just the Xorg with one section where to
configure keyboard, but with hald I have 3 different files and each of those
with a lot of crappy xml forcing to use try and error to see what works and
what don't. On my laptop I can't get the touchpad to work the same way as I
used to have it, it seems like sometimes hald do read some of my settings,
next moment it just ignores them and suddenly a double tap don't make a
middle-mouse-button anymore, but randomly teleports the cursor to another
section of the screen.
No, hald was a big step backwards, I guess we will have gnome2 style register
files everywhere in a soon future... then we will be a more true ms-windows
clone, as the gnome2 developers wishes.
--
//Aho
Aragorn
as J.O. Aho wrote...
> Aragorn wrote:
>
>> On Thursday 22 October 2009 06:27 in alt.os.linux, somebody
>> identifying as J.O. Aho wrote...
>>
>>> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
>>> and Xen 3.0.3... this forces us to build own RPMs to be able to run
>>> BSD based VMs. KVM just 0.83...
>>
>> Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
>> the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also
>> a RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0
>> - so my advice for Xen would be to wait until either the distribution
>> [...
>
> As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the
> 2.6.30 had been nice, but don't have time to maintain a kernel RPMs
> myself and I wouldn't be surprised that RHEL/CentOS 5.x will be
> forever stuck with the 2.6.18.
Well, you don't /have/ to maintain any kernel RPMs. Just fetch the
vanilla sources from kernel.org, unpack the tarball, do a...
make menuconfig
... or...
make xconfig
... and set up the kernel for your hardware. Then all you need to do
is...
make
... and then...
make modules_install install
... and reboot. ;-)
Of course, you will also first need to install Xen itself (and the Xen
tools), but that's a piece of cake. ;-)
>> ...] carries a 2.6.30 or later kernel, or else - which is what I
>> recommend - build a 2.6.30 or newer kernel with dom0 support from
>> sources. And while you're at it, get Xen 3.3 from xen.org directly -
>> it comes as either sources or as an .rpm or .deb package.
>
> As depending on 3rd party application to run on the dom0, [...
That's a bad idea. dom0 should be kept as clean as possible. It should
run the bridging or routing but it shouldn't even be set up to accept
any incoming traffic except for /ssh/ - which should be allowed to come
from the local LAN or any of the domUs anyway, but never directly from
the internet.
> ...] can't just install what ever I would like, or else they won't
> care with as much support as they do today and I think I would have
> gone with 3.4 instead, better to run bsd domu.
3.4? Oops, I'd better check the website again then, because I thought
that 3.3 was the latest official version. ;-)
>> Desktop-oriented distributions typically mess up a lot by means of
>> the additional "enhancement" patches they apply to the vanilla kernel
>> - this is something you will not see with CentOS or Slackware - which
>> may and often do introduce instabilities in the kernel, making it
>> less suitable for use on a server. [1]
>
> RHEL/CentOS glibc depending on gd, which in it's turn depends partly
> on X-libs. There are tons of applications I don't think should be
> installed on a server and CentOS does that, even starting with
> suggesting that you should installed over bloated gnome2.
Yeah, that is one thing I've noticed with our CentOS servers... My
colleague wanted to install hosting software - I have forgotten which
one because we've used different hosting software over the years, but I
think it might have been /virtualmin/ or /directadmin/ - which for some
reason insisted on X11 being installed as a dependency.
>> This is one of the reasons why I prefer building a kernel from the
>> vanilla sources, and in this particular case, you would have a kernel
>> that supports all of your hardware and that can be used as a Xen dom0
>> - 2.6.18 is stable but is really outdated with regard to hardware
>> support.
>
> We experienced real instability and random crashes and reboots with
> Dom0 using iscsi.
That should be resolved now, 13 kernel versions later than 2.6.18. ;-)
Vanilla Linux is already at 2.6.31.4 today. ;-)
That said, I have no experience with iSCSI. My Xen machine has a
combination of SAS disks and SATA disks, all local to the machine.
>> [1] By the same token, I also hate stuff like /hald/ and the whole
>> automounting of storage devices. In my humble opinion - or maybe
>> not so humble in this particular case - that stuff is just more
>> Windows'ism creeping into GNU/Linux.
>
> I have to agree and hald has made device configuration far more
> difficult than before, for example my desktop had just the Xorg with
> one section where to configure keyboard, but with hald I have 3
> different files and each of those with a lot of crappy xml forcing to
> use try and error to see what works and what don't. On my laptop I
> can't get the touchpad to work the same way as I used to have it, it
> seems like sometimes hald do read some of my settings, next moment it
> just ignores them and suddenly a double tap don't make a
> middle-mouse-button anymore, but randomly teleports the cursor to
> another section of the screen.
>
> No, hald was a big step backwards, I guess we will have gnome2 style
> register files everywhere in a soon future... then we will be a more
> true ms-windows clone, as the gnome2 developers wishes.
Well, Gnome users have scolded me for saying that Gnome looks more like
Windows - and in some versions, it really did - than KDE does, and I
have noticed that even on this PCLinuxOS 2009.2 system here, the GTK
apps have a somewhat "champagne-like" color to them, similar to Windows
XP. (Of course, neither Gnome nor KDE look anything as close to
Windows as LXDE.)
I've got this feeling - actually, I've been feeling this for a few years
already - that the newer batches of GNU/Linux users are just people who
absolutely love Windows but simply don't want to pay for it or deal
with its instabilities and malware infestations. So those are the
aspects that drive them from Windows to GNU/Linux, but in their hearts
they still want Windows, or "the next best thing" in look & feel to
that.
And of course, with only the negative aspects of Windows - insofar as it
pertains to the ones that are experienced as negative, without too much
thought having been spent on the why - being the incentive for those
users to start using GNU/Linux, they will still see a computer
according to the MICROS~1 single-user paradigm. I for one do not see a
computer that way.
I see a computer as a powerful multi-user machine, and I see GNU/Linux
as a genuine UNIX client/server multi-user architecture, and thus I
consider all that "plug & pray" (or "plug & panic") stuff a security
hazard. I also don't agree with any daemons modifying */etc/fstab* on
the fly just because you happen to plug in a USB stick. I'm allowing
it here on this machine but that's just because I consider this machine
a temporary solution, given that its hardware is flawed - it regularly
crashes, and lately that goes accompanied by blinking Shift Lock and
Scroll Lock lights on the keyboard (and Num Lock being switched off
when that happens), so it's definitely a hardware issue.
For a serious server and/or workstation however, I resent the whole plug
& play thing and the "let's regularly rewrite a few system files on the
root filesystem"-attitude. I prefer my system and its configuration as
static as possible. Besides, if I'm going to have my root filesystems
mounted read-only during normal operation, then all that automated
fiddling with */etc/fstab* wouldn't work anyway. */etc/mtab* is
another matter; you can make that a symlink to */proc/mounts.*
On another note, I would also like to see the OpenVZ patches be
submitted for inclusion in the vanilla kernel tree, because the
whole /kvm/ and /lguest/ approach is just another "me too" thing in the
area of virtual machine monitors. While /kvm/ may offer a
more "native" approach to virtual machine monitoring than VirtualBox or
VMWare - which are third-party products - it still follows the "home
desktop" paradigm rather than the server/workstation paradigm.
Xen paravirtualization (and hardware virtualization) support in vanilla
Linux was definitely a step in the right direction, but most
distributions don't carry or endorse Xen and instead supply things like
VirtualBox. OpenVZ is even a totally separate distribution on its own,
because none of the distros carry an OpenVZ kernel, other than Gentoo -
but that's a metadistribution, and that's a whole other story - or
possibly Debian, which probably has the largest repository of binary
packages. Yet, if you consider that FreeBSD has its own operating
system-level virtualization technology and that Solaris carries a
similar technology by default - i.e. the Solaris Containers - then
Linux as a kernel is lagging behind in this area. The patches exist,
so it should be trivial to include them in vanilla Linux.
There, I've just contributed my share of ranting again. :p
J.O. Aho
> On Thursday 22 October 2009 17:46 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
>> Aragorn wrote:
>>
>>> On Thursday 22 October 2009 06:27 in alt.os.linux, somebody
>>> identifying as J.O. Aho wrote...
>>>
>>>> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
>>>> and Xen 3.0.3... this forces us to build own RPMs to be able to run
>>>> BSD based VMs. KVM just 0.83...
>>>
>>> Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
>>> the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also
>>> a RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0
>>> - so my advice for Xen would be to wait until either the distribution
>>> [...
>> As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the
>> 2.6.30 had been nice, but don't have time to maintain a kernel RPMs
>> myself and I wouldn't be surprised that RHEL/CentOS 5.x will be
>> forever stuck with the 2.6.18.
>
> Well, you don't /have/ to maintain any kernel RPMs. Just fetch the
> vanilla sources from kernel.org, unpack the tarball, do a...
Thats simple if you have just one machine, but if you have a load of machines,
you want something a lot more simple to administrate and supply to the
machines than source compiling.
>>> ...] carries a 2.6.30 or later kernel, or else - which is what I
>>> recommend - build a 2.6.30 or newer kernel with dom0 support from
>>> sources. And while you're at it, get Xen 3.3 from xen.org directly -
>>> it comes as either sources or as an .rpm or .deb package.
>> As depending on 3rd party application to run on the dom0, [...
>
> That's a bad idea. dom0 should be kept as clean as possible. It should
> run the bridging or routing but it shouldn't even be set up to accept
> any incoming traffic except for /ssh/ - which should be allowed to come
> from the local LAN or any of the domUs anyway, but never directly from
> the internet.
It's the management tools which are 3rd party tools, of course you can ssh to
each machine start and stop VMs with xm, but it don't work when you allow your
customers do that and when you have a cluster of machine to manage, you really
need something to make things simpler.
>> ...] can't just install what ever I would like, or else they won't
>> care with as much support as they do today and I think I would have
>> gone with 3.4 instead, better to run bsd domu.
>
> 3.4? Oops, I'd better check the website again then, because I thought
> that 3.3 was the latest official version. ;-)
Checking xen on my own desktop, it says that 3.4.1 is in the repo, but I think
it's laggin behind, so wouldn't be surprised it's already 3.4.2 or .3.
>>> This is one of the reasons why I prefer building a kernel from the
>>> vanilla sources, and in this particular case, you would have a kernel
>>> that supports all of your hardware and that can be used as a Xen dom0
>>> - 2.6.18 is stable but is really outdated with regard to hardware
>>> support.
>> We experienced real instability and random crashes and reboots with
>> Dom0 using iscsi.
>
> That should be resolved now, 13 kernel versions later than 2.6.18. ;-)
> Vanilla Linux is already at 2.6.31.4 today. ;-)
>
> That said, I have no experience with iSCSI. My Xen machine has a
> combination of SAS disks and SATA disks, all local to the machine.
As service provider, we need to be more flexible and have a bit more space
than what you get on a handful hard drives attached to a server, we need
storage units with 40T+.
>> No, hald was a big step backwards, I guess we will have gnome2 style
>> register files everywhere in a soon future... then we will be a more
>> true ms-windows clone, as the gnome2 developers wishes.
>
> Well, Gnome users have scolded me for saying that Gnome looks more like
> Windows - and in some versions, it really did - than KDE does, and I
> have noticed that even on this PCLinuxOS 2009.2 system here, the GTK
> apps have a somewhat "champagne-like" color to them, similar to Windows
> XP. (Of course, neither Gnome nor KDE look anything as close to
> Windows as LXDE.)
I'm on my way back to ctwm after been using KDE3 for a quite long time (since
they killed gnome), but sadly I have to use some of those gnome2/kde4 apps
anyway. :(
> I've got this feeling - actually, I've been feeling this for a few years
> already - that the newer batches of GNU/Linux users are just people who
> absolutely love Windows but simply don't want to pay for it or deal
> with its instabilities and malware infestations. So those are the
> aspects that drive them from Windows to GNU/Linux, but in their hearts
> they still want Windows, or "the next best thing" in look & feel to
> that.
Yes, I think I have to agree and of cirse there are those too who need a game
server which is more stable than a ms-windows server, so the game developers
"supports" Linux with a dedicated game daemon, but not the game itself.
> And of course, with only the negative aspects of Windows - insofar as it
> pertains to the ones that are experienced as negative, without too much
> thought having been spent on the why - being the incentive for those
> users to start using GNU/Linux, they will still see a computer
> according to the MICROS~1 single-user paradigm. I for one do not see a
> computer that way.
I sadly seen the single user attitude too much in many "Linux" projects, I
don't use my home computers as a single user machines, as I'm not the only one
using a computer in my household and of course I want to be able to access my
files and applications settings regardless on which computer I log into, but
no, some start to store settings in a centralized directory which can't just
be exported as simply as /home.
> For a serious server and/or workstation however, I resent the whole plug
> & play thing and the "let's regularly rewrite a few system files on the
> root filesystem"-attitude. I prefer my system and its configuration as
> static as possible. Besides, if I'm going to have my root filesystems
> mounted read-only during normal operation, then all that automated
> fiddling with */etc/fstab* wouldn't work anyway. */etc/mtab* is
> another matter; you can make that a symlink to */proc/mounts.*
Yes, I'm looking at that direction myself, do you have some good links about
read only / ?
> On another note, I would also like to see the OpenVZ patches be
> submitted for inclusion in the vanilla kernel tree, because the
> whole /kvm/ and /lguest/ approach is just another "me too" thing in the
> area of virtual machine monitors. While /kvm/ may offer a
> more "native" approach to virtual machine monitoring than VirtualBox or
> VMWare - which are third-party products - it still follows the "home
> desktop" paradigm rather than the server/workstation paradigm.
The little experience from VB and VW, I do have to say I think KVM is a better
product as it is, I don't care it's lack of running ms-windows well, as it
won't be anything I would run anyway.
> Xen paravirtualization (and hardware virtualization) support in vanilla
> Linux was definitely a step in the right direction, but most
> distributions don't carry or endorse Xen.
For me it was that I couldn't get a stable system with the early kernels as
they lacked quite a lot of support for my 64bit hardware, so I went with KVM.
> Yet, if you consider that FreeBSD has its own operating
> system-level virtualization technology and that Solaris carries a
> similar technology by default - i.e. the Solaris Containers - then
OpenSolaris comes with their version of Xen, I get quite a lot of mail from
Sun about viritualization, but my Sun heart is with the Sparc based machines,
not thise sad AMD boxes.
--
//Aho
Aragorn
as J.O. Aho wrote...
> Aragorn wrote:
>
>> On Thursday 22 October 2009 17:46 in alt.os.linux, somebody
>> identifying as J.O. Aho wrote...
>>
>>> As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the
>>> 2.6.30 had been nice, but don't have time to maintain a kernel RPMs
>>> myself and I wouldn't be surprised that RHEL/CentOS 5.x will be
>>> forever stuck with the 2.6.18.
>>
>> Well, you don't /have/ to maintain any kernel RPMs. Just fetch the
>> vanilla sources from kernel.org, unpack the tarball, do a...
>
> Thats simple if you have just one machine, but if you have a load of
> machines, you want something a lot more simple to administrate and
> supply to the machines than source compiling.
Well, yes and no... If all the machines have a sufficiently identical
hardware set-up - i.e. they are all the same types of processors and
they have the same brand or type of SCSI controllers, etc. - then it's
as simply as creating a kernel .config file that would suit all
servers, and then all you need to do is install the sources on each
machine and compile them using the same .config file. That which
differs per machine can be compiled as loadable modules rather than
statically linked into the kernel image.
A preliminary build of a kernel took only about 50 seconds on my twin
dualcore Opteron machine - with "makeopts" set to "-j5" so it's not
like in the old days, where you had to wait for hours before the kernel
was built. :-)
>>> As depending on 3rd party application to run on the dom0, [...
>>
>> That's a bad idea. dom0 should be kept as clean as possible. It
>> should run the bridging or routing but it shouldn't even be set up to
>> accept any incoming traffic except for /ssh/ - which should be
>> allowed to come from the local LAN or any of the domUs anyway, but
>> never directly from the internet.
>
> It's the management tools which are 3rd party tools, of course you can
> ssh to each machine start and stop VMs with xm, but it don't work when
> you allow your customers do that and when you have a cluster of
> machine to manage, you really need something to make things simpler.
I would certainly not allow customers access to dom0. If they have to
have access to something, then I would either set up the requested domU
for them, or if they really insist on doing it themselves, I would set
up an OpenVZ inside an domU and let them play around there.
Of course, this may all be outside of your power to decide upon, so I'm
just mentioning how I would prefer things to be. ;-)
>>> ...] can't just install what ever I would like, or else they won't
>>> care with as much support as they do today and I think I would have
>>> gone with 3.4 instead, better to run bsd domu.
>>
>> 3.4? Oops, I'd better check the website again then, because I
>> thought that 3.3 was the latest official version. ;-)
>
> Checking xen on my own desktop, it says that 3.4.1 is in the repo, but
> I think it's laggin behind, so wouldn't be surprised it's already
> 3.4.2 or .3.
Hmm... They're really advancing then... :-) I guess I'm running a
little behind myself. :-)
>>>> This is one of the reasons why I prefer building a kernel from the
>>>> vanilla sources, and in this particular case, you would have a
>>>> kernel that supports all of your hardware and that can be used as a
>>>> Xen dom0 - 2.6.18 is stable but is really outdated with regard to
>>>> hardware support.
>>>
>>> We experienced real instability and random crashes and reboots with
>>> Dom0 using iscsi.
>>
>> That should be resolved now, 13 kernel versions later than 2.6.18.
>> ;-) Vanilla Linux is already at 2.6.31.4 today. ;-)
>>
>> That said, I have no experience with iSCSI. My Xen machine has a
>> combination of SAS disks and SATA disks, all local to the machine.
>
> As service provider, we need to be more flexible and have a bit more
> space than what you get on a handful hard drives attached to a server,
> we need storage units with 40T+.
Of course, I understand that. ;-) Still, kernel 2.6.18 versus kernel
2.6.31.4... That's quite a difference... ;-)
>>> No, hald was a big step backwards, I guess we will have gnome2 style
>>> register files everywhere in a soon future... then we will be a more
>>> true ms-windows clone, as the gnome2 developers wishes.
>>
>> Well, Gnome users have scolded me for saying that Gnome looks more
>> like Windows - and in some versions, it really did - than KDE does,
>> and I have noticed that even on this PCLinuxOS 2009.2 system here,
>> the GTK apps have a somewhat "champagne-like" color to them, similar
>> to Windows XP. (Of course, neither Gnome nor KDE look anything as
>> close to Windows as LXDE.)
>
> I'm on my way back to ctwm after been using KDE3 for a quite long time
> (since they killed gnome), but sadly I have to use some of those
> gnome2/kde4 apps anyway. :(
I'm using KDE 3.5.10 on this machine here. I've tried using it with
Compiz and it "sort of" works, but not really as desired. Qt and GTK
are two different pedigrees and they don't get along too well. ;-)
I do like KDE 3.5.10. I'm using it with virtually all the eyecandy
turned on - apart from using Compiz - and it works rather well. Still
a few bugs here and there, but only minor ones.
One thing I find very useful is Yakuake - I didn't have that before in
my KDE 3.2 set-up on Mandrake 10.0. I use it all the time now, instead
of opening up separate Konsole windows - which I still do on occasion,
if the situation calls for it. It's just so much easier to be working
in whatever GUI application and to simply hit /F12/ and have a terminal
emulator drop down right away. It also remembers its "history" (so to
speak) if you hide it again and call it up again later, i.e. that which
was "on your screen" when you scrolled it up again will still be there
when you bring it up the next time.
>> I've got this feeling - actually, I've been feeling this for a few
>> years already - that the newer batches of GNU/Linux users are just
>> people who absolutely love Windows but simply don't want to pay for
>> it or deal with its instabilities and malware infestations. So those
>> are the aspects that drive them from Windows to GNU/Linux, but in
>> their hearts they still want Windows, or "the next best thing" in
>> look & feel to that.
>
> Yes, I think I have to agree and of cirse there are those too who need
> a game server which is more stable than a ms-windows server, so the
> game developers "supports" Linux with a dedicated game daemon, but not
> the game itself.
Well, /some/ games have been ported to GNU/Linux, but indeed, not the
majority of them.
>> And of course, with only the negative aspects of Windows - insofar as
>> it pertains to the ones that are experienced as negative, without too
>> much thought having been spent on the why - being the incentive for
>> those users to start using GNU/Linux, they will still see a computer
>> according to the MICROS~1 single-user paradigm. I for one do not see
>> a computer that way.
>
> I sadly seen the single user attitude too much in many "Linux"
> projects, I don't use my home computers as a single user machines, as
> I'm not the only one using a computer in my household and of course I
> want to be able to access my files and applications settings
> regardless on which computer I log into, but no, some start to store
> settings in a centralized directory which can't just be exported as
> simply as /home.
That sucks. :-/ I must say that I haven't come across any of those yet,
though.
>> For a serious server and/or workstation however, I resent the whole
>> plug & play thing and the "let's regularly rewrite a few system files
>> on the root filesystem"-attitude. I prefer my system and its
>> configuration as static as possible. Besides, if I'm going to have
>> my root filesystems mounted read-only during normal operation, then
>> all that automated fiddling with */etc/fstab* wouldn't work anyway.
>> */etc/mtab* is another matter; you can make that a symlink to
>> */proc/mounts.*
>
> Yes, I'm looking at that direction myself, do you have some good links
> about read only / ?
The only good one I have found was on the Gentoo Wiki, but alas, due to
several hardware crashes, followed by necessitated reinstallations of
the operating system - on two different machines - I no longer have
that link available at the moment. :-/
However, if you do a Google search on "Gentoo+root+read-only" you might
find it again... I think... ;-)
>> On another note, I would also like to see the OpenVZ patches be
>> submitted for inclusion in the vanilla kernel tree, because the
>> whole /kvm/ and /lguest/ approach is just another "me too" thing in
>> the area of virtual machine monitors. While /kvm/ may offer a
>> more "native" approach to virtual machine monitoring than VirtualBox
>> or VMWare - which are third-party products - it still follows the
>> "home desktop" paradigm rather than the server/workstation paradigm.
>
> The little experience from VB and VW, I do have to say I think KVM is
> a better product as it is, I don't care it's lack of running
> ms-windows well, as it won't be anything I would run anyway.
I believe that it might run Windows via hardware virtualization support
or possibly via emulation, but that is not something which is of
interest to me. Quite frankly, all I pick up about Windows is what I
accidentally read somewhere. Wintendo doesn't interest me. ;-)
I do on occasion read something about MICROS~1, the company, but that's
a different kind of interest. For instance, I have read that the
American Departement of Defense has issued a billion dollar contract to
a couple of corporations - among whom MICROS~1 - for a modification of
the internet so that it becomes more suitable for military applications
again.
And this is something MICROS~1 has been dreaming about since 1995, and
why they have formed that Trusted Computing joint venture with Intel.
One of its purposes was to replace TCP/IP with a proprietary MICROS~1
protocol, which would have been safer - yeah right <lol> - and which
would of course make every computer hooked up to the internet endebted
to and dependent upon MICROS~1.
Still, I don't know to what extent the DARPA thing is going to
proprietarize the entire internet, though. They can get away with it
within the United States, but I doubt that the rest of the world would
be so willing to accept control over the internet being put back into
the hands of the American government, let alone MICROS~1, a convicted
monopolist.
>> Xen paravirtualization (and hardware virtualization) support in
>> vanilla Linux was definitely a step in the right direction, but most
>> distributions don't carry or endorse Xen.
>
> For me it was that I couldn't get a stable system with the early
> kernels as they lacked quite a lot of support for my 64bit hardware,
> so I went with KVM.
Well, Xen exists in a 64-bit version and supports 64-bit dom0. OpenVZ
is slowly getting there, but that requires a newer kernel than the one
they currently supply as "stable". They do have two "testing"-branch
kernels which support 64-bit and SMP, one being a 2.6.26 and the other
a 2.6.27.
>> Yet, if you consider that FreeBSD has its own operating
>> system-level virtualization technology and that Solaris carries a
>> similar technology by default - i.e. the Solaris Containers - then
>
> OpenSolaris comes with their version of Xen, [...
True, but they also support userspace containers, which is operating
system-level virtualization.
> ...] I get quite a lot of mail from Sun about viritualization, but my
> Sun heart is with the Sparc based machines, not thise sad AMD boxes.
Hey, you're hurting my feelings here! I sincerely respect the SPARC but
I do also happen to be a genuine fan of the AMD Opteron. :-)
J.O. Aho
> On Thursday 22 October 2009 19:29 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
>> Aragorn wrote:
>>
>>> On Thursday 22 October 2009 17:46 in alt.os.linux, somebody
>>> identifying as J.O. Aho wrote...
>>>
>>>> As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the
>>>> 2.6.30 had been nice, but don't have time to maintain a kernel RPMs
>>>> myself and I wouldn't be surprised that RHEL/CentOS 5.x will be
>>>> forever stuck with the 2.6.18.
>>> Well, you don't /have/ to maintain any kernel RPMs. Just fetch the
>>> vanilla sources from kernel.org, unpack the tarball, do a...
>> Thats simple if you have just one machine, but if you have a load of
>> machines, you want something a lot more simple to administrate and
>> supply to the machines than source compiling.
>
> Well, yes and no... If all the machines have a sufficiently identical
> hardware set-up - i.e. they are all the same types of processors and
> they have the same brand or type of SCSI controllers, etc. - then it's
> as simply as creating a kernel .config file that would suit all
> servers, and then all you need to do is install the sources on each
> machine and compile them using the same .config file. That which
> differs per machine can be compiled as loadable modules rather than
> statically linked into the kernel image.
The have only one thing common, the brand name, after that they differ quite a
lot from each other and no, you don't even want manually distribute a rpm file
to 50 servers and run "rpm -Uvh kernel-2.6.30-xen.x86_64.rpm", it's a
different thing if you have a coupe of machines at home.
>> It's the management tools which are 3rd party tools, of course you can
>> ssh to each machine start and stop VMs with xm, but it don't work when
>> you allow your customers do that and when you have a cluster of
>> machine to manage, you really need something to make things simpler.
>
> I would certainly not allow customers access to dom0. If they have to
> have access to something, then I would either set up the requested domU
> for them, or if they really insist on doing it themselves, I would set
> up an OpenVZ inside an domU and let them play around there.
You don't want to give customer any direct access to a server which they don't
pay for, so you need a fancy interface for them where they can do simple
things like create a new VM, start/stop it and make some simple setting changes.
>>>> No, hald was a big step backwards, I guess we will have gnome2 style
>>>> register files everywhere in a soon future... then we will be a more
>>>> true ms-windows clone, as the gnome2 developers wishes.
>>> Well, Gnome users have scolded me for saying that Gnome looks more
>>> like Windows - and in some versions, it really did - than KDE does,
>>> and I have noticed that even on this PCLinuxOS 2009.2 system here,
>>> the GTK apps have a somewhat "champagne-like" color to them, similar
>>> to Windows XP. (Of course, neither Gnome nor KDE look anything as
>>> close to Windows as LXDE.)
>> I'm on my way back to ctwm after been using KDE3 for a quite long time
>> (since they killed gnome), but sadly I have to use some of those
>> gnome2/kde4 apps anyway. :(
>
> I'm using KDE 3.5.10 on this machine here. I've tried using it with
> Compiz and it "sort of" works, but not really as desired. Qt and GTK
> are two different pedigrees and they don't get along too well. ;-)
I really not that much for eye candy, I need good functionality, but KDE4 is
focused only on eye candy and does most of the things you would have used
compiz for, all this to pleace some stupid windroidz.
> I do like KDE 3.5.10. I'm using it with virtually all the eyecandy
> turned on - apart from using Compiz - and it works rather well. Still
> a few bugs here and there, but only minor ones.
I have most of the eye candy turned off on my KDE3 desktop, as it don't give
me any functionality. The only real eyecandy to talk about it the transparent
panels, but thats it.
>>> For a serious server and/or workstation however, I resent the whole
>>> plug & play thing and the "let's regularly rewrite a few system files
>>> on the root filesystem"-attitude. I prefer my system and its
>>> configuration as static as possible. Besides, if I'm going to have
>>> my root filesystems mounted read-only during normal operation, then
>>> all that automated fiddling with */etc/fstab* wouldn't work anyway.
>>> */etc/mtab* is another matter; you can make that a symlink to
>>> */proc/mounts.*
>> Yes, I'm looking at that direction myself, do you have some good links
>> about read only / ?
>
> The only good one I have found was on the Gentoo Wiki, but alas, due to
> several hardware crashes, followed by necessitated reinstallations of
> the operating system - on two different machines - I no longer have
> that link available at the moment. :-/
>
> However, if you do a Google search on "Gentoo+root+read-only" you might
> find it again... I think... ;-)
Thanks, I hope it wasn't the old wiki which disappeared with a disk crash, the
new one isn't as good as the old one.
> I do on occasion read something about MICROS~1, the company, but that's
> a different kind of interest. For instance, I have read that the
> American Departement of Defense has issued a billion dollar contract to
> a couple of corporations - among whom MICROS~1 - for a modification of
> the internet so that it becomes more suitable for military applications
> again.
Will this mean we will have switches and gateways randomly crashing? This
would make it a lot more difficult for cyber attackers to attack pentagon, as
suddenly during the attack the switch crashes.
> And this is something MICROS~1 has been dreaming about since 1995, and
> why they have formed that Trusted Computing joint venture with Intel.
> One of its purposes was to replace TCP/IP with a proprietary MICROS~1
> protocol, which would have been safer - yeah right <lol> - and which
> would of course make every computer hooked up to the internet endebted
> to and dependent upon MICROS~1.
IPX or what it was called?
> Still, I don't know to what extent the DARPA thing is going to
> proprietarize the entire internet, though. They can get away with it
> within the United States, but I doubt that the rest of the world would
> be so willing to accept control over the internet being put back into
> the hands of the American government, let alone MICROS~1, a convicted
> monopolist.
Everything depends on how much money Redmond hands out under the table to
different politicians, like they did when they bought Luxembourg to hide a
resolution to enforce software patents within EU together with fishing quotes,
thanks to Poland, EU didn't accept software patent.
>>> Yet, if you consider that FreeBSD has its own operating
>>> system-level virtualization technology and that Solaris carries a
>>> similar technology by default - i.e. the Solaris Containers - then
>> OpenSolaris comes with their version of Xen, [...
>
> True, but they also support userspace containers, which is operating
> system-level virtualization.
>
>> ...] I get quite a lot of mail from Sun about viritualization, but my
>> Sun heart is with the Sparc based machines, not thise sad AMD boxes.
>
> Hey, you're hurting my feelings here! I sincerely respect the SPARC but
> I do also happen to be a genuine fan of the AMD Opteron. :-)
AMD is okey for desktop, I do run it at home, but Sparc is the real thing, of
course PowerPC works fine too. I wish there had been more big endian desktop
machines, the nearest you get today is those older PS3, as sadly those "slim"
don't support Linux.
--
//Aho
Aragorn
as J.O. Aho wrote...
> Aragorn wrote:
>
>> On Thursday 22 October 2009 19:29 in alt.os.linux, somebody
>> identifying as J.O. Aho wrote...
>>>
>>> I'm on my way back to ctwm after been using KDE3 for a quite long
>>> time (since they killed gnome), but sadly I have to use some of
>>> those gnome2/kde4 apps anyway. :(
>>
>> I'm using KDE 3.5.10 on this machine here. I've tried using it with
>> Compiz and it "sort of" works, but not really as desired. Qt and GTK
>> are two different pedigrees and they don't get along too well. ;-)
>
> I really not that much for eye candy, I need good functionality, but
> KDE4 is focused only on eye candy and does most of the things you
> would have used compiz for, all this to pleace some stupid windroidz.
Well, no, it's more complicated than that. KDE 4.x is about an entirely
new paradigm for the desktop, but I don't think most of the KDE 4
adopters will actually be using their desktop according to this new
paradigm.
Of course, the black panels and all is just a catering to the Vista
fans, but I think you can change that.
>> I do like KDE 3.5.10. I'm using it with virtually all the eyecandy
>> turned on - apart from using Compiz - and it works rather well.
>> Still a few bugs here and there, but only minor ones.
>
> I have most of the eye candy turned off on my KDE3 desktop, as it
> don't give me any functionality. The only real eyecandy to talk about
> it the transparent panels, but thats it.
Well, that's the part of the eyecandy which I don't use. :-) My panels
are solid. I have one panel at the bottom - the normal one - and one
that forms the menu of the active application. I've added a few icons
to that one - among others, the KDE system menu, which I rather have on
the top panel than on the bottom panel - and an uptime/CPU usage
monitor applet.
I'm also using the "System++" window decorations, "Keramik" widget style
and a variation on the "Blue Slate" color scheme - it has a white
background for documents - plus all custom sizes for the system fonts.
>> I do on occasion read something about MICROS~1, the company, but
>> that's a different kind of interest. For instance, I have read that
>> the American Departement of Defense has issued a billion dollar
>> contract to a couple of corporations - among whom MICROS~1 - for a
>> modification of the internet so that it becomes more suitable for
>> military applications again.
>
> Will this mean we will have switches and gateways randomly crashing?
> This would make it a lot more difficult for cyber attackers to attack
> pentagon, as suddenly during the attack the switch crashes.
Well, that's one option, but the proprietarization of a globally used
protocol is what scares me the most. Well, we don't have to beat
around the bush about it, and I don't want to go the "Sid" way and
sound like a conspiracy lunatic - albeit that many conspiracies are
actually very real - but Bill Gates is after all a Bilderberger, and
they are by definition corporate cryptofascists.
>> And this is something MICROS~1 has been dreaming about since 1995,
>> and why they have formed that Trusted Computing joint venture with
>> Intel. One of its purposes was to replace TCP/IP with a proprietary
>> MICROS~1 protocol, which would have been safer - yeah right <lol> -
>> and which would of course make every computer hooked up to the
>> internet endebted to and dependent upon MICROS~1.
>
> IPX or what it was called?
No, IPX was Novell's network protocol. I think the joint MICROS~1 and
Intel protocol was called Palladium.
>> Still, I don't know to what extent the DARPA thing is going to
>> proprietarize the entire internet, though. They can get away with it
>> within the United States, but I doubt that the rest of the world
>> would be so willing to accept control over the internet being put
>> back into the hands of the American government, let alone MICROS~1, a
>> convicted monopolist.
>
> Everything depends on how much money Redmond hands out under the table
> to different politicians, like they did when they bought Luxembourg to
> hide a resolution to enforce software patents within EU together with
> fishing quotes, thanks to Poland, EU didn't accept software patent.
They also bought themselves into the UK like that. Allegedly, Bill
Gates bought Tony Blair a mansion, resulting in all official websites
of the United Kingdom suddenly being supported by Internet ExploDer
only and no longer being compatible with Mozilla, Firefox, Netscape or
Opera.
I don't know whether this is still the case today, though. I'm not a
British citizen and so I've never had a need to visit any of those
websites.
>>> I get quite a lot of mail from Sun about viritualization, but
>>> my Sun heart is with the Sparc based machines, not thise sad AMD
>>> boxes.
>>
>> Hey, you're hurting my feelings here! I sincerely respect the SPARC
>> but I do also happen to be a genuine fan of the AMD Opteron. :-)
>
> AMD is okey for desktop, I do run it at home, but Sparc is the real
> thing, of course PowerPC works fine too. I wish there had been more
> big endian desktop machines, the nearest you get today is those older
> PS3, as sadly those "slim" don't support Linux.
Well, I would hardly call an AMD Opteron a desktop processor chip. :-)
I also consider AMD to be far more FOSS- and GNU/Linux-friendly than
Intel. Of course, Intel supports GNU/Linux and actively participates
on the development of the Linux kernel, but at the same time they are
also in league with MICROS~1 - see what we've discussed higher up.
AMD on the other hand has - without that anyone asked for it - decided
to make the GART on AMD64 available as an IOMMU specifically so that
Linux could use it. They have also implemented a few specific
registers which were in fact obsolete, but which Windows needs, and of
which MICROS~1 thus requested that they be added to the AMD64 design.
And that goes to show how "good" MICROS~1 really is at developing
operating systems [1], if instead of porting their operating system to
a processor architecture, they require that the processor architecture
be ported to the operating system. <grin>
[1] Not that MICROS~1 has ever developed anything of their own, least
of all an operating system. MS-DOS was a rebranded QDOS, written
by Tim Patterson of Seatte Computer as an unauthorized "update" to
CP/M, which was written by Gary Kildall. OS/2 was a joint venture
with IBM, who had taken the initiative, although developers were
being exchanged back and forth between both companies during the
initial development of the OS/2 1.x generations. NT was an
unauthorized and illegal copy of major chunks of the VMS kernel,
and *by* the VMS kernel developer Dave Cutler. XENIX was based
upon AT&T UNIX. Not even BASIC was developed by Bill Gates
himself.
We also know why MICROS~1 purchased Corel. It had nothing to do
with CorelDraw, but with the fact that Corel had started releasing
its own (not too good) GNU/Linux distribution, and when Corel was
out on the market, MICROS~1 seized the opportunity to buy Corel
and subsequently kill their GNU/Linux distribution development.
Still, if you want a good laugh, check out this "oldie but
goodie"... :p
J.O. Aho
> On Thursday 22 October 2009 20:59 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
>> Aragorn wrote:
>>
>>> On Thursday 22 October 2009 19:29 in alt.os.linux, somebody
>>> identifying as J.O. Aho wrote...
>>>> I'm on my way back to ctwm after been using KDE3 for a quite long
>>>> time (since they killed gnome), but sadly I have to use some of
>>>> those gnome2/kde4 apps anyway. :(
>>> I'm using KDE 3.5.10 on this machine here. I've tried using it with
>>> Compiz and it "sort of" works, but not really as desired. Qt and GTK
>>> are two different pedigrees and they don't get along too well. ;-)
>> I really not that much for eye candy, I need good functionality, but
>> KDE4 is focused only on eye candy and does most of the things you
>> would have used compiz for, all this to pleace some stupid windroidz.
>
> Well, no, it's more complicated than that. KDE 4.x is about an entirely
> new paradigm for the desktop, but I don't think most of the KDE 4
> adopters will actually be using their desktop according to this new
> paradigm.
Yes, there are some real changes how to use the desktop works, but it's done
more in mid of a single screen, single user in mind, system defaults are
ignored. I think Suns Java desktop had more usefulness an innervation than KDE4.
> Of course, the black panels and all is just a catering to the Vista
> fans, but I think you can change that.
The new panel don't have coordinate positioning of icons, you need to place
empty-space-blocks, say you want something to be in the middle of the panel,
then you place all the icons you want to be in the left/right en of the panel,
then you start to place a million empty-blocks, until you are at he middle,
place what you want to be there, then empty-blocks again an you are at the
other end where you can add some more icons... this was far better in KDE3
where you jut placed the icon in the middle and it stayed there...
>>> And this is something MICROS~1 has been dreaming about since 1995,
>>> and why they have formed that Trusted Computing joint venture with
>>> Intel. One of its purposes was to replace TCP/IP with a proprietary
>>> MICROS~1 protocol, which would have been safer - yeah right <lol> -
>>> and which would of course make every computer hooked up to the
>>> internet endebted to and dependent upon MICROS~1.
>> IPX or what it was called?
>
> No, IPX was Novell's network protocol. I think the joint MICROS~1 and
> Intel protocol was called Palladium.
Found something:
"Doc's Cover Palladium Privacy, Unique Identifier Issues. EPIC has documents
from the National Institute of Standards and Technology under the Freedom of
Information Act describing Microsoft Palladium. The documents (pdf 980k,
http://www.epic.org/privacy/consumer/microsoft/nistpalladium.pdf) describe
Palladium's applications for Digital Rights Management and note that the
technology embeds "unique machine identifiers," thus raising risks that user
behavior may be subject to traffic analysis. Issues raised by Palladium, which
is now known as the Next Generation Secure Computing Base, are similar to
privacy problems with the controversial Intel Pentium Serial Number.
In June 2002, Microsoft released information regarding its new "Palladium"
initiative. Palladium is a system that combines software and hardware controls
to create a "trusted" computing platform. In doing so, it would establish an
unprecedented level of control over users and their computers."
The whole story at:
http://epic.org/privacy/consumer/microsoft/palladium.html
>>>> I get quite a lot of mail from Sun about viritualization, but
>>>> my Sun heart is with the Sparc based machines, not thise sad AMD
>>>> boxes.
>>> Hey, you're hurting my feelings here! I sincerely respect the SPARC
>>> but I do also happen to be a genuine fan of the AMD Opteron. :-)
>> AMD is okey for desktop, I do run it at home, but Sparc is the real
>> thing, of course PowerPC works fine too. I wish there had been more
>> big endian desktop machines, the nearest you get today is those older
>> PS3, as sadly those "slim" don't support Linux.
>
> Well, I would hardly call an AMD Opteron a desktop processor chip. :-)
>
> I also consider AMD to be far more FOSS- and GNU/Linux-friendly than
> Intel. Of course, Intel supports GNU/Linux and actively participates
> on the development of the Linux kernel, but at the same time they are
> also in league with MICROS~1 - see what we've discussed higher up.
Sure, wouldn't you want to cooperate with a crock who never have to be afraid
of being punished, a little bit of bribes here and another lie here and a kind
of a monopoly there, as you can be sure to ripe a good harvest of other
companies, governments and end users.
> And that goes to show how "good" MICROS~1 really is at developing
> operating systems [1], if instead of porting their operating system to
> a processor architecture, they require that the processor architecture
> be ported to the operating system. <grin>
They still use "Free C Compiler", so they have no choice ;) I don't think they
have ever discovered anything that could be remotely call optimization option
in their compiler and no oner has bothered to learn anything new since 8080
was released.
--
//Aho
Ivan Marsh
> Anybody using CentOS?
Yes.
--
"All right, all right, if it will make you happy, I will overthrow society."
- Philip J. Fry
Mike Jones
> Mike Jones wrote:
>
>> Anybody using CentOS?
>
> Yes.
I had noticed. ;\
Rikishi42
> Anybody using CentOS?
Yup, on a Soekris (http://www.soekris.com/net5501.htm).
Runs cool, as backup server and NNTP server.
--
Any time things appear to be going better, you have overlooked
something.
Mike Jones
> On 2009-10-21, Mike Jones <N...@Arizona.Bay> wrote:
>
>> Anybody using CentOS?
>
> Yup, on a Soekris (http://www.soekris.com/net5501.htm).
>
> Runs cool, as backup server and NNTP server.
Threads kinda done with now, but thanks for the tip anyhoo. :)