I recently participated in a discussion in a CentOS group I belong to about the suitability of CentOS for ordinary laptops. These were my thoughts, mostly taken from various points in the discussion and edited into a coherent whole. Is CentOS really good for laptops? Like so many things it depends on what you intend to do and what software you're going to use.
I use CentOS 8 on several laptops and it mostly works well. It may be missing some drivers you might need. If so, ELRepo is a good source for those. You definitely won't find the number of apps you do in Ubuntu's repositories and will need to go with third party repos. The best of them is EPEL, maintained by the Fedora project. You can leave both ELRepo and EPEL enabled to get updates as needed probably 99.8% of the time. The rare conflict can be avoided by setting repo priorities in dnf to insure official repos have precedence.
If you need to go to third party repos beyond that pull packages manually. Some repos conflict with each other or, on rare occasions, with CentOS packages. If you can stick with EPEL you avoid that.
One thing Ubuntu does that CentOS does not do is automatically download and install proprietary packages required by some hardware. For example, I use an Epson all in one printer/scanner/copier. I had to get drivers and apps directly from Epson's website and install them manually. The good news is that Epson provides rpms for Red Hat Enterprise Linux that work perfectly well with CentOS.
In my opinion CentOS is more difficult to setup and configure than Ubuntu on a typical laptop and to the find and install all the apps you want. However, if you do that work it's rock stable and reliable. It's also every bit as easy to keep up to date and secure as you will get notifications when updates and patches are available and can install them with a click.
I never recommend Fedora. I don't like being forced to upgrade the OS as a whole frequently. For me laptops are for getting things done, not tinkering. I've also had too many problems with packages being updated without the requisite dependencies causing breakage in Fedora. I recommend either CentOS or Ubuntu LTS for those reasons.
I haven't found any reasonably modern hardware on which I couldn't make CentOS work. The question is how much work does it take and how difficult is the process. That varies widely. One caveat: I've been working with Linux professionally since 1995. What's easy for me may not be easy for someone who has limited experience. Of course, for them, working through issues may be a great learning experience.
I have yet to have a clean install of CentOS on a laptop that requires no further action, including laptops by ASUS, HP, Lenovo, and Toshiba. That may be because of hardware or because of how I use my laptops. Usage patterns make a huge difference. In general, for most people, Ubuntu LTS is going to be easier to install, configure, and add software to than CentOS. Once installed both are stable, reliable, and reasonably easy to use. Both work well.
Tuesday, November 17, 2020
Sunday, September 30, 2018
New version of Culmus (Hebrew) fonts released
For those of you who do some Hebrew computing, I received this from Maxim Iorsh on e-mail via the Culmus announce list. For those who don't know Culmus is an excellent set of Hebrew fonts that I've used on Linux for many years:
Many popular Linux distributions have Culmus packages in their repositories. Whether they update those packages during a release cycle and how quickly they adopt new version varies widely from distribution to distribution.
Tuesday, March 21, 2017
How Things Work Today or The Joys of Consulting
A person with company A has a concern about some work that needs to be done. They call outsource IT firm B with whom they have a contract. Firm B has nobody on staff with the required experience. Company B is big and well known. Their solution: call recruiter C who in turn checks their database and realizes that Linux systems consultant D has the experience. Hi! I'm D.
Unfortunately this is being handled like a game of telephone and the information C gave to D (me) didn't clearly explain what they needed so D (me) asked for more information. In the meanwhile I get a note from B forwarded by C that makes it very clear what is needed. Thank you, C, but... I now have to go back to C to tell them my question is irrelevant. Asking it would make me look stupid because it really isn't the issue at all. If that message gets through in time I give them what they need to present me successfully to B and A. Fortunately C did get the message before presenting D to B.
Why might this still not happen? B presents this as if A is demanding someone who has worked on the exact same hardware running the exact same application. That's why I asked an irrelevant application question in the first place. Software vendor E supports the revised environment for their application and actually has this all very well documented. I work with E for another client so I have access to their knowledge base. I can definitely solve the problem. That doesn't change the fact that I don't match on the irrelevant points of experience and they may turn around and look for someone who does.
Welcome to the world of IT consulting in 2017. Does this make sense to anyone? It doesn't to me.
Wednesday, December 21, 2016
A Holiday Gift From Conexant: an ALSA Driver For Recent Cherry Trail SOC Based Devices
Late on Monday Simon Ho of Conexant announced the release of a driver for the company's driver for CX2072X codec to the ALSA-devel mailing list. I have to add a tip of the proverbial hat to Pierre Bossart who shared the information in kernel.bugzilla.org where I found it. According to Mr. Bossart we can expect “a follow-up machine driver soon from Intel.” The machines where sound has been a problem have Intel SST sound on the SOC which uses the Conexant codec. On those systems the "sound card" is simply not detected.
This is good news for owners of many recent tablets and notebooks running on recent Intel Atom (Cherry Trail) based SOCs. These include systems by Acer, ASUS, HP, Toshiba and probably others. It impacts Android as well as more conventional Linux distributions. Preliminary testing in the user community, though limited at this point, appears to be entirely positive.
NOTE: I'll be posting a full review of my HP x2 Detachable 10-p010nr, the latest incarnation of that company's 10” 2-in-1 device shortly. Please watch this space.
Friday, January 8, 2016
Goodbye, Debian 8.1
Goodbye, Debian 8.1 (Jessie). I tried the distro for several months because RHEL clones (Springdale Linux and CentOS, both 7.0 and 7.1) didn't like my legacy nVidia GeForce 6150 SE in this old desktop and it was a pain to fix that. The system still is good enough to do all the work I need to do and performs reasonably well. Debian seemed like a reasonable alternative. I chose to install it with LXDE as the desktop environment which is lightweight and ideal for old systems.
First, Iceweasel is not simply Firefox with the branding stripped out as is often claimed. It slows down, takes all the system resources and locks for anywhere from a few seconds to almost a minute on many websites and does this repeatedly. It did it across multiple versions. Firefox simply works without this nonsense. Of course, I can use genuine Mozilla Firefox on Debian, but only outside their package management system unless I build and maintain packages myself. Yes, other browsers offer better performance on Debian, but for some sites Firefox is my preference and sometimes I really need to test in Firefox.
Speaking of packages, their vaunted large repository would often have broken updates because of version mismatches and/or a lack of timely dependency updates. I also had to give up on Iceweasel language packs for a while because the browser was updated but the language packs were not. I had the choice of a browser with a known vulnerability that wouldn't upgrade or ripping out the language packs. Granted, I don't need browser menus in another language, but a lot of people do and there are things I wanted to test in a localized environment. I've seen this sort of really poor repository/package management in other distros, of course. I just haven't seen it much recently.
Despite the large package selection I was surprised that some very ordinary things I use regularly that are found in lots of other distros weren't in Debian. No matter what distro I use I seem to end up building packages. Debian is no different.
Then there is PulseAudio. Yes, it works. I couldn't get it to remember that I wanted line out as the default, not headphones, so I kept having to change it. Sure, that's a really minor annoyance, but it just works on most distros. User error? In this particular case quite possibly. I just couldn't be bothered to research it. I shouldn't have to spend the time to do so on something that just works in literally every other distro I've tried in recent years.
Performance was decent, but a distro designed to be lightweight can be faster on older equipment. I went back to an old favorite, Vector Linux, who have a very solid release in 7.1, and my system is faster. I'm not supporting Debian for work at the moment so there was no reason to keep it. Look, it's not a bad distro. Most of what I've described is relatively minor and entirely fixable. I don't want to tinker and I do want performance on legacy equipment. Debian 8.1 is simply not the best choice for me.
First, Iceweasel is not simply Firefox with the branding stripped out as is often claimed. It slows down, takes all the system resources and locks for anywhere from a few seconds to almost a minute on many websites and does this repeatedly. It did it across multiple versions. Firefox simply works without this nonsense. Of course, I can use genuine Mozilla Firefox on Debian, but only outside their package management system unless I build and maintain packages myself. Yes, other browsers offer better performance on Debian, but for some sites Firefox is my preference and sometimes I really need to test in Firefox.
Speaking of packages, their vaunted large repository would often have broken updates because of version mismatches and/or a lack of timely dependency updates. I also had to give up on Iceweasel language packs for a while because the browser was updated but the language packs were not. I had the choice of a browser with a known vulnerability that wouldn't upgrade or ripping out the language packs. Granted, I don't need browser menus in another language, but a lot of people do and there are things I wanted to test in a localized environment. I've seen this sort of really poor repository/package management in other distros, of course. I just haven't seen it much recently.
Despite the large package selection I was surprised that some very ordinary things I use regularly that are found in lots of other distros weren't in Debian. No matter what distro I use I seem to end up building packages. Debian is no different.
Then there is PulseAudio. Yes, it works. I couldn't get it to remember that I wanted line out as the default, not headphones, so I kept having to change it. Sure, that's a really minor annoyance, but it just works on most distros. User error? In this particular case quite possibly. I just couldn't be bothered to research it. I shouldn't have to spend the time to do so on something that just works in literally every other distro I've tried in recent years.
Performance was decent, but a distro designed to be lightweight can be faster on older equipment. I went back to an old favorite, Vector Linux, who have a very solid release in 7.1, and my system is faster. I'm not supporting Debian for work at the moment so there was no reason to keep it. Look, it's not a bad distro. Most of what I've described is relatively minor and entirely fixable. I don't want to tinker and I do want performance on legacy equipment. Debian 8.1 is simply not the best choice for me.
Monday, October 19, 2015
List of Linux System Hardening Resources
My recent post about how quickly newly commissioned Linux systems can be attacked and possibly compromised led to a bunch of e-mail queries about resources which explain how to lock down a variety of Linux distributions. Most such guides are distribution specific because, while the basic principles are always the same, there are significant differences between distributions and even versions of the same distribution that make writing a generic guide difficult at best.
I did compile a list which I added to the comments. However, based on the number of questions I've received I thought it would be best to publish the list as a blog post, something people could easily find and bookmark, with some additions to what I originally posted. I've limited this list to distributions commonly used in businesses (large and small), academia, and in non-profits. I have not included specialized distributions, including those designed for use by security professionals. Most of these distributions also are excellent choices for personal use.
Red Hat Enterprise Linux / Centos / Scientific Linux / Springdale Linux
Debian
SUSE
Ubuntu
I did compile a list which I added to the comments. However, based on the number of questions I've received I thought it would be best to publish the list as a blog post, something people could easily find and bookmark, with some additions to what I originally posted. I've limited this list to distributions commonly used in businesses (large and small), academia, and in non-profits. I have not included specialized distributions, including those designed for use by security professionals. Most of these distributions also are excellent choices for personal use.
Red Hat Enterprise Linux / Centos / Scientific Linux / Springdale Linux
- Red Hat Enterprise Linux 7 Security Guide
Chapter 4: Hardening Your System with Tools and Services - Red Hat Enterprise Linux 6 Security Guide
- University of Texas Red Hat Enterprise Linux 7 Hardening Checklist
- CIS Red Hat Enterprise Linux Security Benchmarks
Debian
SUSE
Ubuntu
Wednesday, October 7, 2015
Linux Security: Lock Down a New System Immediately
PCWorld recently published an article about Linux botnets launching DDoS attacks. The attackers find and exploit poorly secured Linux systems. Some Linux users have a fairly cavalier attitude about security, assuming the supposedly superior design of the OS somehow protects them. It doesn't. Now that Chromebooks outsell Windows laptops and Amdroid devices are ubiquitous the days when Linux was a secondary target for malware are long gone. Linux' prominence in both the server room and on consumer devices make it a prime target.
How quickly will a newly commissioned system be attacked? Here's my recent experience. I did a build of a webserver with CentOS 7.1 and Drupal 8. That went smoothly. Then I installed all the latest patches. On to configuring and hardening the server. The first time I issued a su command to allow me to configure sudo I got a message about failed logins. I looked at the logs and sure enough, someone was already trying to break in with a scripted brute force attack. I immediately configured ssh to disallow root login and to disconnect after three failed attempts. That slowed but did not stop the attacks. OK, I checked the IP address they were coming from, knowing full well it might be spoofed, and found the owner was a French ISP. To satisfy my curiosity I put in a temorary firewall rule to disallow that IP range and the attack stopped and did not resume. So... either the IP address was not spoofed and some script kiddie was trying to break in from their actual connection or else the attack came through a proxy server with an IP address in that range. Cute.
Anyway, I finished my usual tasks for hardening a server and Apache, uploaded my backed up files and put them in the appropriate places with the appropriate permissions. My idea of hardening Apache includes both mod_evasive and mod_security with a current rule set. My idea of securing a server includes blocking pretty much all inbound connections not needed by either the web server, software used on the website or SSH.
I should also add that IP address blocking, up to and including geolocking, is generally not an effective defense. Knowledgeable hackers use proxies. Many change their apparent IP addresses frequently. Blocking IPs, even at the firewall level, is a lot like playing Whac-a-Mole. The attack simply continues from a different IP in short order. The brute force attacks I'm still experiencing are trying to login as root and since remote root logins are disabled that simply won't work. However, the excess traffic to my server continues and there is relatively little I can do about it.
How long between my rebuild and the start of the attacks? A few minutes. Such is life on the Internet today. The first thing anyone should do with a new system, any system, is lock it down.
How quickly will a newly commissioned system be attacked? Here's my recent experience. I did a build of a webserver with CentOS 7.1 and Drupal 8. That went smoothly. Then I installed all the latest patches. On to configuring and hardening the server. The first time I issued a su command to allow me to configure sudo I got a message about failed logins. I looked at the logs and sure enough, someone was already trying to break in with a scripted brute force attack. I immediately configured ssh to disallow root login and to disconnect after three failed attempts. That slowed but did not stop the attacks. OK, I checked the IP address they were coming from, knowing full well it might be spoofed, and found the owner was a French ISP. To satisfy my curiosity I put in a temorary firewall rule to disallow that IP range and the attack stopped and did not resume. So... either the IP address was not spoofed and some script kiddie was trying to break in from their actual connection or else the attack came through a proxy server with an IP address in that range. Cute.
Anyway, I finished my usual tasks for hardening a server and Apache, uploaded my backed up files and put them in the appropriate places with the appropriate permissions. My idea of hardening Apache includes both mod_evasive and mod_security with a current rule set. My idea of securing a server includes blocking pretty much all inbound connections not needed by either the web server, software used on the website or SSH.
I should also add that IP address blocking, up to and including geolocking, is generally not an effective defense. Knowledgeable hackers use proxies. Many change their apparent IP addresses frequently. Blocking IPs, even at the firewall level, is a lot like playing Whac-a-Mole. The attack simply continues from a different IP in short order. The brute force attacks I'm still experiencing are trying to login as root and since remote root logins are disabled that simply won't work. However, the excess traffic to my server continues and there is relatively little I can do about it.
How long between my rebuild and the start of the attacks? A few minutes. Such is life on the Internet today. The first thing anyone should do with a new system, any system, is lock it down.
Subscribe to:
Posts (Atom)