Is My System Capable of 32 or 64 Bit Linux?

There are a number of situations where you may not be sure if your CPU supports 32 or 64 bit Linux. If you want to know, it’s pretty easy to see if it supports 32 or 64 bit. If nothing else, it’s always good to know what your CPU architecture is and thus know which distros are compatible with your hardware.

You simply might not know this information. You wouldn’t be alone in that. These sort of questions pop up fairly regularly at the various support sites.

Maybe you were still new to Linux when you installed? Or maybe you’re working on a system that you yourself didn’t install? Perhaps you just don’t remember? There are a number of reasons why you’d want to know and why you might not already know.

Anyhow, this should be a relatively short article. There’s only so much fluff that I can add! I’m gonna tell you how to know for sure what architecture you can use.

Is my CPU 32 or 64 bit?

It was not that long ago that I saw someone asking this question at a forum I frequent. They wanted to know if their CPU supported 64 bit. The answer, which was well intended, was that they should run this command:

Which would indeed output this sort of text:

That’s great, but it’s not actually informative – as an answer to this specific question. What that command and output determine is that you’re using a specific variation of Linux. Granted, it’s true for those CPUs that support 62 bit and have a 62 bit CPU installed. It’s not always certain to be true, however.

For example, if you were using a 32 bit distro then the output from the ‘uname’ command would be 32 bit. You can run 32 bit Linux versions on 64 bit CPUs and the output will only be accurate so far as the version installed. After all, a 32 bit distro will run just fine on 64 bit hardware. Even if your hardware supports 64 bit, the uname command will output something about i686 if you have a 32 bit distro installed.

So, you could realistically have an output that says something about 32 bit while being perfectly capable of running 64 bit Linux versions. Using the uname command doesn’t tell you the hardware capability (necessarily). It tells you what is currently in use.

How do we know for sure? Well, there are a number of ways, but the easiest way that I can think of and it requires the terminal. Go ahead and open your terminal emulator by pressing CTRL + ALT + T on your keyboard.

Next, enter this ‘lshw‘ command:

In the output you will find something about ‘width’ and that’s your answer.

If you want, you can use ‘grep‘ to process the output and get an even easier, or at least more concise answer. Just use this command:

With any luck, that won’t lie to you. That won’t tell you what you’re using, that will tell you what CPU architecture you can use. If your CPU architecture supports it, it will tell you right then and there.

I’ve prepared a graphical demonstration of when it may present inaccurate information. The CPU is capable of 64 bit, but the OS in question is actually just a 32 bit OS.

32 vs 64 bit demonstration
See? The 32 bit OS is in use and it could use 64 bit.

There’s no doubt with the ‘lshw’ command, you learn if you can use 32 or 64 bit versions of Linux. That’s why it’s important to use that command rather than relying out the output of ‘uname’, as the ‘uname’ output only only tells you what CPU architecture you are currently using and not what CPU architecture you could be using.

And, there you have it. Thanks for reading! Don’t forget that you can sign up for the newsletter, donate, or simply opt to contribute to the site with articles of your own. If you want to lend a hand, let me know. I’m receptive to such things, as I am receptive to feedback!

Disable Ubuntu Snaps

People have a variety of reasons why they want to disable and remove Snap apps from Ubuntu. It’s relatively easy to disable Snaps and this article shows you how.

Let’s start with the basics. What is a Snap? It’s another form of packaging software and Canonical’s Snapcraft page describes it like this:

Snaps are app packages for desktop, cloud and IoT that are easy to install, secure, cross‐platform and dependency‐free. Snaps are discoverable and installable from the Snap Store, the app store for Linux with an audience of millions.

Canonical is the company that makes Ubuntu and if you’ve been using Linux for any length of time, you’ve probably heard of them and Snaps. The reality is that, if you want to use Ubuntu or official Ubuntu flavors, you might want to make your peace with them. They’re going to be everywhere.

Right now, you can find Snaps being more or less mandatory in current Ubuntu Core versions. If you want to use Livepatch to keep your running system protected then you’ll need to use snaps. The list of places Snaps are in use goes on, but more and more applications are being packaged exclusively as Snaps and that trend looks likely to continue.

To be frank, I can’t blame the developers. Package it once and it runs everywhere – or it can run everywhere. This saves time, presents a single point of contact, and helps to ensure uniformity across the myriad distros out there. It does away with things like ‘Dependency Hell’. It even makes it more secure.

In an ideal world, it’d be great!  Maybe you don’t live in that ideal world? Maybe you don’t want Snaps? I don’t need to know your reason. Let’s just disable them.

Removing/Disabling Snaps

Let’s start by cracking open your terminal. You’re gonna want to start there for this. It’s as easy as using your keyboard to press CTRL + ALT + T. Then, enter the following commands into your terminal, one by one and pressing ENTER after each one:

The first command will completely purge ‘snapd’ – the service that controls and installs Snaps. The next three commands remove any remnants of Snaps that you have on your system. The final command will reboot your system, so that everything is cleared out of memory and so that you start fresh and without Snaps.

And, there you go. You can disable Ubuntu snaps! You’re Snap free! Everything is now just as you wanted it. You no longer have any Snaps on your system, nor do you have to worry about installing them by mistake. 

At the same time, it may well be time for dedicated Ubuntu users to adjust and learn to use Snaps. They do have their benefits. They do things like auto-update, automatically revert to the previous version if it’s broken, and keep applications isolated from the rest of the system. For the most part, they just work, without you needing to worry about anything.

So, before you decide to completely remove Snaps from your system, you might just want to take a minute to make peace with them and learn to use them. Yeah, they take up more space, their permissions are wonky, and they’re still a work in progress. You’re probably going to end up using them eventually. The sooner you get used to managing them, the easier it’s probably going to be.

Anyhow, thanks for reading. I appreciate the readers and welcome you to contribute. There’s a whole host of ways you can do so, from joining to donating. You can even write articles without registering, share this article at your favorite sites, and you can sign up for the newsletter so that you know you’re getting these articles (and no spam) in your inbox.

Use an RPM on a DEB-based System

Once in a while, you’ll come across a piece software that’s only in RPM format. It’s possible to convert RPM to DEB and you may be able to install that software on your DEB-based system.

You’ll find that it’s not unusual to come across software packaged in a format that you can’t use. That’s just the name of the game. Developers and package maintainers are going to concentrate on the stuff they themselves use. It’s not selfishness that prevents them from packaging it in different formats, it’s just a matter of time and priorities. 

It’s times like these when you can use a nifty little tool called ‘alien‘. Alien has been around for a long time and is really useful. It can actually be used in both directions, converting between .deb and .rpm interchangeably. 

Convert With ‘alien’

So, let’s get started. This won’t take very long and will be a valuable tool for your tool-chest. If you don’t need it today, put it aside for a future date. As you progress along your Learning Linux Journey, it may well prove valuable.

As you know, the tool we’ll be using is ‘alien’ and the man-page defines it as this:

alien – Convert or install an alien binary package

You’ll install it with your package manager. As we’re using an apt-based system, we’ll be using apt to install the software. Crack open your terminal with CTRL + ALT + T and enter the following:

That’s going to pull in quite a few dependencies. On a stock Lubuntu installation, it pulls in about 200 MB worth dependencies, so you should be aware of this.

Now that you have it installed, there are a couple of ways you are most likely to use it. The first, given that we’re talking about Debian/Ubuntu/derivatives, would be converting an .rpm to a .deb. That’s pretty easy. Just do this:

That will convert the package to .deb and you can install it in the normal ways. Seeing as you’re right there in the terminal already, you can just use:

You can skip all that and do the conversion and installation all at the same time. To do this, you simply use the -i switch. It looks like this:

NOTE: This won’t always work. The package you converted may not work, usually due to dependencies that can’t be satisfied. If it doesn’t work, you’ll have to look for other solutions.

If you want to go the other direction, you can use this:

There are other ways to use alien, but those are the most common ways that I see it being used – and the ways I’ve historically used it. It has been effective most of the times I’ve tried it, but I am just a single data point and anecdotes aren’t really data.

If you’re interested in other uses (such as tgz or slp), you can consult the man-page or read the online man page. It’s a fairly versatile application and one that all Linux users should know about.

Once again, thanks for reading. Don’t forget that there’s a newsletter and that you can now donate to help cover any hosting costs. If you want to contribute, there are all sorts of ways that you can help – just let me know.

Quickly Reset Ubuntu’s Default Repositories

Is your software not updating? Are you getting repository errors when you try to upgrade? There’s a quick and easy way to reset the Ubuntu repositories to the defaults.

Ubuntu, like all Linux distros, uses repositories for distributing software. This provides a central location for curated, standardized software that’s almost certain to work on your system. These repositories are not just where you install software from, they’re also where you get your software updates.

If you want to see them in action manually, open your terminal and enter the following:

That will show you the system checking the repositories, updating your internal database of software and software versions. There aren’t a whole lot of defaults, so it’s usually a pretty quick process. If you’ve been adding PPAs or other repositories, it could take a while to get through the list.

Of course, if you see errors with that command then this might actually be the article you’re looking for! There are a variety of reasons why one might want to set the system back to the defaults, and it’s actually pretty easy once you know how.

Reset Ubuntu’s Repos

Like many articles and exercises, this one is gonna start with you cracking open your terminal. You should already know how to do that, but you can just use your keyboard and press CTRL + ALT + T.

Once you have that open, just go ahead and run this horribly destructive (I kid, I kid) command.

NOTE: That command could have a horrible outcome if you mess it up. Be sure to double-check it, or use copy/paste. If you screw this up, you can delete files that you really don’t want to delete. You have been warned!

That command will erase all the entries in your ‘sources.list’ file, technically deleting the file itself, which is not necessarily a good thing. Fortunately, it’s a necessary step and only the first step. The next step is also easy – and more or less mandatory.

Just run the following command:

Up should pop a window that looks a whole lot like this:

software properties
Note the lack of any selected repositories. The next step should be obvious.

There you go. You have a blank slate. Select from those four (or five, if you want the source code and have selected at least one other repository) and then click close. When you close it, the system will ask you if you want to update the database and you should agree, of course. You can also change the server from which you download, and most people pick a server that’s geographically close.

That’s it. That’s all it takes to reset your Ubuntu repositories to the defaults. There’s no wizardry involved. You’re simply removing one file and recreating it with the defaults. You could do it all with a file manager if you opened it as root, but the terminal is faster and easier.

Thanks for reading. Feedback is always appreciated. You can sign up for the newsletter and get a notification when new articles are published. A couple of people asked, so I’ve set it up so that you can donate to help fund the site. I’m not going to try to guilt you into donating. The site will remain online and continue to grow even without donations. Still, I had some interest and figured I’d add it as an option. 

Dealing With Duplicates In Your Bash History

Your Bash history can be a valuable tool when you mess up and need to retrace your steps to find out what went wrong. It’s in your best interest to keep it from getting cluttered.

Some of my readers are fairly new to Linux, so you may not know that you have a Bash history. Well, you probably do. It’s helpfully called .bash_history and it’s a hidden file in your home directory. You can open it with a text editor if you want.

See, every time you write a command into the terminal (unless you take steps to avoid it) that command is stored in a hidden file called .bash_history. The period at the start of the file name means that it’s a hidden file and you’ll need to enable hidden file viewing in your file manager. (It’s quite frequently F4 or under the ‘View’ menu.)

If you open your terminal (press CTRL + ALT + T) and push the up arrow on your keyboard, you’ll see the last command you used in your terminal. Well, it’s a bit more complicated than that, but you’ll see the bottom-most entry in your .bash_history.

If you use your terminal a lot, you’ll have duplicates. It’s just a fact of life. Many commands will be run multiple times, such as performing updates. These clutter up your history and just waste space. You don’t have to keep the duplicates, or even allow duplicates.

De-dupe .bash_history

First, let’s disable duplicates and delete them if they do somehow occur. To do this, you’re going to edit your .bashrc file. As you can see by the . at the start of the file name, the file is hidden by default. You can use the GUI file manager and favorite text editor. Enable viewing hidden files, and just add the following line to the very bottom of that file.

Save it, of course.

If you want, you can do it right in the terminal. Open the terminal with the directions above and enter the following command:

Notice how there’s no use of ‘sudo’? That’s because you already own these files and you don’t need elevated permissions to edit them. 

Anyhow, use the down arrow and then paste in the text above, just as though you were editing it in your favorite text editor. Then, go ahead and save it by pressing CTRL + X, then Y, and then ENTER.

There… Now Bash should ignore duplicates and erase any new duplicates that it finds.

All well and good?

Maybe…

I mean, it’s not like you just installed your OS today and have a sparkling clean bash history. No, if you’re like me, you’ve probably got a bunch of clutter in there and all sorts of duplicated content. So, you’re going to want to clear those already existing duplicates out as well.

Seeing as you’re already in the terminal, you can use the following command that I once found online and saved to my notes:

That right there will go ahead and remove any duplicates that it finds in your bash history. You might want to make a backup of the file before trying that command – but I’ve used it so many times that I have complete faith in it. So far, it has only removed duplicates and not broken anything. (Pay most of your attention to the use of awk in the command if you’re wondering how it works.)

And, there you have it. You should have a nice .bash_history that isn’t full of duplicates. I’ve been known to open the file manually and run through it to remove stuff I’m never going to use again, commands that I’ve gotten wrong, or commands that are no longer of any use. 

Addendum

I should also mention that I have been using the (mostly) same history file for a long time. You save it and import it on new computers that will run the same operating system. Personally, I use my bash history fairly often and I like the consistency. I also do the same with my aliases, but that’s a topic for another day.

By the way, if you don’t want to have your command stored in the history, the easiest way to avoid it (on a command-by-command basis) is just to put a space in front of it. The system doesn’t care that there’s a leading space, except to use it as a cue to not store the command in your history. If you’re entering sensitive data into your terminal, you might want to consider that. If it’s just a junk command that you’re never going to see again, you might want to consider that.

Finally, thanks for reading. I appreciate the audience and I enjoy getting my notes online. The new domain is going well and we’ll soon be getting some of the older content transferred. It’s just a bunch of tedious work. I’d ask for help, but there’s not a whole lot anyone can do to help. I’ll just have to find the time to do it. Don’t forget the newsletter! 

Subscribe To Our Newsletter
Get notified when new articles are published! It's free and I won't send you any spam.
.
Linux Tips
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.