Re: [gentoo-amd64] UDEV
On Saturday 26 March 2005 14:47, Mark Constable wrote: > Is anyone else successfully using a udev-only system on amd64 or > is this a general/amd64 wide issue (and not just for me) ? Seeing as how udev implies udev-only (udev and devfs are mututally exclusive), I suspect many people have udev-only setups... The first time I tried moving to udev, it was nothing but headaches, so I switched back quite quickly. A few weeks ago, when I tried again, it seemed to work, so I'm now using a udev system... However, CD/DVD burning is an issue for me: One drive will burn only if cdrecord is *not* setuid root, the other will not burn at all. I do not use an initrd, so there's one major difference between your system and mine. Have you tried rebuilding the initrd lately? -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Flash plug-in
On Friday 25 March 2005 11:33, Simon Stelling wrote: > Luigi Pinna wrote: > > I tried to the manuall installation but the installer doesn't support > > the x86_64 architecture... > > Is there a solution? > > Not only the installer, the whole flash thing doesn't support amd64, so > you have to use a 32bit-browser (i.e. mozilla-firefox-bin). You can't > load a 32bit-plugin into a 64bit browser, that's the problem. Unless you stick to using moral software. I'm using the latest GPLFlash (*not* in Portage) and it works fine in many cases, though I haven't managed to get it to work in Konqueror yet (only FireFox). -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
On Wednesday 02 March 2005 05:09, Renzo Rosales wrote: > Is anyone going to help this guy? lol He doesn't want us to. He'd rather we all delete his email! =p -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
On Wednesday 02 March 2005 02:09, Joseph LeMoyne IV wrote: > Hate to burst your bubble, guys, but Simone was joking. Notice the > almost word-for-word reply. "I hope this will be appreciated." Come on. I was primarily replying to Mark, not Simone. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] KDE 3.4 arts build problem
On Wednesday 02 March 2005 01:52, Marcus D. Hanwell wrote: > I have run beta1 - rc1, and they were compiled with > sys-devel/gcc-3.4.3.20050110. Contrary to what has been said the > Gentoo GCC can and does compile KDE successfully. Then explain why there's a workaround in kde.eclass: > # temp fix for bug #78720, until the real bug in gcc gets fixed > # briefly, -fvisibility-inlines-hidden is broken on amd64 and ppc > # this only applies to kde 3.4. the grep prevents us from removing configure unnecessarily. > if useq amd64 || useq ppc; then > if grep -- '-fvisibility=hidden -fvisibility-inlines-hidden' admin/acinclude.m4.in >/dev/null; then >sed -i -e 's:-fvisibility=hidden -fvisibility-inlines-hidden:-fvisibility=hidden:' admin/acinclude.m4.in >rm -f configure > fi > fi On Wednesday 02 March 2005 01:52, Marcus D. Hanwell wrote: > I have also used sys-devel/gcc-3.4.3-r1 in one of my chroots - any minor > issues have already been patched as far as I am aware. Gentoo is apparently patching KDE to ignore Gentoo's GCC's claim of visibility support, so you're right in saying that this should not be the problem... However, Gentoo's GCC *is* broken and *does* prevent vanilla KDE from compiling. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
On Wednesday 02 March 2005 01:51, B Vance wrote: > On Wed, 2005-03-02 at 01:21 +0000, Luke-Jr wrote: > > > On Tuesday 01 March 2005 20:33, Creamer, Mark wrote: > > > > This e-mail transmission contains information that is intended to be > > > > confidential and privileged. If you receive this e-mail and you are > > > > not a named addressee you are hereby notified that you are not > > > > authorized to read, print, retain, copy or disseminate this > > > > communication without the consent of the sender and that doing so is > > > > prohibited and may be unlawful. Please reply to the message > > > > immediately by informing the sender that the message was misdirected. > > > > After replying, please delete and otherwise erase it and any > > > > attachments from your computer system. Your assistance in correcting > > > > this error is appreciated. > > > > On Tuesday 01 March 2005 23:01, Simone Piunno wrote: > > > this is just to inform you I have received an email from you but I > > > wasn't a named addresse. According to the notice that was included in > > > that email, I was not authorized to read, print, retain, copy and > > > disseminate that email without your consent, and that doing so could be > > > unlawful. Then I've decided to fulfill the request to reply and inform > > > you of what happened, as I'm doing now. I confirm I've already deleted > > > the email from my system. I hope this will be appreciated. > > > > This is to inform both of you that while Mark can legally deny your/our > > right to print, copy, or disseminate his emails, but he cannot prevent > > you/us from reading or retaining it. Likewise, you/we are not legally > > obligated to delete or erase his emails, nor to inform him of any such > > "mistakes" simply because he tells you to. > > Then again it could be a simple signature asking that people who get a > message via misdirection, simply tell him so he can re-send to the > proper people and then toss it (Unless you're really curious about what > he does). Seems to boil down to common courtesy, and easily ignored if > it offends. True, but if he wants common courtesy, he shouldn't be insisting that whatever he says goes. Saying "Please let me know and delete the email if you got it by mistake" is quite different than "You must email me & delete this email or else" -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
> On Tuesday 01 March 2005 20:33, Creamer, Mark wrote: > > This e-mail transmission contains information that is intended to be > > confidential and privileged. If you receive this e-mail and you are not a > > named addressee you are hereby notified that you are not authorized to > > read, print, retain, copy or disseminate this communication without the > > consent of the sender and that doing so is prohibited and may be unlawful. > > Please reply to the message immediately by informing the sender that the > > message was misdirected. After replying, please delete and otherwise > > erase it and any attachments from your computer system. Your assistance > > in correcting this error is appreciated. On Tuesday 01 March 2005 23:01, Simone Piunno wrote: > this is just to inform you I have received an email from you but I wasn't a > named addresse. According to the notice that was included in that email, I > was not authorized to read, print, retain, copy and disseminate that email > without your consent, and that doing so could be unlawful. Then I've > decided to fulfill the request to reply and inform you of what happened, as > I'm doing now. I confirm I've already deleted the email from my system. I > hope this will be appreciated. This is to inform both of you that while Mark can legally deny your/our right to print, copy, or disseminate his emails, but he cannot prevent you/us from reading or retaining it. Likewise, you/we are not legally obligated to delete or erase his emails, nor to inform him of any such "mistakes" simply because he tells you to. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] KDE 3.4 arts build problem
On Wednesday 02 March 2005 00:13, you wrote: > probably I'm not the first to encounter the following problem. I try to > install KDE 3.4. I'm using the kdecvs-build script but I can't even compile > arts. The problem is because Gentoo is using a broken backport of the GCC visibility feature and they don't seem to care to fix it. I disabled it for my GCC by adding this to make.conf: GENTOO_PATCH_EXCLUDE='13_all_gcc34-visibility1.patch.bz2 15_all_gcc34-visibility3.patch.bz2 14_all_gcc34-visibility2.patch.bz2' YMMV. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
On Saturday 19 February 2005 03:04, Scott Serr wrote: > I don't think anyone would buy one of these by choice, you are right > there. But if it comes with your notebook -- you home it will work. I > installed AMD64 Gentoo, used an Orinoco PCMCIA while trying to get my > internal supported. I found that I had to use ndiswrapper, but it was > only supported in 32bit Linux (Mar 2004). OK... so I set out to replace > it with a card that was supported with an open source driver. I bought > it and carefully installed it on my 1 month old (at the time) notebook. > To my amazement the BIOS halted with a message something like > "Unsupported network adapter. Remove and reboot your system." This is > a BIOS Wireless Whitelist. IBM, HP/Compaq, and Dell are using them to > control what cards you can put in your notebook. http://www.srcf.ucam.org/~mjg59/thinkpad/hack.c This should, in theory, at least, remove the whitelist restrictions... -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Recommendations for Intel Xeon
On Sunday 20 February 2005 22:07, gentoo-user wrote: > I'm getting a server with Intel Xeon CPUs that support EM64T (Intel's > version of AMD64). Would you recommend sticking with i686 compile options > for a production-level server? What are the benefits of compiling with > 64-bit support? Is the speed difference (if any) worth the potential loss > of stability? From what I've heard, Intel's x86_64 CPUs really are just x86 with added 64-bit emulation on the chip. 64-bit code therefore runs slower, etc... Might want to confirm it from someone who actually has one, though. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
On Saturday 19 February 2005 03:04, Scott Serr wrote: > I nice cheap one that is supported well is the Xterasys. I've purchased > one, although it's sitting in a box. Supported well with libre drivers or with proprietary junk? This makes a big difference to many people... (a quick google didn't come up with any drivers, let alone libre vs proprietary info) > > > -Original Message- > > From: Luke-Jr [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 22, 2005 10:08 PM > > > > On Sunday 23 January 2005 2:50 am, [EMAIL PROTECTED] wrote: > > > x86_64 is now supported with ndiswrapper-1.03-rc3. This means there's > > > finally a way to get Broadcom wireless adapters working. > > > > Why would anyone buy these, I wonder? I can understand Airport Express > > coming > > in Macs, but that would be PPC, not x86_64... > > > > I don't think anyone would buy one of these by choice, you are right > there. But if it comes with your notebook -- you home it will work. I > installed AMD64 Gentoo, used an Orinoco PCMCIA while trying to get my > internal supported. I found that I had to use ndiswrapper, but it was > only supported in 32bit Linux (Mar 2004). OK... so I set out to replace > it with a card that was supported with an open source driver. I bought > it and carefully installed it on my 1 month old (at the time) notebook. > To my amazement the BIOS halted with a message something like > "Unsupported network adapter. Remove and reboot your system." Can you add the card after the system is booted? > This is > a BIOS Wireless Whitelist. IBM, HP/Compaq, and Dell are using them to > control what cards you can put in your notebook. Can they advertise PCMCIA/CardBus support with that limitation? IMO, if their systems will not accept a standard PCMCIA/CardBus card, then they have no right to claim support/compatibility with the standards. If someone pulled that on me, I would demand that they either give me a BIOS to flash without the whitelist crap or allow me to return it for the full price at their expense... -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Several problems with Gentoo AMD64
On Friday 11 February 2005 01:04, Mark Constable wrote: > Luke-Jr wrote: > > ... > > Not related to the problem you are having, but don't expect to be able to > > compile KDE with the more recent Gentoo revisions of GCC. They enable a > > broken backport of the visibility stuff which breaks KDE. > > What might be the best CFLAGS and ACCEPT_KEYWORDS, or any > other options, to ease this situation ? No keywords or CFLAGS will fix the problem. KDE components will error during compile as long as GCC contains the broken visibility code. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Several problems with Gentoo AMD64
On Thursday 10 February 2005 19:42, Jason Harmening wrote: > 1. app-text/ghostscript (espgs) segfaults on about half the postscript > files that are given to it. dmesg output is as follows: WFM > 2. After doing an "ACCEPT_KEYWORDS=~amd64 emerge -u world" earlier this > week, ~amd64 isn't guaranteed to be stable. I don't see any reason to use it for an entire system... > But now when I try to emerge arts, I get an error indicating that simple C++ > files cannot be compiled. Here are the relevant contents of > Would this be a problem with the gcc/g++ installation, or with the arts > configuration? Arts (the same version) had previously built fine for me > with gcc 3.4.2, but I need to remerge it in order to link it with > libogg/libvorbis. Not related to the problem you are having, but don't expect to be able to compile KDE with the more recent Gentoo revisions of GCC. They enable a broken backport of the visibility stuff which breaks KDE. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: KDE 3.4.0_beta1
On Thursday 10 February 2005 09:45, Duncan wrote:
> Luke-Jr posted <[EMAIL PROTECTED]>, excerpted below,
>
> on Thu, 10 Feb 2005 03:41:33 +:
> > on PPC...
> >
> > mkdir -p /etc/portage
> > for d in /usr/portage/kde-base/*; do
> > pkg="${d/\/usr\/portage\//}";
> > echo "${pkg} ~x86 x86" >> /etc/portage/package.keywords echo "${pkg}"
> >
> > >> /etc/portage/package.unmask
> >
> > done
> >
> > That should work on any arch, though it will make a technically invalid
> > package.keywords file. It will work perfectly fine, though. :)
>
> OK, that will /normally/ work fine, and might work fine on all current KDE
> 3.4.0 betas, but as you say, it's technically incorrect (because it's
> telling portage to treat your arch like x86, which it isn't, and that
> can cause "interesting" complications, see below), and it /will/ cause
> problems with some packages, which is why the technotes say don't do it.
Only packages that won't work on your platform.
>
> Here's the deal. Certain ebuilds conditionally build in or compile
> certain features based on the keywords.
Based on USE flags.
> One example I know of, altho it's keyworded amd64 so there'd be no reason to
> use package.keywords to hack things, is xorg.
Nope. It uses USE flags to determine what arch.
> Others would be both mplayer and xinelib.
Those are checking USE flags also...
> Even more commonly, amd64 specific patches are conditionally applied based
> on keywords.
s/keywords/USE flags
> If you tell portage to use x86 (in either form), these tests will be screwed
> up.
If portage is changing my USE flags based on package.keywords, then portage is
screwed up.
> Thus, what one /really/ should be doing before they go trying x86 (in
> either form) in the keywords is verifying that the ebuild doesn't have any
> of these specific tests in it, or at minimum, that if it does, they aren't
> serious issues (an example being the lib/lib64 issue, presently).
As far as I am aware, ebuilds are not supposed to go checking KEYWORDS
themselves.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: KDE 3.4.0_beta1
On Thursday 10 February 2005 03:51, Mark Constable wrote:
> Luke-Jr wrote:
> > mkdir -p /etc/portage
> > for d in /usr/portage/kde-base/*; do
> > pkg="${d/\/usr\/portage\//}";
> > echo "${pkg} ~x86 x86" >> /etc/portage/package.keywords
> > echo "${pkg}" >> /etc/portage/package.unmask
> > done
> >
> > That should work on any arch, though it will make a technically invalid
> > package.keywords file. It will work perfectly fine, though. :)
>
> Spot on, thank you :-)
>
> # ACCEPT_KEYWORDS="~amd64" emerge kde -p
You don't need ACCEPT_KEYWORDS="~amd64" in there after you run that...
Suggestion: emerge -vp kde-meta
--
Luke-Jr
Developer, Utopios
http://utopios.org/
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: KDE 3.4.0_beta1
On Thursday 10 February 2005 03:14, Mark Constable wrote:
> Anyone successfully doing this ?
Yes, but on PPC...
mkdir -p /etc/portage
for d in /usr/portage/kde-base/*; do
pkg="${d/\/usr\/portage\//}";
echo "${pkg} ~x86 x86" >> /etc/portage/package.keywords
echo "${pkg}" >> /etc/portage/package.unmask
done
That should work on any arch, though it will make a technically invalid
package.keywords file. It will work perfectly fine, though. :)
>
> Also, is anyone on this list interested in seeing some
> kind of KDE based audio (and video) focussed liveCD a
> bit like Agnula/CCRMA ?
>
> --markc
--
Luke-Jr
Developer, Utopios
http://utopios.org/
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Making Radeon 8500 Work
On Saturday 05 February 2005 12:59 am, Mike Melanson wrote: > > btw - the 8500 will work without Ati's binary drivers. The 3D won't be > > as fast, but it will work. > > As long as the Xv works, I would be very happy. As my email address > implies, I am heavy into multimedia development, particularly on Unix > (xine and FFmpeg). Xv should work fine without any immoral/proprietary software/drivers with any nVidia or ATi cards. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: warning for sun-jdk 1.5.0.01 & sandbox
On Fri, January 28, 2005 6:39 am, Duncan said: > Dylan Carlson posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 28 Jan 2005 06:40:07 -0500: >> This is because the installer for sun-jdk tries to access /dev/random which violates the sandbox. So, the solution is to emerge sun-jdk without >> using the sandbox feature. e.g. >> >> FEATURES="-sandbox" emerge -v sun-jdk > > That's correct, but sandbox is after all a security related feature, and some of us simply don't like the idea of giving an emerge carte blanche, as root no less, during the compile phase. What if something is wrong and it deletes all of /bin ? (I once had a Mandrake Cooker RPM do something like this. Luckily, I had a copy of that dir recently backed up under a different name, and was able to use absolute path commands to get back up.) Actually, sandbox is more of a precaution for bugs than a security feature. If someone wants to bypass sandbox, all they need to do to bypass it is to ignore the preloaded library, either by manually getting the function out of the libc (dlopen, dlsym; should be compatible with all systems/kernels) or by making the kernel calls directly (specific to whatever kernel the code is designed for). -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: Installing 32 bit?
On Wed, January 26, 2005 1:58 pm, [EMAIL PROTECTED] said: > Luke-Jr <[EMAIL PROTECTED]> wrote: >> I don't care that x86_64 CPUs are compatible with x86. If the price range was the same for a non-x86-based 64-bit CPU, I would have gone with that. I chose x86_64 for its price, not compatibility. > > Good for you. Then you won't mind putting up with the 32-bit support you get with the lower cost. If it weren't for the overhead of 32-bit libraries, no, I wouldn't mind. But I don't have the disk space to have two copies of every library on my system... > >>> I'm a home computer user and the "pure 64-bit" approach has turned out, in practice, to be a PITA, because it is too dogmatic about the 64-bit aspect. >> >> How is that? I am using a pure 64-bit system perfectly fine. No complaints so >> far. > > If it's a PITA for me, it isn't less so because it's no PITA for you. > > One of the problems for me is that Unicon (unicon.org) is not yet supported on AMD64. There is limited support "behind the scenes," but only because I wrote it, and it doesn't keep up with the CVS, and it doesn't support hardened gcc. Unicon is all GPL, LGPL, and public domain material, so this has nothing at all to do with proprietary vs. free software. A single program is no real reason to keep 32-bit versions of all your libraries... Perhaps the ones it uses, but not all of them. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: Installing 32 bit?
On Wednesday 26 January 2005 7:23 pm, [EMAIL PROTECTED] wrote: > Sure, you can use AMD64 to make a pure 64-bit server. But the people > at AMD didn't go to all the trouble of making it possible to run > 32-bit and 64-bit programs together with each other just so people > could make pure 64-bit servers. They'll be happy to see you use it > pure 64, and a pure 64-bit server OS would be great. But Gentoo has > to be what's best in general. I don't care that x86_64 CPUs are compatible with x86. If the price range was the same for a non-x86-based 64-bit CPU, I would have gone with that. I chose x86_64 for its price, not compatibility. > I'm a home computer user and the "pure 64-bit" approach has turned out, in > practice, to be a PITA, because it is too dogmatic about the 64-bit aspect. How is that? I am using a pure 64-bit system perfectly fine. No complaints so far. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] nVidia vs ATI
As always, if you stick to using only m oral software: There are no nVidia card with 3D acceleration. Radeons up to the 9200 models have had 3D acceleration for a long time. Newer Radeons may or may not have working 3D accel; support is in-progress so there should be eventually... Personally, I never use 3D anyway, so I disabled it altogether, but I got a Radeon 9200 just in case I ever need it (like if my fav. games (armagetron & quakeforge) ever run on a 64-bit system ;). On Wednesday 26 January 2005 8:42 am, Mark Constable wrote: > Duncan wrote: > > Well, I guess that's part of buying hardware without free drivers... > > I don't do NVidia anything any more because they prefer software slavery > > to freedom, and I'm not down with that. > > I have nVidia gfx cards and emerge nvidia-kernel after > rebooting on a new kernel "just works" and is one of the > main reasons I use Gentoo. > > I haven't bothered with any 32-bit workarounds but not > being able to use OpenOffice is starting to bite me so > what is the easiest path to get OO up and running on > and otherwise full 64-bit system ? > > (diddling with multilib might be fun but I suspect I > won't get a working OO anytime soon) > > My main question though is... are the ATI Radeon gfx > cards supported well enough now on 64-bit Gentoo that I > can still have acceleration with a no-mess driver ? > > ie; I am about to buy a new machine, should I go for > a Radeon card or stick to some nVidia card that I know > will easily work thanks to the nvidia-kernel ebuild ? > > --markc > > -- > gentoo-amd64@gentoo.org mailing list -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Installing 32 bit?
On Wednesday 26 January 2005 1:45 am, Nathan Brink wrote: > hey, about packages that dont work, how about the nvidia-net package? > > i cant use the integrated netword card in my motherboard with the > amd64 livecd. this isnt terribly bad, because i have a few extra pci > cards, but why would a component integrated into an amd64 motherboard > be masked? > > is there any way i can easily "--force" this package on or, since the > kernel supposedly supports 32-bit moduals, can i compile it in the > 32-bit and still get it working? 64-bit Linux supports 32-bit modules? I was under the impression that only modules matching the arch could be used... -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Installing 32 bit?
On Wednesday 26 January 2005 12:19 am, Duncan wrote: > When multilib is fully in place, /lib, /usr/lib, etc, will all be their > 32-bit default. All the 64-bit stuff will be in the lib64 variants. Quite silly, I think. *Native* libs/bins should be in the default paths. Stick emulation/compat elsewhere. I would suggest using /lib-x86, /lib-x86_64, /lib-ppc, etc and include a symlink from /lib to the native arch. Then, you avoid issues when you have multilib x86 and ppc, both 32-bit. > With the just coming 2005.0, the pieces are pretty much in place, but some > ebuilds are't fixed yet. Thus, the standard 2005.0 profile will use lib32 > and lib64, with lib being a symlink to lib64, for those ebuilds that still > assume lib is the native system bitness libraries. Which should be a correct assumption... > With multilib fully in place, most or all libraries will be compiled > twice, once for native 64-bit (placed in lib64), once for legacy 32-bit > (in lib32 for now, lib for 2005.1). Plugins and the like are normally > instituted as 32-bit libraries, so they'll work normally, with any > applications also compiled as 32-bit. What if you only need 64-bit libraries? You need to install both anyway with a multilib system? What if you want PPC libs also? > However, by mid-year, 64-bit MSWormOS should be becoming more popular, so > 64-bit codecs, plugins, and the like, should also be becoming more > available, and the problems with running 32-bit only binary codecs and the > like in 64-bit mode will be disappearing, because they won't be 32-bit > only any more. Of course, that still leaves the issue of them being > proprietary-only, unfortunately... Of course, none of that affects people who stick to using moral software. Even if this one problem is solved, there will always be disadvantages to using proprietary software. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Stuck on bug, now what? Newbie needs help.
On Sunday 23 January 2005 10:03 pm, kevin wrote: > Now, I'm honestly not trying to be a jerk, but...that's like saying > there's no benefit to stage1. I honestly don't understand the > differences too well, so if I seem way off base, I prolly am... Just > going by the readme, it say's you'll learn more, and have full control > over optimizations w/ stage1. Stage3 is touted as being fastest to > finish... it's downside, is stated as being unable to tweak the base > system. The "optimization" part is more for systems without a stage3, like Pentium 2. With a stage3, you lose the chance to set your USE flags for the system packages. > Are you saying the differences in performance from a stage1 base > system, and a stage3 base system, are negligible? If you want certain USE flags set on your system, you need to use stage1 (or recompile the system later from a stage3) > Really, not trying to be a jerk asking that question, I honestly don't > know It _seems_ to me like having your compiler (that is what you make > (gcc) during the bootstrap process, no?) optimized would have some > non-trivial advantages. All Athlon64 systems at this point, AFAIK, have the same features. Thus, there is no system-specific stuff to optimize for the arch yet. > Again, I'm a newbie, and have to plead ignorance. I've just > read a lot about how things are better and faster when compiled from > source for your architecture (across OS's, not just gentoo)... Generally, this is true... but only when there is a difference between different CPUs for that arch. > so, stage1 was a no-brainer for me. I never thought of working from 2 or 3. A stage2 could be a very probably option. You'd still be able to set USE for your system and the compilers could be recompiled w/ changes in the background once you're up and running. > It sounds like what you're saying is: there isn't a lot of difference in > the core system you end up w/, wether you go w/ stage1 or stage3? Not unless you set USE flags affecting system packages. > > > Now, when you start talking about applications, the ability to pass > > -march and recompiling to the AMD64 native architecture instead of using > > the x86 generic binaries *will* give you a substantial speed-up. > > Yeah, it's those statements exactly, that I hear everywhere in my > computer travels, that make me try stage1 gentoo. That's the difference between compiling for a "supported" arch (x86) and the native arch (x86_64). If you compile things for a x86, it obviously won't take advantage of the features the x86_64 arch provides. > I'm just trying to get my head around this however... it sounds to me > like you're saying from a system standpoint, the "base" system (OS, I/O, > permissions, printing subsystem, networking, etc.) there's very little > optimization you can do (and what's generic and safe, has already been > done in the stage3 tarball). Stage1 optimizations's could almost be > considered dangerous? An x86_64 stage3 will already be compiled for x86_64. It might include x86 libraries also, for all I know. In that case, you would want to use a stage1 if you want a pure 64-bit system (w/o multilib). > When installing applications however, you say there are significant > benefits. This I understand. The Analogy given in the portage manual of > compiling something large like OpenOffice w/ only your window managers > functions (e.g. Gnome, but not KDE), makes a lot of sense to me. I had > assumed it was the same at the Base system level (w/ ssl support seems > non-trivial to me?). Most people who use OO.o install it from a binary package which, unless it has changed recently, would include only x86 32-bit binaries. Actual binary ebuilds aren't too common, and I don't think any are included in the system. > > As a newbie to Linux it's hard for me to sometimes separate things like > the GUI from the base-system in my head... When you talk about the Base > system, I think you have a very different idea in your head than I do? IIRC, the "base system" in Gentoo terminology refers to the part of your system that packages assume exists. For example, plenty of packages need GCC to compile, but many don't actually DEPEND on it. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
Just saw why people might prefer to get a Broadcom, though... $10 for a 802.11g card as opposed to $84 (Orinoco)-- if there were open drivers, I'd get it. :/ -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
On Sunday 23 January 2005 1:29 pm, Mike Williams wrote: > On Sunday 23 January 2005 04:25, Luke-Jr wrote: > > > Do you know a place that sells 802.11g mini-pci nics that are linux > > > compatible? In my case it is because I bought a laptop. > > > > Never heard of "mini-pci"... As far as laptops (CardBus), I'm pretty sure > > Orionico (sp?) work fine... > > mini-pci is a very common interface. > Take an access point apart and you'll see one. They all use a mini-pci > wireless cards, like all laptops with build in wifi. I've seen a lot of APs with CardBus... > > Oh, it's orinoco :) And my mini-pci laptop built-in wireless card works > nicely with it (802.11b mind). > I don't think orinoco is anymore than b either... http://www.proxim.com/products/wifi/client/abgcard/ -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
On Sunday 23 January 2005 4:03 am, Dwayne Martin wrote: > Do you know a place that sells 802.11g mini-pci nics that are linux > compatible? In my case it is because I bought a laptop. Never heard of "mini-pci"... As far as laptops (CardBus), I'm pretty sure Orionico (sp?) work fine... > > -Original Message- > From: Luke-Jr [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 22, 2005 10:08 PM > To: [EMAIL PROTECTED] > Subject: Re: [gentoo-amd64] 64-bit Broadcom wireless works! > > On Sunday 23 January 2005 2:50 am, [EMAIL PROTECTED] wrote: > > x86_64 is now supported with ndiswrapper-1.03-rc3. This means there's > > finally a way to get Broadcom wireless adapters working. > > Why would anyone buy these, I wonder? I can understand Airport Express > coming > in Macs, but that would be PPC, not x86_64... > > > Follow instructions at: > > http://ndiswrapper.sourceforge.net/phpwiki/index.php?Installation > > (be sure "CONFIG_NET_RADIO=y" is compiled into the kernel) > > ...or just emerge Cardoe's ebuild from > http://dev.gentoo.org/~cardoe/ndiswrapper-1.0_rc3.ebuild -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
On Sunday 23 January 2005 2:50 am, [EMAIL PROTECTED] wrote: > x86_64 is now supported with ndiswrapper-1.03-rc3. This means there's > finally a way to get Broadcom wireless adapters working. Why would anyone buy these, I wonder? I can understand Airport Express coming in Macs, but that would be PPC, not x86_64... > Follow instructions at: > http://ndiswrapper.sourceforge.net/phpwiki/index.php?Installation > (be sure "CONFIG_NET_RADIO=y" is compiled into the kernel) ...or just emerge Cardoe's ebuild from http://dev.gentoo.org/~cardoe/ndiswrapper-1.0_rc3.ebuild -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 32 bit environment
On Wednesday 12 January 2005 1:07 am, Beau V.C. Bellamy wrote: > Actually, i'm having this very same problem with the radeon drivers > included with xorg. I'm not sure this is a driver issue or what. I'm at a > loss. I have a few games (like Enemy-Territory) that do not run with > hardware acceleration at all when the kernel is 64 bit compiled. This is > the case even in a chrooted environment. Does anyone have ideas? Check perms on /dev/dri/* -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 32 bit environment
On Tuesday 11 January 2005 12:28 pm, Nick Warrington wrote: > If I do glxInfo I get all the right info about my NVIDIA card > etc etc, but DRI is off.(Before anyone asks, it is turned on in the 64 bit > world). Is this even possible? Last I checked, nVidia doesn't support DRI... -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: x86 emulation and Flash
On Thursday 06 January 2005 10:02 am, Duncan wrote: > Again as Zac mentioned, your alternatives are to continue to run the > 64-bit versions without the plugins, possibly installing them if desired > when the proprietary company gets off its *** and decides to port them, or > you may install the 32-bit compatibility libs, and a 32-bit browser, so > you can plugin the 32-bit proprietary plugins. One other alternative > would be 32-bit chroot setup as outlined in the Gentoo for AMD64 > technotes. (There's a link to them on amd64.gentoo.org, tho it's not as > easy to find as it probably should be, or look at other recent posts of > mine for a more direct link.) Another option would be for someone to write a wrapper that maps 32-bit x86 plugins to any native arch (why not use qemu to support x86 plugins under ppc/sparc/etc at the same time?). The simplest/best way I could think of to do this would be to convert the APIs to a stdio protocol and provide remote-plugin support at the same time. Then it could simply execute the plugin (possibly over SSH et al), have the client run in a full 32-bit x86 environment (or any other environment) and have the server plugin translate the stdin back to API calls. Of course, since I'm part of the group that is against proprietary software for "idealistic" reasons, I'm not going to be inclined to write anything like this myself... though it would be an interesting project to anyone with the free time. -- Luke-Jr Developer, Utopios http://utopios.org -- gentoo-amd64@gentoo.org mailing list
