With SuSE’s 64bit Linux OS out the door sharply on the heels of AMD’s Athlon 64, Chris Schläger, Director of Distribution Development, gives us the low-down on why the 64bit SuSE Linux 9.0 Desktop operating system is the only choice for making the 64bit leap. Also on hand to offer their wisdom were Malcolm Yates, SuSE’s Strategic Alliance man, and Marketing Director Jasmin Ul-Haque.
SuSE’s Schlager Tells the 64bit Linux Story
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Hasn’t Linux been 64 bit on Alpha and SPARC for years? Why is 64 bit Linux news?
I know the BSD’s have been running 64 bit on Alpha and SPARC for years, Solaris and TruUNIX(?) for even longer.
64 bit has been around for over a decade, why all the fuss?
Did you read the article? They make numerous references to Alpha and PowerPC (IBM, not Motorola), and how it made everything easier to port.
And they say as much in the article, namely that the port was so easy because GNU/Linux has a tradition of supporting 64 bit platforms. But unlike Sparcs and Alphas it’s aimed at the high-end consumer. Granted, there was a time when the Alpha almost became a consumer level CPU, but this died with MS ceasing support. So, that’s the fuss.
BTW, it is TRU64.
Of course linux has been 64-bit for a while, but i don’t know many family computers that are running on SPARC or Alpha. It seems like a lot of forum-dwellers are making it seem like the home/desktop move to 64-bit isn’t noteworthy. What’s the deal with that?
Linux on x86-64 is noteworthy because it means AMD64 is ready to be adopted on a desktop level (at least for powerusers).
*BLINK*… what is different about 64 bit AMD vs. 64 bit Spark / Alpha? As Mike said you would have to be more than a little bit DULL to not realize the HUGE difference. Anyone ever hear of a little company called Epic Games? They make a ‘little game’ called Unreal Tournement. There Just happens to be a 64 bit port of this game, and the company just happens to be VERY excited about AMD64 bit. Now not only Epic but many other GAMING companies can leverage the big boost that 64 bit will give in makeing games, And for high end gamers who Just happen to be DESKTOP USERS those benefits just get that much better. If any of you are DULL enough to believe that games are not consumer level i pity you. Believe it or not, 64 bit is going to Hit Hard – and sooner than many ‘blithering idiots’ seem to think. Just my .02 cents worth. Pardon the strong language… /grin
P.S. Epic was just one of MANY examples i could very easily given…open your eyes people!
Shuttle just came out with the SN85G4 with the Athlon 64! : )
Shuttle + Linux = mmmm mmmmm good!
What about something like Wine? Not being the most savvy person when it comes to wine (or it’s derivatives), I have three questions when it comes to wine.
A) Could wine be compiled as a 64 bit program?
B) Would wine’s compatability and stability remain in tact?
C) Could we see a performance boost as a result of a 64 bit version of wine (running 32 bit windows applications).
The simple answer is no (to the last question at least), but I mean… if wine could make use of those extra and extended registers and address space – couldn’t there be some improvement? Even if it was something as simple as running more smoothly?
*shrug* I’m probably thinking too much emulation-wise. Afaik wine works much more simply than that… In other words, wine utilizing the advantages of 64 bits isn’t going to improve performance in the WIN32 program itself. I’d be kidding myself to think it could make those programs like psudo 64 bit programs… But I’m no expert, so I thought I’d ask anyway:)
Anyone who knows the mechanics of wine fairly well care to comment or answer my questions?
While WINE itself may run just a bit faster because of the increase in registers, and other little things, the applications themselves are not emulated, but executed, so, they’ll only run as fast as the processor can run legacy x86 code. There have been projects to get Wine to run on non-x86 processors (using bochs to emulate the cpu), so it should have no real problems running on a 64bit CPU.
For me, the nice part about having consumer level 64bit chips, is that it’ll force coders to stop assuming that pointers are 4bytes, cause that’s the main reason for apps not being properly portable, so more apps will work on my alpha
Great interview and very informative. It is nice to know how the 64 bit saga has come to pass. I cannot wait until they come out with the first 64 bit Athlon, I will be one of the very first adopters ( Adapters ) and I will use nothing else but SuSE Linux 9
There are two parts to wine:
Replacements for Windows DLLs: These could not be compiled as 64-bit libraries because the Windows apps would still be 32-bits. 64-bit libraries cannot be linked to 32-bit apps.
A PE loader/system-call interceptor: This could be compiled as 64-bits, in theory, but there would be rather little speedup from this.
Lastly, WINE apps couldn’t make any use of the larger amount of memory, so the overall speedup would be pretty much nil.
Well the alpha was the first official port after x86 back in the days with kernel 2.0, last i remember linux had support for several 64bit arch.
Alpha, Sparc64, Mips64, IA64, AMD64, SH64 and s390x
on slightly related news (well linux news) was looking at Linus bitkeeper log just there, seems like the BSD “jails” system for processes is been introduced into 2.6 (there’s an inital patch), then again i could be reading the changelog wrong
http://linus.bkbits.net:8080/linux-2.5/ChangeSet@-2d?nav=index.html
“[PATCH] syscall number for vserver
Vserver is a patch that implements BSD jail style virtual host semantics
inside Linux, where every process not only runs in its own namespace (it
reuses the chroot code for that, should switch to CLONE_NEWNS for 2.6),
but also its own hostname and IP address as well as its own view of
/proc.
Because of that added functionality, it needs more than what is
available in the LSM framework (which can only allow/deny permissions,
not alter return values).
The source code has been running stable for the last few years and is in
use at quite a few service providers. The Fedora project also wants to
use vserver for their build system. However, vserver for 2.4 just tacks
their syscalls onto the end of the syscall table and the userland tools
find those “dynamic numbers” somehow … EWWWW.
For 2.6 I’d like to do things right. At the moment the vserver patch
has sys_new_s_context and sys_set_ipv4root calls, but since we’ll
probably end up getting an ipv6 call too and people are planning future
functionality, I guess it would be more appropriate to multiplex these
through one sys_vserver patch, in the same way sys_ipc works.
For your reference, you can find more information about
vserver on these pages:
http://www.13thfloor.at/VServer/
http://www.solucorp.qc.ca/miscprj/s_context.hc
I estimate the project has about a dozen developers now. We are
planning on making the implementation for 2.6 fairly lightweight,
reusing infrastructure from other code where possible and only doing
things through sys_vserver where there is no other way.
This small change just adds sys_vserver to the syscall table.”
*sigh*
Actually, Tim Sweeney himself (Epic’s chief engineer) noted that 64-bit wouldn’t necessarily improve things for regular users in the short term – what he did say, however, is that the content generation tools of Epic’s *next generation* technology *might* require 64-bit due to memory demands. That’s all.
Actually, Tim Sweeney himself (Epic’s chief engineer) noted that 64-bit wouldn’t necessarily improve things for regular users in the short term – what he did say, however, is that the content generation tools of Epic’s *next generation* technology *might* require 64-bit due to memory demands. That’s all.
Which would make sense considering that most people are far off from buying more than 4 GB of memory. In the future it will be more common to have so much memory but those days are at list one CPU-generation away.
Ok — i have heard that EPIC is bringing out a UT for 64 bits.. Why do I need a 64 bit version of a game? Will it really make that big of a difference? Are current 32 bit games held back by “old” technology?
This is just a question. I know I can see great advantages for 64 bit in 3d apps, and video apps, where we routinuely access and process large amounts of data…
but for the regular home consumer, do they really need 64 bits? or is it really just an enthusiast-targeted “geek toy”?
John, I am most certain that you were the first to ask what good a 586 would be over your 486 when it arrived.. never mind. 🙂
As for Epic, I think this is really some sort of fetish with their UT-line of games. You will not find a second fully-blown game beside UT that supports more platforms. They even have a QNX-version for the hell of it (Q3A only has a demo on QNX, IIRC)! I think they want the 64-bit because it “can be done” and to be the first. After all, there is always the challenge with the Quake-line of games from id, who have a long tradition of being multiplatform..
The 64 bit port was mostly for AMD so they could show a fully functional 64bit ‘game’. Tim in that interview made it plain there were no special 64 bit optimizations. He also stated that this port was in fact running quite fast. Another thing he stated was that in the very near term 64 bit on the cunsumer desktop would be limited due to apps / games available. He stated more than once however that the Making of games would become MUCH better for gaming companies due to the added headroom that 64 bit brings to the table. You can expect ports of major games to begin hitting in Q3-Q4 of 2004. The AMD 64 processors are making quite a splash. John need is subjective- the short answer is no you dont actually Need 64bit computing, however…about the middle of next year you will begin seeing initial gaming benchmarks of early beta ports that i believe will be an eyeopener for alot of folks. AMD bet the their business on the New 64 bit athlons catching on much faster than conservatively stated. Not To Say they will sink if it dont happen, just that the exec’s ‘privately’ believe the early adopter Performance Sector will take serious notice. Personally my planned system upgrade just happens to be Q2-Q3 2004. Just about the time you WILL be seeing some very interesting things happening in the new x86-64 world. /grin