Re: Ubuntu 32 Bits 2gb Ram
Nereu Theiss
Go to the System Settings and under the System section, hit Details. You will get every detail including your OS, your processor as well as the fact whether the system is running a 64-bit or a 32-bit version.
Open the Ubuntu Software Center and search for lib32. If that turns up any results, you are on a 64-bit install (the results are compatibility libraries for running 32-bit applications on a 64-bit install).
As far as I can remember, it is possible to install x86_64 kernel on a 32-bit system. As a few wrote here, you should look what libraries you have/what packages you have installed on your system. So the safest way to see is to check if you have /lib64 and if it is a symlink to /lib.
Another possible way is to check what packages you have downloaded in /var/cache/apt/archive. If they contain _amd64.deb, it is a 64-bit system, that is, if you have installed packages and have not cleared your cache.
Have a look at your Software Sources in Synaptic or Software Centre. If you haven't deleted your original source eg cdrom, it will (?) indicate the architecture. It's a GUI but it won't say '32bit' nor '64bit'.
Do you feel that my 32 bits environment should be called 32 bits (I believe so) or 64 bits (after all, it does run inside a 64 bits kernel). In that environment uname -m says i686 and all libraries and executables and processes are 32 bits.
Edit Thanks to the hint from @nightcracker, I did a little more investigation into the include structure on the 32 and 64 bit systems. I have added an answer below that "fixes" the problem temporarily but I think it will break on the next update. Basically, I am missing a directory called /usr/include/c++/4.4/i686-linux-gnu/64 that should contain a subdirectory called bits that has the missing include file. Any idea what package should be taking care of this?
Now compiling with just the -m64 works correctly. The major drawback is that this is still not the correct way to do things and I am guessing the next time Update Manager installs and update to g++ things may break.
From my experience, sudo apt-get install gcc-multilib g++-multilib helps. But my another issue is that I FORGET to clean the directory so I still get the same error. It is the first time to use clang or cmake. So I just delete my original directory and re-compile and it works. Hope it helps someone like me.
I think, also, it wouldn't cost you anything to put, say, #include after including my_pch.h, and that doing that sort of thing might be wise. If you're ever going to move the code into production you could then recompile it with my_pch.h empty.
Edit: Another thing to consider (which I also can't test) is just to include the things you actually use (string, vector, whatever) in my_pch.h. That will probably pull in bits/stdc++.h anyway, when building the precompiled header. Make it a comprehensive list so that you don't need to have to keep adding to it. Then you have portable code and people won't keep beating you up about it.
That's it! Nothing too much complicated. In my case, stdc++.h.gch file has been generated which is around 93 mb. It will get auto-included next time you use g++ even without any extra flags or changes in code. The compilation time has got improved in a very huge extent in my case.
Lubuntu is distributed on three types of images described below.Desktop imageThe desktop image allows you to try Lubuntu without changing your computer at all, and at your option to install it permanently later. This type of image is what most people will want to use. You will need at least 1024MiB of RAM to install from this image.
Choose this if you have a computer based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon, Core 2). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the i386 images instead. Choose this if you are at all unsure.
For almost all PCs. This includes most machines with Intel/AMD/etc type processors and almost all computers that run Microsoft Windows, as well as newer Apple Macintosh systems based on Intel processors.
The desktop image allows you to try Lubuntu without changing your computer at all, and at your option to install it permanently later. You will need at least 1024MiB of RAM to install from this image.
I have 3 32 bit computers on which I would like to install the latest version of Ubuntu MATE that will run on this architecture. The computers are: one each Dell desktop and laptop; and an ACER Netbook.
If you don't mind Xfce I would recommend the Linux Lite distro. If you want Mate I agree with tkn, and would also recommend Debian or a Debian derivative. I also use Parrot OS with the Mate Desktop and it is noticeably faster than Ubuntu Mate on my two old Dell Inspirons that are exactly the salme. (I don't recommend it as it is not recommended for new users and highly specialized).
Sparky Mate a Debian based OS (which is a rolling release) with the Mate Desktop I would recommend.
and I mentioned Linux Mint - but they are no longer supported. You could also try LM LMDE, but that only has Cinnamon desktop. Not finding a ton of 32-bits using MATE. MX Linux was supporting it, but not sure if they still are.
Rather liked the earlier versions of Peppermint OS (Peppermint Linux). Head guy died, but it's been resurrected as a Debian/XFCE product. Have a thirteen year old laptop that I've been thinking of resurrecting for my grandson. Didn't check, but pretty sure they still have a 32 bit version.
I have an old machine with an Intel D2700DC motherboard. I use it as a home server for some side projects. I have Ubuntu 32-bit installed on it, but recently figured out that its embedded D2700DC CPU is actually a 64-bit processor.
Do you think it will be faster in some ways or what other benefits I can get from installing 64-bit? One reason I see is that Ubuntu stops supporting 32-bit in the last major releases and I still have Ubuntu 18.04 there.
I would install 64 bit if I were you primarily because it will be more reliable and have bugs fixed more often. It will also future-proof your machine, since you can then just update to the next OS version every now and then without having to worry about it.
All FOSS projects have finite developer eyes/hours available to them, and 32 bit just isn't getting many of those eyes and hours anymore, and there are no magic coders that just fix stuff because it's broken, sadly. It's wisest to just accept this limitation as reality, since it won't really change.
I know of at least one 3rd party Linux kernel builder who stopped supporting 32 bit relatively recently because of a series of 32 bit kernel bugs that were known but were not getting fixed, nor did they appear likely to ever get fixed in the future. And that's the Linux kernel project, which has thousands of contributors. It just goes downhill from there with other projects with far fewer developers. This situation will happen to more and more core and not so core software and tools as 32 bit gets removed from more and more primary GNU/Linux distribution pools.
This becomes increasingly relevant as major projects like Google Chrome, Firefox, etc, start to drop, if they have not already dropped, 32 bit support, which means you'll be using insecure non-updateable software to access the internet.
Note that you can in theory sort of cross grade 32 bit to 64 bit (at least on Debian, not sure about Ubuntu), I tested that on one machine to see, but it's such a pain, and takes so long, and leaves so much cruft, and requires so many manual fixes, that in the end, I decided that was not worth it, and just switched the rest of my systems to 64 bit by reinstalling.
Keep in mind you can copy your main configs, and then get a package list, and reinstall the packages when you reinstall to 64 bit, it doesn't take that long, and once it's done, no more need to worry about it.
Your other option is to just never upgrade your box again, and just let it run until it dies. On systems that don't interact with the internet that's not a terrible way to deal with the stuff, but you may hit a snag one day when you need to match versions of something like samba or nfs and you can't because your server box OS is too old.
Additionally, it is a real possibility that it will be slightly faster, since x86-64 has 16 general-purpose registers and x86-32 has only 8. Position-independent code, which is used for security reasons in most binaries these days, is free on x86-64 with RIP-relative addressing but needs an additional register on x86-32. Having additional registers means that programs can keep more data on the CPU instead of having to go to memory, improving performance.
However, there will probably be a slight increase in memory usage, since pointers will be 64 bits instead of 32 bits. If you're really stressed for memory right now, that won't make it any better, but otherwise, it's probably fine.
The gains to redeploying a 64 bit distro are going to be marginal at best. Sure you'll get some more memory support, but unless the current box is under memory pressure that probably won't be noticeable.
d3342ee215