On Mon, 2006-05-15 at 00:23 +0200, Orn E. Hansen wrote:

Ok, I'm sorry to barge in here, I did rename the thread above. I find this just "bonkers" ... "Linux does _not_ want ...". An AMD64 processor, was designed to be able to run code from both worlds, for the purpose of backwards compatibility.

From the standpoint of PAE 52-bit programs _co-existing_ with 32-bit or even PAE 36-bit programs, _yes_.

But from the standpoint of PAE 52-bit programs calling 32-bit or PAE 36-bit libraries, or 32-bit or PAE 36-bit programs calling PAE 52-bit programs, *NO*. *PLEASE* read my blog article. Please understand how memory models work. This is not a "solvable problem" in software. It is _nothing_new_. It's plagued DOS, various extenders, DPMI, OS/2, Win16, Win32s, Win32, etc... Yes, again, a PAE 52-bit kernel can run _both_ PAE 52-bit and 32-bit or PAE 36-bit programs. But that doesn't necessarily mean the two can work together. Again, program/library memory models are the problem.

It's the user who decides what he wants, not you or I.

Sigh. You _utterly_ missed my point. Sigh. I'm talking about the _technical_reality_ of how memory models work. x86-64 is _no_different_ -- it's just another memory model.

If the user wants to be able to run some 32bit software, then it should be the PRIDE of Linux programmers, to provide the best solution to do so ... not come around, as, telling people to go hide in a bunker, because the GOD LINUX doesn't want it, and so he won't get it.

Sigh. Windows XP x64 is ... guess what? Largely a _32-bit_ OS! You'll often get _better_ performance out of running Win32 applications on a Win32 OS, than Win64 programs on a Win64 OS, because it's still largely Win32! Only now Microsoft is using WoW to do all sorts of real-time call address and object translation to have those 64-bit programs call _core_ 32-bit libraries. And going the other way is even worse. In _all_ cases it's a _major_ performance hit! And it's _not_ "native." All Linux x86-64 releases have been natively made PAE 52-bit. Fedora and SuSE-based distros then ship a limited set of native 32-bit / PAE 36-bit programs, so those older 32-bit / PAE 36-bit programs then work. It is _vastly_superior_! Other distros, like Debian, use a chroot approach, with its positives and negatives. _Both_ Linux approaches are _better_ than Windows XP x64. And from what I've seen of Vista so far, the problem is _not_ solved with it either. In fact, the whole reason for WoW is because Win32 is _not_ "64-bit clean" like the majority of the GNU world. It's not a solution for the problem you're thinking of, but a solution for the problem than Win32 can't be ported to 64-bit. Anyone who has talked to MS Office for MacOS X developers can attest for how 32-bit, data-alignment ignorant, x86-only Microsoft's codebase is. Sigh, _please_ understand what I was saying. You obviously can't recognize that AMD can_not_ solve the issue of programs and libraries using different memory models.

And even though Linux, as of today, is mostly "free" of charge the goal of it is the same as that of any other. To make a living on Linux, or the technology created and proven on it. One would therefore think that the Linux community was about eventually making money on Linux, not help make Windows the only reasonable platform for desktop users.

Have you _used_ Windows XP x64? It's _worse_ than Linux x86-64! WoW is not only a _poorly_performing_ solution, it's not very compatible. And Windows XP x64 is still _largely_ 32-bit -- with all the associated issues. Then again, this whole "Longhorn" thing has been a re-hash of the "Cario" playbook 10 years later. But I won't go there. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Mon, 2006-05-15 at 07:30 +0200, Orn E. Hansen wrote:

The entire arguement of this, was taken back in 8/16, to 16/32, you lost about 20 years ago. The x864 CPU, is basically an old 8088 using it's AH register, that then was extended to be an AX register, that then got extended to be an EAX register. All of which exist in a CS (Code Segment) or a DS (Data Segment) capable of segmenting the memory access down to 16k blocks. All of which currently exist within a built in memory controller that can translate memory access within 4k or 16k space.

All this has _nothing_ to do with how programs using memory models. The CPU isn't the issue, it's the memory models programs/libraries/plug-ins use.

The past years, it has been pretty tiresome to hear the old rhetoric at how Gates and Windows are evil. That they've been "blocking" innovation. The fact of the matter is, that the community of self-proclaimed Gods in the Linux community has done more to block it, than Gates, at late. No no, don't tell me to start providing patches, because even if I did, they wouldn't be accepted by the community. The community hasn't been about "sharing" for about 5-10 years.

I'm sorry, but NT 3.51 "Daytona" is where NT became Chicago's bitch. NT _never_ recovered from that. NT 3.5 was finally a true, Win32 design with minimal need for WoW (unlike NT 3.1). Today, .NET is a joke and Win32 is utterly polluted from Chicago -- and NT 6.0 "Longhorn" is another NT 4.0 "Cairo" fiasco -- almost point-by-point, only 10 years later. NT's RBAC/MAC is essentially useless if you want to run any desktop applications. Patch management on Windows, because of its inter-dependency and integration, is why it's impossible. Microsoft itself pays serious money to Altiris to handle its own patch resolution internally (even if they eventually feed Microsoft SMS or SUS servers). They have ever since half of Microsoft went down because of SQL Slammer -- when "staying current" caused 2 newer patches to uninstall the older patch that would have prevents SQL Slammer. The Microsoft systems being feed from Altiris management didn't go down, because Altiris QA caught that and Microsoft's own QA didn't bother. Something like -- newer patches breaking older ones -- is virtually _unheard_of_ in the UNIX world. Don't get me started on MS RPC handshakes and how Microsoft not only breaks their own security protocols in some patches, but such handshakes aren't even enforced (but Samba enforces them, so things break). The UNIX piecemeal model is far more maintainable and secure. Always has been. Always will be.

Personally, I'm beginning to think Linux is a platform that I should leave by now. Don't like what the core on it is, these days.

GNU is 64-bit clean. Win32 isn't and never has been. That's why Microsoft has to use WoW, again. Digital tried for 10 years to get Microsoft's own tool developers and application division to actually write to "pure" Win32/64 -- and never could. Digital knew NT far better than Microsoft, and even wrote Win64 for them. "Longhorn" is a joke, just like "Cairo" was. You can't have a pure .NET platform when you don't have pure .NET tools -- just like you couldn't with pure Win32/64 before that either. Linux x86-64, as implemented by Fedora and SuSE, works extremely well. True PAE 52-bit programs/libraries, with a good subset of 32-bit / PAE 36-bit libraries and programs (although I have a few complaints). Windows XP x64 is not. And Vista x64 is a mess right now. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

Constantly hearing what can't be done, and running outdated technology gets extremely tiresome over the years. The beauty (and bane) of the x86-64 architectures is that it enables us to effectively transition from 32-bit to 64-bit architecture. The bane is that some [lazy] developers don't want to make their code 64-bit clean. Additionally, 32-bit code running on a 64-bit OS on this architecture may run faster than if it were native. One thing we ran into on Alpha/NT is

On Monday 15 May 2006 4:21 pm, Orn E. Hansen wrote: that we had a mode that allowed X86 code to run under emulation/translation so we had a good application base. The downside was that vendors didn't want to port their code to native Alpha so that we really never got a lot of good native Alpha applications. I would prefer on this net, we try to provide solutions to problems. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Mánudaginn 15 maí 2006 22:46 skrifaði Jerry Feldman:

The beauty (and bane) of the x86-64 architectures is that it enables us to effectively transition from 32-bit to 64-bit architecture. The bane is that some [lazy] developers don't want to make their code 64-bit clean. Additionally, 32-bit code running on a 64-bit OS on this architecture may run faster than if it were native. One thing we ran into on Alpha/NT is that we had a mode that allowed X86 code to run under emulation/translation so we had a good application base. The downside was that vendors didn't want to port their code to native Alpha so that we really never got a lot of good native Alpha applications.

Lot of the issues, are related to compilers rather than actually the developers themselves. But when considering certain commercial stuff, upgrading or cleaning code may be even harder work and more expensive than creating the original codebase itself. While at the same time people using this code, don't want to throw away their investment in the software. Seen from my point of view, there are some technologies that are preferrable. 1) Getting rid of the hour "sleep" time of a desktop Linux, during night hour batch jobbing that is inherent from old Unix and totally reduntant in the modern desktop world. 2) Being able to boot directly into an "image" of the last active state. 3) Being able to optimize code into 8/16/32 bit where possible. 4) Being able to have a single codebase library, so that a library only needs to be loaded "once", so that whenever I start my puny program my puter won't sleep for a whole minutes while waiting for all the libraries to initialize. 4) Being able to use the "backwards" compatibility of the platform, without having to literally boot into DOS. I personally think these are vital technologies to implement, not to push under a blanket and wait for someone else to do the job.

I would prefer on this net, we try to provide solutions to problems. That is my preferred view.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Tuesday 16 May 2006 6:44 pm, Bryan J. Smith wrote:

Yes, in the Windows world -- where intelligent Microsoft architects design good APIs and then Microsoft's own tool developers and application divisions _ignore_ them (despite Microsoft always blaming the problem on ISVs, it's Microsoft itself) -- it's a major issue (and always has been).

But the IEEE POSIX and X/Open SUS has addressed the split 32-bit/64-bit memory model on Alpha, MIPS, SPARC and now x86-64. There is no reason not to follow the specifications, and the GNU compiler targets do exactly that.

Compilers and toolchains will _never_ solve memory model issues. Just as an aside. There are a number programming memory models in use. In the Unix?Linux world, we use LP32 for 32-bit programming where long integers and pointers are 32bits. In the 64-bit world, we chose the LP64 model where long integers and pointers are 64-bits and integers remain at 32-bits. I say we as this is the model that Digital chose for Tru64 Unix (previously Digital Unix and OSF/1) back in the early 1990s. http://www.unix.org/version2/whatsnew/lp64_wp.html

LP32 and LP64 are not the only models in use. Microsoft chose LLP64 which defines both the int and long int datatypes as 32-bits using only long long and pointers at 64-bits. (Note that all of the models define single-precision floating point as 32-bits and double precision floating point at 64-bit (IEEE 754 standard). One thing that comes into play here when talking about memory models is virtual memory. A 32-bit program can only directly address 4GB of data (segmented into stack, text, initialized data, heap, and mmapped segments) where a 64-bit program can address 16 exabytes. (Certainly there are physical limitations of the chips - PAE-52 for instance), and the 2.6 kernel permits addresses up to 64GB. There are different needs in the community. Today's servers have need to much larger physical memory, especially with multi-core, multi-CPU architectures. The AMD-64 and EM64T architectures work well on the desktops and in many server configurations where the larger servers need architectures, such as IA64. The IA64 has a much different physical memory model than does the X86-64 chips, but I'm not going to get into the architecture. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Sunday 14 May 2006 11:40 pm, Bryan J. Smith wrote:

Only now Microsoft is using WoW to do all sorts of real-time call address and object translation to have those 64-bit programs call _core_ 32-bit libraries.   Just for historical purposes, WoW has been around for a long time since it was also used in the 16-bit to 32-bit world.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

PAE 52-bit Bryan, I do not see any reference to PAE 52-bit in the AMD 64 Architecture

On Monday 15 May 2006 11:05 am, Bryan J. Smith wrote: programmer's manual. Can you point me at a reference to this. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Mon, 2006-05-15 at 14:34 -0400, Bryan J. Smith wrote:

Processor Address Extensions (PAE). It's all over the first two AMD programmer manuals. Read the early tables on the different modes the AMD x86-64 processors support. You'll see the following ... x86-64 implements a 7-layer model using 52-bit registers with 48-bit flat addressing (so it's compatible with the 16-bit segement + 32-bit offset registers of the i486 TLB, which is capable of 48-bit virtual addressing) on a 40-bit capable physical platform (the 40-bit limitation comes from the core design of the original Athlon, based on the 40-bit interconnect of the Digital Alpha EV6 platform). It is compatible with legacy Intel Processor Address Extensions using 36-bit registers in 32-bit addressing model on a 36-bit capable physical platform (using paging). AMD _only_ covers how to enable x86-64 "Long Mode" in the kernel with the resulting 52/48/40-bit model. It also talks about how x86-64 "Long Mode" is able to run newer 48-bit as well as old 32-bit flat memory model programs.

This is introduced in pages 4-5 of Volume 2 "System Programming": http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/2459... Page 5 moves from talking about the legacy PAE to the use of a new, 52-bit PAE mode for Long Mode. It continues through page 13 of how a _kernel_ can support programs and libraries of any existing memory model. AMD (as well as Intel for that matter) do _not_ even attempt to tell OS' how to solve the issue of larger issue of programs and libraries of different memory models using each other's values or calling each other's routines in _any_ of its (nor Intel's) manuals. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Mon, 2006-05-15 at 15:53 -0400, Jerry Feldman wrote:

Thanks for the reference. I had been using Volume 1 or the programmer's manual since it deals with the actual instructions. I don't see anywhere in Vol. I where PAE is mentioned.

Volume I over-simplifies many details. It's not actually 64-bit. It's 48-bit, using PAE 52-bit paging. But those details aren't typically of any interest to users or application-level developers. But they are pertinent to how Linux x86-64 works, as well as system-level (including library) developers. Someone was getting confused why can't 64-bit programs use 32-bit libraries and vice-versa.

The processor vendor (AMD/Intel/...) should not really get into telling an OS how to interoperate the multiple memory models.

Correct. But it *IS* important that people know how it actually works.

Note that a process only sees virtual memory and the specific registers of its memory model. 32-bit programs effectively think they are on x86-32. Maintaining multiple libraries has been around the Unix world for a very long time where some vendors maintained 16-bit and 32-bit libraries.

Correct, that is how the problem is addressed. Now we've just added

The bottom line with the 64-bit X86 architecture is that a 64-bit operating system running in long mode can enable native 64-bit and 32-bit applications to operate.

Again, big-ass asterisk on the "64-bit." ;->

And for terminology purposes, the AMD64 implements 16 64-bit registers with 64-bit virtual addressing. the PAE-52 comes into play with physical addressing.

It's actually 52-bit. If you read the "fine print" in Volume 2, the "flat 64-bit" model isn't implemented yet. ;-> Again, if it was, then the x86-64 would be operating in a mode that is not compatible with the i486 TLB. Such a "flat 64-bit" kernel could _not_ execute 32-bit or PAE 36-bit programs, libraries, etc... -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On 5/15/06, Michal Hlavac wrote:

Hello Mat,

flash player in firefox works for me... strange is that flash player doesn't works in konqueror... And I have installed flash player package... I have AMD Turion(tm) 64 Mobile ML-40.

miso

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

So are you running the 32-bit OS version... or are you running 64-bit OS with a 32-bit application. From my own understanding there is no 64-bit flash player. :( I've found the 'mixed-mode' a PITA when trying to update packages. :( My gut feel is just to run the 32-bit version in the interim until we get some of these apps over eventually to 64-bit. A shame... but much cleaner. I do understand the processor/library reasons for this. However from an end-user viewpoint it's frustrating to say the least. Also try explaining it to relos.. with their shiny new 'linux' about 64-bit binaries and 32-bit binaries... particularly when they are computer novices and use Suse for Web-browsing and Email. (really!) -- Matt Bottrell mbottrell@gmail.com

On Thursday 18 May 2006 11:24, David Bottrill wrote:

On Thursday 18 May 2006 15:45, Matt Bottrell wrote:

...

On 5/15/06, Michal Hlavac wrote:

So are you running the 32-bit OS version... or are you running 64-bit OS with a 32-bit application. From my own understanding there is no 64-bit flash player. :(

I'm running a 64bit install, and flash works in Firefox which claims to be 64bit. This is also true for Java and Realplayer. So unless SUSE have done some magic then all the apps are 64bit.

Ummmm.....I am not questioning what you have said, but are you sure?? And if what you have said is true, I for one want to know how you did that so I can do it too. How did you install Firefox and how do you know it is 64 bit. Bob S.

On Fri, 2006-05-19 at 07:22 +0000, David Bottrill wrote:

I installed from the X86_64 CDs thats all...... If you select Help > about it firfox it gives you the architecture. It says IIRC i686 (X86_64).

i686 = Pentium Pro, 32-bit (or 36-bit PAE) -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Fri, 2006-05-19 at 12:31 +0000, David Bottrill wrote:

So do you think then that (X86_64) means it's detected it's running on an 64bit O/S but is actually only a 32bit app?

Yes! You are running the i686 (32-bit/36-bit PAE) version of Firefox. You are _not_ running the x86-64 (48-bit/52-bit PAE) version. Is there a document out there on how YaST handles selection of select i586/i686 packages under x86-64, _including_ ensuring _updates_ are handled? This is one of the reasons I'm leaving Fedora Core x86-64, Red Hat doesn't bother to include things like Firefox built to 32-bit for x86-64 (even though it does HelixPlayer and others). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Fri, 2006-05-19 at 09:01 -0400, Jerry Feldman wrote:

Actually, the x86_64 bit version of an application is built for 64-bit virtual. The 48-bit/52-bit PAE is applicable when talking about the OS's virtual memory manager, paging, and TLBs. An application built for x86_64 (or Alpha or IA64) will have a full 64-bit virtual memory address space

That's the standard programmer line. But the binary is very much built _explicitly_ for 48-bit/52-bit PAE. We don't know if they will run if and when AMD implements a _true_ "flat" 64-bit mode. If you read the fine print in AMD's own manual, it doesn't exist yet. So there's no guarantee the binaries will be compatible. That's why I differentiate.

as well as access to the full 64-bit registers.

Yes, non-address registers are 64-bit. There's a huge difference between what the "programmer" sees and what the "system programmer/organization" actually does, _including_ the resulting object code itself. ;-> -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Fri, 2006-05-19 at 10:29 -0400, Jerry Feldman wrote:

Again, the binaries built by the compiler use a flat 64-bit model.

From the programmer's standpoint, but not the object code from what I've seen. Or let me re-phrase that, there is no guarantee that the object code that runs on 52-bit PAE will work on future AMD/Intel "flat 64-bit" platforms.

Remember, that the binaries are built for virtual memory and they have a full 64-bit memory model.

Again, from the programmer's standpoint -- Application Programmer Interface (API). I'm not talking about programmer, I'm talking about Application Binary Interface (ABI) compatibility. Whole different ballgame! And you've really over-simplified the compatibility here. It is _not_ easy to create a 52-bit PAE to 32-bit/36-bit PAE translation so object code of each can link against the other.

The general purpose register set contains 16 64-bit registers that are used for both data and for addresses.

Because you can fit a 52-bit address into a 64-bit register. ;->

The VM provides the appropriate mapping between the virtual address and the physical address.

The model _is_ 52-bit PAE, using *48-bit* addressing -- _not_ 64-bit! That's the object code last time I checked!

If a binary is explicitly built for features of a specific chip, it probably will not be compatible. This has always been an issue. In general, when building an application (or an OS) you build it for the target deployment. In the case of x86-64 Linux distros, you build for the generic x86-64, not to include specific AMD or Intel extensions.

But x86-64 is _not_ "64-bit flat" in object code.

This is true. The programmer does not concern himself with the specific memory models. The system programmer may be concerned with the underlying hardware. The application programmer sees a full 64-bit virtual environment, especially if he/she is using a high level language (including C).

But C _becomes_ object code. C is API. Object code is ABI. _Huge_ difference! -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Fri, 2006-05-19 at 11:23 -0400, Jerry Feldman wrote:

There is never that guarantee, but there is always some work to provide a certain amount of binary compatibility. Neither AMD not Intel is going to extend this architecture in such a manner as to render existing code unusable.

Yes and no. Again, understand there is a _hard_ 48-bit/256TiB physical addressing limitation with the current 48-bit pointers and 52-bit PAE addressing. 256TiB is _not_ a lot of memory in 5 years. So to overcome the 48-bit/256TiB limitation, AMD has to _break_ i486 TLB compatibility. So _any_ kernel that implements such a memory model that _breaks_ the 48-bit/52-bit PAE model that was designed to _explicitly_ support 32-bit/36-bit PAE programs. So, YES they will _break_ compatibility on the same OS! The solution is to use virtualization. The architecture will support greater addressing than 48-bit/256TiB in this new mode, which is what the "supervisory" OS will use. But then the architecture can support "instances" of 48-bit/52-bit PAE, 32-bit/36-bit PAE, etc..., which will run 48-bit/52-bit PAE, 32-bit/36-bit PAE, etc... OSes underneath. In fact, Microsoft's _core_ compatibility effort is going to leverage this in a future Vista release. So, no they won't break compatibility -- using virtualization.

The ABI is defined through a series of calling standards. ABIs can get complicated, as you mention. Before we had defined ABIs, it was very difficult for a COBOL program to call a FORTRAN library. For the most part, programmers had to write bridge code in assembler. The ABI not only goes into how to call a procedure, but also how symbols are defined. In C++, it is important that the symbols are all mangled in the same way. This is extremely important with dynamic shared objects (.so). it would be interesting if GCC used a different mangling algorithm in their compilers than Intel does in theirs.

Object code for x86-64 is flat 48-bit pointers then used in a 52-bit PAE model. Object code for i486/586/686 is segmented/virtual 48-bit pointers used in a flat 32-bit or extended 36-bit PAE model. The pointers are _not_ compatible in calling each other. The only compatibility is that the OS, controlling the 52-bit PAE model, can run 36-bit PAE extended and 32-bit flat applications, as well as newer 52-bit PAE programs. This is because addressing is always 48-bit, even if not normalized the same way. To break the "hard" 48-bit/256TiB addressing limitation, _none_ of these programs would run under it. That's where virtualization is going to solve the problem. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

On Thu, May 18, 2006 at 07:05:28PM -0400, Bryan J. Smith wrote:

On Fri, 2006-05-19 at 00:45 +1000, Matt Bottrell wrote:

...

I've found the 'mixed-mode' a PITA when trying to update packages. :( My gut feel is just to run the 32-bit version in the interim until we get some of these apps over eventually to 64-bit. A shame... but much cleaner. I do understand the processor/library reasons for this. However from an end-user viewpoint it's frustrating to say the least. Also try explaining it to relos.. with their shiny new 'linux' about 64-bit binaries and 32-bit binaries... particularly when they are computer novices and use Suse for Web-browsing and Email. (really!)

I don't know why Novell and/or Red Hat can't just come up with a set of select packages that are shipped as i386/i586/i686 binaries in the x86-64 version and _not_ ship any x86-64 option for those select binaries. Just leave those select, subset of packages as i386/i586/i686, _period_.

I've now experienced the same "update hell" on SuSE Linux 10.x x86-64 as I have been dealing with on Fedora Core x86-64 (although at least SuSE puts the option for i586 on the same CDs/DVD as x86-64).

Sigh, I'm getting really tempted to fork my own, x86-64 only distribution of Fedora (or maybe even OpenSuSE), using my extensive experience in running Fedora Core x86-64 distros with a complete 32-bit Firefox/multimedia stack over these past 15 or so months.

We do this for Firefox. Ciao, Marcus

On Fri, May 19, 2006 at 10:53:08AM -0400, Bryan J. Smith wrote:

On Fri, 2006-05-19 at 16:06 +0200, Marcus Meissner wrote:

...

We do this for Firefox.

But you _also_ ship Firefox x86-64, and other components as well.

We do not ship Firefox as x86_64 RPM since 9.3. You can _download_ it from the Mozilla projects directory, yes, but this is not supported.

That can be confusing for many, as well as updates.

Now I'll be the first one to say SuSE Linux x86-64 is _better_ than Fedora Core x86-64 at this. But it still could use some refinement.

Is there a "step-by-step guide" to guaranteeing browser/multimedia bliss using i586/i686 binaries/libraries/plug-ins under x86-64, while everything else is x86-64?

Use KDE and konqueror. The 64bit one uses a 32bit wrapper nspluginwrapper that runs plugins. Ciao, Marcus

On Saturday 20 May 2006 05:12, Bryan J. Smith wrote:

On Sat, 2006-05-20 at 16:31 +0200, Marcus Meissner wrote:

...

We do not ship Firefox as x86_64 RPM since 9.3.

It seems to default to the 32-bit binary. But I swear I saw it -- but maybe I just saw it as an option in the Internet directories?

...

Use KDE and konqueror. The 64bit one uses a 32bit wrapper nspluginwrapper that runs plugins.

Hmmm, any reason Firefox can't do the same? That might be nice.

-- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own

Just tried Konqueror with the 64 bit mplayer plugin. got sound but no pic. x86-64 mozilla can't see the plugin and neither can firefox 1.0.6 with the (x86-64) add on note in the "about ff" screen. then i tried real player, mozilla and kongi can't find it, firefox does. yea, i know, i will play with links to various directories later, but it was supposed to work without manual intervantion. later i will even play with src rpms, if i have the time. That's in 10.00-OSS-stable, upgraded to the latest updates. had much better luck with 9.3 in multimedia. i don't think i am the exception. i just wish someone puts together a multimedia howto/what-to for x86-64. in 10.0 and/or 10.1 thanks, d.