I haven't seen a table or something, and there's probably no
precise answer to your question for the overall "market".
But I guess, the market analysts have such figures, and
probably you can "buy" their analyses. They usually count
sold boxes of the top vendors, like IBM/Lenovo, HP, Dell,
Fujitsu-Siemens, Acer and so on.

So much for the hardware. But what about the popularity of
64-Bit operating systems? (How fast) Is it growing?

Certainly some folks like IDG or Gartner of GfK have some
figures available, and, of course, it's possible to count
sold boxes for commercial operating systems like MS Windows,
Apple MacOS/OS X. Also, one might count downloads of *nix
systems. But noone is willing to take the effort to count
downloads for 100+ Linux and *BSD systems, just to find out
what share the 64-Bit version has within the estimated 2%
overall market share of *nix.

On the other hand: How was this figure actually estimated,
und what is market share? Is it the number of installed
systems or the number of users or is it turnover?
And how can anyone count any of these for open source
products that are downloaded anonymously from various
mirrors?

As everyone will know, many large companies had relevant
parts of their business, like web sites and even shops,
running on Linux or BSD systems, without actually knowing
it. Who counts guerilla installations?

And, BTW: What does 90% market share of MS Windows
actually mean? Software that runs quite well on XP sometimes
fall short of running on Vista. Is it really fair to count
two obviously "incompatible" systems as one?

And how many users are working in parallel on a guerilla
Linux or BSD box, compared to a Windows based server or
desktop system? Who counts all this?

Maybe, if someone did, we would possibly have to redefine
the term "market share of MS Windows", as it might turn
out not to be quite as big as it seems today. Depending
on what you actually compare. If you count pre-installed
systems on OEM products, then there's is no debate, of
course. But this won't tell you a thing about how these
boxes are used. E. g., many people have multi-boot
installations. They bought a Windows box and installed
a second system, Linux or BSD or whatever they like.
The market analysts will never know about this. They
only count the pre-installed systems.

Having said all this, the sales figures of 64-bit systems
from Microsoft and Apple should give an indication, and I
am shure they are available somewhere or can be asked from
the vendors.

gargamel

I did a bunch of google searches using many different variants of 64 bit and usage. I couldn't find anything at all about numbers of actual usage for 64 bit OS's. I gonna keep looking again later - there has to be something on it.

hey, happy new year and etc....


Nops.

neither me. I am 41.

Hey-Suess! I hope you are wrong.
It won't be much longer before everything goes 64bit. All the CPUs being sold today, and for sometime now, have all been 64 bit and the software is slowly catching up. I would think it will happen just as it did in the transition from 16 to 32 bit, i.e., in a few years "new" 32 bit software will be hard to find.

The BIG reason for this was the desire to have even more memory on my system than allowed by the 32-bit kernel. So I installed the Slamd64 kernel. Now, I also have a Slamd64 box as well. But I wanted to keep this one as 32-bit, for many reasons. But mostly because there are many applications that aren't available as 64-bit. I will be looking into recompiling as many of the packages I have from Slacky.eu in 64-bit format. They simply have too large of a repository to ignore. And if I could get others to assist in rebuilding that repository to 64-bit, I would be happy to donate my build system to that purpose. And by build system, I mean my liquid-cooled quad-socket server.

Xavian-Anderson Macpherson
Shingoshi

Attached Thumbnails

 

Correction: There are few applications that aren't available as 64-bit. Also remember that slamd64 is multilib, you can run 32-bit programs just fine as long as the 32-bit dependencies are met.

For slamd64 builds check here:
http://wiki.github.com/JoshW/slamdbu...uilds-projects
And there's also this python script that converts slackbuilds to slamd64:
http://git.strangeworlds.co.uk/?p=sb...lob;f=sbo64.py
and also see here:
http://wiki.github.com/JoshW/slamdbu...org-conversion

Typically those will be closed-source binary-only pieces of software (corporate software but games as well). I can't think of any Open Source software that won't build on 64bit Linux.

Fortunately, two pieces of binary-only software that many people use have recently become available for 64bit Linux: Sun's java runtime (including a working firefox browser plugin) and Adobe's flash player plugin for web browsers.

All my SlackBuild scripts at http://slackware.com/~alien/slackbuilds/ are 64bit ready. They need no modification (apart from the definition of $ARCH) to be used with slamd64. Some software will need patches to fix 64bit incompabilities. If you find one of my SlackBuilds needs a 64bit patch, just let me know, send me the patch and I will add it.

Eric

Thanks, that's good to know, I didn't know you added support for 64-bit to your slackbuilds. I've also noticed that all the 12.2 slackbuilds on slackbuilds.org have support for 64-bit.

Being that I've already installed a 64-bit kernel from Slamd64 on my Slackware system, I'm thinking of taking this a step further.

What if we look at Slamd64 in reverse. Instead of building a 64-bit OS that can run 32-bit binaries, what about simply adding the 64-bit functionality to an existing Slackware system. What I mean is this. Instead of using Slackware's glibc, what about using Slamd64's glibc package set instead. I'm going to create a chroot for testing this idea and see what happens. I will install only those packages that I know I need for a basic system in Slackware. Doing pretty much the same thing as would be done if you intended to use NetBSD's pkgsrc in Slackware.

The point would be to find out how little of Slamd64 would you need to install in Slackware, to keep full functionality of the original Slackware 32-bit package set. From what I understand, this may cause real problems. Since Slamd64 does have a glibc-compat (or something like it) for using 32-bit packages in Slamd64. It would be much better, if we could simply compile glibc to support both 32-bit and 64-bit in one single package, instead of having a compat to get around this.

If anyone else has already tried this, I would like to know what their results were. I know from experience, that Slackware can be upgraded to Slamd64, by simply changing the repositories for your packages. That's precisely what I did to move to 64-bit, two years ago. And aside from some configuration changes, it worked very well. Considering that it was advised not to do.

If something like this (using a modified glibc) would work, no one needs to wait for Pat to make up his mind about what should be done here.

Xavian-Anderson Macpherson
Shingoshi

Ok. So I have the 64-bit kernel working just fine. But now there are issues which appear when building packages. Having a 64-bit kernel doesn't create problems with running 32-bit applications. That's what I'm doing right now. But when I want to build something, let's say like kvm which builds a kernel module as well as binaries, the modules need to be 64-bit, while the binaries need to be 32-bit.

Does anyone have any ideas as to how to resolve this? The highest priority here is to keep Slackware functionality. Meaning the basic system must be 32-bit. The 64-bit components should only be an addition to the existing 32-bit foundation. Doing this, removes the necessity to have a 32-bit compatibility layer as is done with Slamd64. Instead, the compatibility layer would be to run 64-bit applications, on top of a 32-bit system running with a 64-bit kernel. But since the kernel is 64-bit, there should be no need for a 64-bit compatibility layer there either.

So, let's hear what ideas some of you have on this.

Xavian-Anderson Macpherson
Shingoshi

Personally, I think what you're doing makes absolutely no sense.

There is no use in running a 64-bit kernel with 32-bit software, it just complicates things to no end.

The compatibility mode is simply an option in the kernel that allows a 64-bit kernel to accommodate 32-bit software as long as the dependencies are met. However, do note that 32-bit programs gain NO benefit from being run in emulation mode by a 64-bit kernel, in fact there is likely a slight overhead for doing so.

So, just do what makes sense, either stay with 32-bit Slackware or install 64-bit slamd64 which will allow you to run 32-bit apps that have not yet been ported.

1. You may not know what you're talking about.
Answer: It is better to run a 64-bit kernel to make use of larger memory footprints as made possible by the newer motherboards running 64-bit processors. Others say 32-bit applications actually run faster in this mode than not. A 64-bit kernel is also better than PAE on i686. My motherboard in this machine has 8GBs of ram. My other motherboard in my Slamd64 machine has 16GBs of ram. Running a 64-bit kernel means that I should be able to chroot into a 64-bit system (though I haven't tested that yet). I can't do that with a 32-bit kernel (that I do know)!

2. I'm not the only one doing this. And in fact I talked it over with some others on the Slamd64 irc (#slamd64) channel who do this themselves (before attempting it). The fact that you don't know much about this, is not surprising. You're just one of many who don't.

3. I wasn't asking for your permission or acceptance.

Ok, and here's 4!
4. I'm not going back to running a 32-bit kernel. I've already seen benefits I'm not willing to give up.

Xavian-Anderson Macpherson
Shingoshi

And I wasn't offering or granting it. But, I still don't see the point of doing this, why you are doing this.

Quote:

Originally Posted by H_TeXMeX_H And I wasn't offering or granting it. But, I still don't see the point of doing this, why you are doing this.

I see this as a possibility for regular Slackware users to feel more comfortable in transitioning into a 64-bit system. I'll tell you right now, I'm still working out the details here. I was actually in the process of writing my main developer when I checked here. Basically, here's the notion.

People don't like change. Even people who are Slackware users. You should have figured out by now, I'm one of the exceptions. I like the challenge that comes with change. It keeps me mentally sharp. At least I hope so. But too many become so comfortable, that when change is even required, they're simply too complacent to move forward. I try not to fall prey to this. My simple motto is "Adapt, or Die!

So two almost three years ago, I didn't hesitate when I had the chance to run a 64-bit system, to switch completely from Slackware to Slamd64. Much to the surprise of Fred Emmott, I even did a straight upgrade using slapt-get, from one to the other. All I did was change my repositories. There were of course some hitches. But they were mostly workable. So now, I'm wanting to try this from a different direction. I installed the 64-bit kernel only for the larger memory footprint. But now, I'm faced with other issues, that only those who regularly build packages would find themselves faced with.

That's what I was writing my lead developer about before I started writing this. I'll quote him in his response to my initial email notifying him of my latest move.

Quote:

Ahh, leave (it) to you (to) find a snafu. I have discussed the ARCH and get_flags routines with a couple of my 64-bit users. But your situation brings another curve to the equation which relates to some thought I've been having the last few days vis-a-vis cross-compiling using src2pkg. ARCH really only sets the ARCH part of the package name. And it should be left flexible if for no other reason than when creating 'noarch' packages. The actual CFLAGS, LDFLAGS and compiler options are derived dynamically using uname. I'm going to have to devise another variable or switch which would allow you to override or pre-set these more easily. I think you can do so already, but it means having to set some things separately: ARCH, STD_FLAGS, TUNE_FLAGS, OPTIM_FLAGS, LD_FLAGS (some or all of these depending on what you are trying to do)

He wrote this after I contacted him about the results I experienced in attempting to build binutils. But let me get back to the point here. If we start from a clean Slackware system, one which runs all of it's 32-bit applications without a hitch, we can then move on to having a Slackware system that also includes 64-bit applications. Having the 64-bit kernel, allows you to do both, without any problems. I'm already running my 32-applications just as I did before. The only snafu here, is that I basically have a system that now may need to cross-compile applications for 32-bit. But here's where I'm now uncertain. Do I want to build any of my applications from this point forward as 32-bit, or completely move over to 64-bit builds from the existing Slackware system? For myself, this doesn't really matter to anyone else. However, if I'm interested in providing something other users may find helpful, I may need to give them the choice of their preferred packaging output. Either as 32-bit or 64-bit.

Personally, I think building everything from this point forward as 64-bit should be preferred. I think only those packages which won't build as 64-bit, should fall back to 32-compilations. There was one package in particular which simply won't ever be built as 64-bit, and that's xv. It says (said) so right on it's own page. Now, if there are replacements for packages like these, they should be sought out by all means. There may not be that many left. But having Slackware users comfortable running an uncompromised 64-bit system, would lend more hands to (re)building for 64-bit applications.

That's my "LONG WINDED" ;-) reason for doing this.

And I'll try not to be so defensive next time.
Xavian-Anderson Macpherson

Right ... so in the end you'll basically re-invent slamd64 ... right ? Yeah, eventually that's what you'll do.

I think the only uncertainty here is how a 32-bit kernel with PAE compares, performance-wise, against a 64-bit kernel running 32-bit apps via emulation. I am uncertain about the results, but cannot say that they will be different or meaningful.

But, go right ahead, at least it'll be a learning experience.