MX Linux Forum

I've been comparing MX with most of the lighter distros recently. Most all the ones catering to legacy systems and older hardware seem to be running 64-bit versions exclusively. I don't understand why this isn't a contradiction. ??

Examples?

It doesn't make much sense in my option, maybe people start to move to 64 bit and don't want to build 32 bit distros anymore, but it doesn't make sense for old systems. Some really old systems (or Atom based netbooks for example) cannot do 64 bit and 64 bit is a bit more wasteful with the memory than 32 bit.

I think that it's pretty certain that if you want to be able to be used on older hardware, then you need a 32 bit OS. A non-pae version is probably also a requirement. For really old hardware you need an i486 system. (Some of the BSD and Linux versions are i386 solely for compatibility with very old systems.)
I keep a couple of i486 LiveDisks (CD usually) around just in case they are needed. Along with a couple of i386 disks. Just in case.
My normal LiveDisk's are 32-bit_i686-PAE, as that will boot on all of my computers. They are also usually on DVD rather than CD no matter the size ISO involved.

Adrian wrote:Some really old systems (or Atom based netbooks for example) cannot do 64 bit and 64 bit is a bit more wasteful with the memory than 32 bit.

Well, it's more 50-50 with the Atom based systems - wikipedia has a useful table of the 32 versus 64-bit capable processors.

I'm running 64-bit Linux very successfully on a few Asus Eee PC 1015PX netbooks; these have the Atom N570 (Pineview). Certainly doing better than the 32-bit Windows 7 which they originally had, grinding away doing updates ...

Old is in the mind's eye of the be(h)older.
Old is older for old folks.
Young folks think that something made yesterday is old.

I seed torrents with a Pentium-I 90Mhz with 64M RAM that I built in 1995 for Windows '95. I run a very old version of Puppy on it. As you can imagine, it's slow, but so am I.

I run 51 BOINC projects on 8 machines built before 2005. All are 32-bit. All love MX.

Built my first 64-bit machine in 2006, my second in 2007, but was not successful at running 64-bit OSes or apps on either. Now I realize that I didn't give it enough RAM. But 64-bit was not ready for prime time then for other reasons too. So I ran 32-bit exclusively on all machines until 2014. This year I've built two 64-bit machines, and are successfully running 64-bit OSes and Apps. But, they are 4G quad-cores with at least 4G of RAM. (Hmmmm? Maybe 64-bit software was ready for prime time but hardware wasn't?)

I don't find that 64-bit software is any better or faster than 32-bit on any machine. It just requires more money, effort, energy, resources, and code from the whole computer industry and user base to do the same amount of real work. This is one case where older surely is better.

Adrian wrote:Examples?

Here's a follow-up to qualify my original post observation. I was going by the newest versions of OS's announced on DistroWatch. Looking more carefully, I discovered that the DW announcements almost always list 64-bit versions, but the actual Release Announcements from the developers *very* often also list 32-bit versions too. A tad of bias at DW?

Transcoding makes use of 64-bit well. Anything that's heavy on number-crunching also. For most of us the 32-bit OS does all it needs to, and does it well.
That said, I use 64-bit operating systems as my default. I do use and enjoy MX14.x as a solid choice for almost any PC. My Atom Single-Core loves it, as do I.

64-bit is definitely faster in video production and post-production than 32-bit, but the software available to do these tasks has improved greatly which has a huge impact on the quality of the finished product. I was able to encode a 1h45m video in about 9 minutes and play it through a projector to a video window measuring 15' x 8.5' with acceptable quality for mostly static or slow moving points, however, panning was not so great and audio sync suffered a tiny bit. Increasing the encoding quality to create an output file about double the size of the earlier encode fixed it and the process took a little more than 30 minutes.

When I first moved to 64-bit, I was seeing speed improvements of around 20% and nothing was going to pull me back into the 32-bit arena, but MX is just so impressive that I will happily take the tradeoff in speed.

I have a question that's slightly off-topic. I've only run 32-bit and 32-bit pae systems on my computer, but my CPU has virtualization capabilities (AMD-V), which allows me to install 64-bit guest OSes in VirtualBox. I assume that the computing power of a 64-bit guest OS is still limited by the 32-bit computing power of the host. In other words, there would be no improvement in performance of a 64-bit guest OS versus a 32-bit guest OS. Am I correct?

The question of 64 vs 32 has been floating around the Forum ever since I can remember. Early on, there were very good reasons to not use 64 bit as a lot of software was not available. That is no longer the case. If an OS is available in 64 bit there is no reason not to choose it over the 32 bit version if you have a 64 bit computer. If not available no reason not to use a 32 bit only OS for the average user.

joany wrote:I have a question that's slightly off-topic. I've only run 32-bit and 32-bit pae systems on my computer, but my CPU has virtualization capabilities (AMD-V), which allows me to install 64-bit guest OSes in VirtualBox. I assume that the computing power of a 64-bit guest OS is still limited by the 32-bit computing power of the host. In other words, there would be no improvement in performance of a 64-bit guest OS versus a 32-bit guest OS. Am I correct?

64-bit Host will run a VM smoother than 32-bit Host will. Try breakout or something similar on a 64-bit Host. Then run it on a 32-bit Host. I've never tried to see if there is a difference in a Guest VM running 32 and 64-bit.

I had installed 64-bit MEPIS 8.0 years ago and found some of the programs I used frequently didn't run as well as they did on a 32-bit system, but I understand that times have changed and there have been major improvements to the stability and usability of 64-bit. Although I'm sticking with MX-14 (32-bit pae) for the foreseeable future, AntiX looks quite attractive as a second option. So I might try 64-bit AntiX with KDE in the future.

Fwiw, I think I now have a 64bit MX-14.2 install.

Over the weekend I spent some time converting a i386 install (MX-14.2-pae.iso) over to amd64.

I roughly followed the instructions here: http://www.ewan.cc/?q=node/90, at least until I ran into some problems around step 9.

1072 of the 1074 i386 packages have been switched over to amd64 packages. l currently have only one i386.deb package installed, fbxkb-antix, and I may end up removing it because it doesn't seem to work. I think fbxkb-antix might work if it was rebuilt for 64bit. (but I don't know where the source is).

I also don't have Adrian's gui installer (installer-mx) installed because it's currently only available in a i386 package. Actually it looks like the i386 package is installable, but it wants to remove a couple 64bit packages and install 32bit versions in their place, and install several other 32bit packages. I think a 64bit installer package could be built, the source is on github but it's not debianized.

Here's a summary of the differences between my 64bit install and the 32bit MX-14.2-pae install it started out as:

Kernel differences

__---amd64--__
linux-headers-3.12-0.bpo.1-amd64 ___3.12.9-1~bpo70+1
linux-image-3.12-0.bpo.1-amd64 _____3.12.9-1~bpo70+1

__---i386---__
linux-headers-3.12-0.bpo.1-686-pae _3.12.9-1~bpo70+1
linux-image-3.12-0.bpo.1-686-pae ___3.12.9-1~bpo70+1

miscellaneous package version differences

____________________________--i386-- ______________--amd64--

antix-goodies ______________0.4.7 _________________0.4.7.1
bc _________________________1.06.95-2 _____________1.06.95-2+b1
dbus _______________________1.6.8-1+deb7u1 ________1.6.8-1+deb7u3
dbus-x11 ___________________1.6.8-1+deb7u1 ________1.6.8-1+deb7u3
dc _________________________1.06.95-2 _____________1.06.95-2+b1
gparted ___________________ 0.12.1-2 ______________0.12.1-2+b1
gtkdialog _________________ 2:0.7.20-4.2 __________2:0.7.20-3
intel-microcode ____________2.20140430.1~bpo70+1 __2.20140624.1~bpo70+1
libdbus-1-3 ________________1.6.8-1+deb7u1 _______ 1.6.8-1+deb7u3
libusb-1.0-0 _______________2:1.0.18-2~bpo70+1 ____2:1.0.19-1~bpo70+1
python-six _________________1.7.2-1~bpo70+1 _______1.7.3-1~bpo70+1
wpasupplicant ______________1.0-3+b1 ______________1.0-3+b2
xfce4-whiskermenu-plugin ___1.3.1-1 _______________1.4.0-mx140+1

i386 packages not installed, or not working

fbxkb-antix
installer-mx

Hi Everyone,

So, are we going to see an official 64-bit version soon?

Thanks, Michael.

cuscotravelservices wrote:Hi Everyone,

So, are we going to see an official 64-bit version soon?

Thanks, Michael.

As we have said many times, that would probably only happen if and when a Community member or (preferably) group took it over as a project. That would mean not only development, but also maintenance and support. Same goes for MX KDE.

The current Development Team has enough to do already...

I also don't have Adrian's gui installer (installer-mx) installed because it's currently only available in a i386 package. Actually it looks like the i386 package is installable, but it wants to remove a couple 64bit packages and install 32bit versions in their place, and install several other 32bit packages. I think a 64bit installer package could be built, the source is on github but it's not debianized.

You can git clone my repo and then run qmake && make on a 64bit Linux and obtain the 64bit executable. You need of course all the qt dependencies to run qmake and make.

Adrian wrote:

I also don't have Adrian's gui installer (installer-mx) installed because it's currently only available in a i386 package. Actually it looks like the i386 package is installable, but it wants to remove a couple 64bit packages and install 32bit versions in their place, and install several other 32bit packages. I think a 64bit installer package could be built, the source is on github but it's not debianized.

You can git clone my repo and then run qmake && make on a 64bit Linux and obtain the 64bit executable. You need of course all the qt dependencies to run qmake and make.

A day or so after I posted that I managed to debianize your source and build a 64bit "installer-mx" package. I installed it, but I haven't tried using it.

I created a snapshot iso of my 64bit install, but the LiveUSB I made with that iso wouldn't boot (the initrd still had the original i386 modules in it -- which might be the reason it wouldn't boot). I stopped playing around with it after that.

kmathern wrote:
I created a snapshot iso of my 64bit install, but the LiveUSB I made with that iso wouldn't boot (the initrd still had the original i386 modules in it -- which might be the reason it wouldn't boot). I stopped playing around with it after that.

You would need the 64 bit modules in the initrd.gz if you are using a 64 bit kernel.

As Jerry has pointed out several times, there is a lot of work involved in building and supporting a 64bit version of MX.

I wonder if it is that difficult... once we get that initrd with the 64bit modules then most of the packages just come from Debian with their 64bit versions, I think MX packages can all be built on 64bit arch without problems. It's double the work to build the CD, true, but I think most of it can be done automatically.

Adrian wrote:I wonder if it is that difficult... once we get that initrd with the 64bit modules then most of the packages just come from Debian with their 64bit versions, I think MX packages can all be built on 64bit arch without problems. It's double the work to build the CD, true, but I think most of it can be done automatically.

The building is relatively easy, though a bit time-consuming. However, there will be added 'issues' with things such as skype, netflix etc that don't seem to work too well on 64 bit linux.

Some of the things are trickier to set up, but that should be users' choice.
I don't remember having problems with Skype on 64 bit Linux and Neflix is available now in Google Chrome.

Are you interested in gathering together a sort of "Club 64" to look into developing a test run of a 64-bit MX 14.2?

Jerry3904 wrote:Are you interested in gathering together a sort of "Club 64" to look into developing a test run of a 64-bit MX 14.2?

Jerry,

I can test but not extensively as I have slowed down, all of my systems are 64 bit capable.

I have always run the 64 bit version of Mepis, and yes I agree the program selection has improved since 2007, but the last few years I do not tinker much & simply became a on-line user.

My Acer chromebook almost became the default system but the 11 inch screen is hard on my eyes now (use a 23 inch external monitor for my primary for Google video chats), but it is easy to use computer and does almost everything I need. That said using the quad desktops there is a perceptible difference surfing the web with a dozen tabs open in a 32 and 64 bit versions of an operating system with 4 gigs of DDR3 memory.

There is nothing that I can time or test, but I certainly get annoyed from the on-line lag coming from one of the 64 bit Mepis systems to a 32 bit Mepis system, when the system are almost side by side.

I use to play with encoding, VM, Usenet, Par, Par2 and Rars and my favorite program gimp. I still use gimp but for sizing and cropping photos, am sorry it does not run in the Chromebook.

If you spend any time behind a keyboard, flicking or paging about on the internet there is a more than a casual difference in performance between 32 and 64 bit systems. I have read all of the arguments over the years about lack of software, no difference in performance, and software must be optimized for 64 bit performance. My internet is quicker than most other users, and maybe that is the lag I can perceive using 32 or 64 bit systems. I am no longer a speedy typist with Dupuytren's contracture damaged hands, but I can still click a mouse and this is where I notice the difference the most...

Not certain about Laptop CPUs: lots of the Desktop SSE3 cpu are 64 bit. and will always run the latest flash or Google Pepper? SSE2 instruction can operate on twice as much data as an MMX instruction, performance might not increase significantly. Two major reasons are: accessing SSE2 data in memory not aligned to a 16-byte boundary can incur significant penalty, and the throughput of SSE2 instructions in older x86 implementations was half that for MMX instructions. Intel addressed the first problem by adding an instruction in SSE3 to reduce the overhead of accessing unaligned data and improving the overall performance of misaligned loads, and the last problem by widening the execution engine in their Core microarchitecture in Core 2 Duo and later products.
Run in terminal: $ grep flags /proc/cpuinfo

Internet speeds: http://www.speedtest.net/my-result/3718632919

JR

namida12 wrote:Internet speeds: http://www.speedtest.net/my-result/3718632919

Dayum...