Re: Athlon 64 support? (multiple responses)
by Dee-Ann LeBlanc
Gerald Henriksen <ghenriks(a)rogers.com> wrote:
> As far as the CPU instruction set is concerned Athlon64 and Opteron
> are identical as they are both AMD64 processors.
Good to know. :)
> At some point in the future there likely will be an AMD64 version of
> RHLP, as the community will likely build it if necessary. However
> this won't happen in time for the release of Red Hat 10 given that
> Athlon64 is not yet available, and reportedly won't be available in
> volume for many months yet.
Oh sure, I didn't think it would be for 10. :) I'm asking in general. :)
>
> However the normal version of Red Hat 9/10/etc. will work fine on an
> Athlon64 machine albeit without support for the new features of the
> AMD64 architecture (no 64bit stuff, no additional registers, etc).
Ah, okay, so that should be the same for any distro, really. Good good.
Hardware isn't my specialty, can you tell? :)
"Mike A. Harris" <mharris(a)redhat.com> wrote:
> It's unknown at this point in time wether or not an official
> AMD64 release will be done for the RHLP. That is yet to be
> decided.
I expect I'll see something related to this asked in the next demo RHN
survey then. :)
>
> On a personal note however, if an official release doesn't occur,
> I will be volunteering personal time to work on a community
> driven release along with other interested parties if possible.
Awesome. :)
>
> Once the Athlon 64 consumer chip becomes available, I believe
> that there will definitely be a quickly forming enthusiast
> community for this new chip, and I know what OS I'd like to see
> people running on it. ;o)
Oh yes. I'm sure I won't be the only one salivating. :)
>
> Of course this is all just personal speculation of my own, and I
> do not speak for Red Hat in any way.
Understood!
--
Dee-Ann LeBlanc, RHCE
Lots of things Linux
http://www.Dee-AnnLeBlanc.com/
20 years, 3 months
up2date and apt/yum repositories
by Paul Nasrat
I've been doing some testing using
up2date-3.9.13-2
Firstly an obvious should bail is:
up2date --get-source against a yum url, I believe yum-arch now indexes
headers of src.rpms but when running against fedora I get:
up2date --get-source synaptic
...
synaptic-0.43.1-0.fdr.1.rh90.93.src.rpm...
There was some sort of I/O error: HTTP Error 404: Not Found
Should we ignore src.rpm headers in yum archives as the path to them is
not necessarily obvious (parallel with yum directory, or a subdirectory,
etc).
This is better than with up2date-3.9.6-1 where it would download the
html error page :)
In addition I just tried to update to kernel test4 from arjanv's
repository (using apt up2date):
up2date --nox --force kernel
...
Test install failed because of package conflicts:
file /lib/modules from install of kernel-2.6.0-0.test4.1.32 conflicts
with file from package filesystem-2.2.1-4
rpm -qf /lib/modules/
filesystem-2.2.1-4
kernel-2.4.21-20.1.2024.2.1.nptl
kernel-2.6.0-0.test3.1.31
This seems odd to me as both kernel-2.4 spec and kernel 2.6 specs are
consistent in having /lib/modules in them, am I missing something
obvious as this should work.
Paul
20 years, 3 months
gnome-bluetooth gnome-vfs module.
by David Woodhouse
Shouldn't /usr/lib/gnome-vfs-2.0/modules/libbluetooth in the
gnome-bluetooth package be called libbluetooth.so? Renaming it makes
Nautilus a lot happier.
Gnome-bluetooth doesn't seem to exist in Bugzilla, either.
And although I can drop a vcard file onto my phone, I can't drop a
contact from Evolution.
--
dwmw2
20 years, 3 months
bugzilla: See bugs in this component
by Michael Schwendt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The "See bugs in this component" button at step 4 of bugzilla Bug
Wizard bugs me:
https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi
It is brain-dead, because it queries the database only for the
specific product chosen in the previous step.
It is misleading, because it reports "Zarro Boogs found" for a
component which clearly has bugs in the same version of a package in
Raw Hide or a different "Product".
Probably not easily possible without hacking the bugzilla code, but
for instance, when reporting bugs against the latest Red Hat Linux
Beta, the button should at least find open bugs in Raw Hide, too.
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/S1y+0iMVcrivHFQRAoD0AJ0R6A29eyBfmMhDVNuEY55SQMD/VwCdH2Ry
T8jOxQ28zNzJ33bQckoUv90=
=VM+c
-----END PGP SIGNATURE-----
20 years, 3 months
Athlon 64 support?
by Dee-Ann LeBlanc
I understand that Red Hat is planning to support Athlon 64 machines
specifically in the Enterprise line? Is this correct? (I'm not bashing
or judging, just confirming a fact. :)
--
Dee-Ann LeBlanc, RHCE
Lots of things Linux
http://www.Dee-AnnLeBlanc.com/
20 years, 3 months
Services & firewall configuration
by Ian Pilcher
Reading the discussion about Taroon, portmapper, ports, etc., reminded
me of one of the shortcomings of Red Hat Linux (and all other
distributions AFAIK).
It seems to me that the fundamental problem is the lack of "linkage"
(for lack of a better word) between service configuration and firewall
configuration. In an ideal world, the network access required by a
service would be easy to determine -- perhaps with chkconfig-like meta-
data in the init script. The firewall configuration program could then
be enhanced to prompt accordingly.
Even better, to my mind, would be to actually combine the services and
firewall configuration programs. Instead of a single checkbox for each
service, each service would have a checkbox for each interface. The
network configuration program should probably prompt the user to run the
firewall configuration when an interface is added.
Just some thoughts on future directions. Flame away!
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
20 years, 3 months
Re: Athlon 64 support?
by Dee-Ann LeBlanc
Sean Middleditch <elanthis(a)awesomeplay.com> wrote:
> Supporting Athlon 64 in the Enterprise line only would be daft, as
> Athlon 64 is a consumer chip. Perhaps you meant Opteron, the
> server/workstation AMD64 CPU? But speaking of Athlon 64, will a
> consumer RHL project release be made for it?
Actually, someone didn't do enough reading before she posted that. I am
indeed asking about support for the Athlon 64, which indeed Red Hat has
not made a public statement on at all as far as I can tell. So now my
question is whether Athlon 64 support is going to be bundled in with the
main RHLP or a separate one. :)
--
Dee-Ann LeBlanc, RHCE
Lots of things Linux
http://www.Dee-AnnLeBlanc.com/
20 years, 3 months
gconfd logs
by Konstantin Ryabitsev
Hello, all:
This is aimed at Havoc mostly -- I think it's a bad idea to i18n-ize the
stuff that goes into syslog, which is what gconfd currently does. We
have many users using various languages, and it doesn't help to see
gconfd error reports in Chinese or Korean. Can we just stick to English
for the backend stuff that the user never sees?
Alternatively, it would be good to have two settings for the locale --
one for the user currently logged in at the console, and another set by
the sysadmin for the stuff they want to see in the logs.
Really, seeing error reports in Chinese does me little good, and can't
be analyzed by various log-reporting tools.
Any thoughts?
Regards,
--
Konstantin ("Icon") Riabitsev
Duke Physics Sysadmin, RHCE
20 years, 3 months
AGPGART
by Dave Bevan
Does anyone know (for Severn-Beta-1 or Severn-Beta-1+Arjanv's 2.6-test3.1.31 kernel) the following:
a) If AGPGART does AGP 8X on Intel 875p AGP chipsets?
b) A way of querying AGPGART settings, in particular AGP Window Size, on a running kernel?
-- Dave.
Dave Bevan | New Media Support Specialist
BBC News Support | London
BBCi at http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
20 years, 3 months
linux/autoconf.h and RED_HAT_LINUX_KERNEL
by Féliciano Matias
First, i am not a "kernel hacker".
If /usr/src/linux-2.4/include/linux/autoconf.h is generated by "make
menuconfig" or "oldconfig", ... the news autoconf.h doesn't include
linux/rhconfig.h.
It's normal since the original autoconf.h and rhconfig.h conform with
binary Redhat kernel supply with the distribution.
If i let autoconf.h untouched, "#include <linux/autoconf.h>" define the
RED_HAD_LINUX_KERNEL macro. That's nice.
But if a use a "custom" kernel (make mrproper, make...) ,
RED_HAT_LINUX_KERNEL macro is not more defined.
This cause some trouble with alsa-driver. I try to build alsa for RH9
from freshrpms :
http://shrike.freshrpms.net/rpm.html?id=856
Alsa's configure try to find out if a RedHat kernel is used :
boolvar=RED_HAT_LINUX_KERNEL
echo "$as_me:3104: checking for redhat kernel" >&5
echo $ECHO_N "checking for redhat kernel... $ECHO_C" >&6
ac_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -I$CONFIG_SND_KERNELDIR/include"
boolchk=""
if test "$cross_compiling" = yes; then
echo "$as_me:3110: result: \"unknown\"" >&5
echo "${ECHO_T}\"unknown\"" >&6;boolchk=""
else
cat >conftest.$ac_ext <<_ACEOF
#line 3115 "configure"
#include "confdefs.h"
#include "$CONFIG_SND_KERNELDIR/include/linux/autoconf.h"
int main( void ) {
#ifndef $boolvar
exit(1);
#else
exit(0);
#endif
}
_ACEOF
This doesn't work with a custom kernel. Even with a not so custom kernel
:
$ make mrproper
$ cp configs/kernel___config .config
$ make dep
Perhaps, you can add RED_HAT_LINUX_KERNEL_SOURCE in autoconf.h and leave
RED_HAT_LINUX_KERNEL only in rhconfig.h.
--
Féliciano Matias <feliciano.matias(a)free.fr>
20 years, 3 months
