Archive

Posts Tagged ‘centos’

CentOS 7: Home Networking

Monday 21 July 2014 Leave a comment

CentOS is a lot smarter than you might expect. It knows when it is connected to a home router. The new firewall quickly adjusts and generally does the right thing.

However, it won’t automatically allow you to link to the other computers on your home network. It’s defensive by nature and pretty tight. Once you tell the firewall things are okay for this or that, it will relax just a bit.

Let’s say that you have at least one other computer on your home network running Windows. This is not about Windows, so you’ll have to research how, but your Winbox can share files and any peripherals attached to it with your CentOS 7 machine (start by reading this for XP/Vist and this for Win7). The nickname for the protocol Linux uses to talk to Windows is called “Samba” which is taken from the abbreviation SMB (server message block). By default, it’s likely your CentOS machine is running a Samba client. It simply needs permission from the firewall to use it on the home network.

In your main menu, find the system administration tool for the firewall. It will demand your root credentials. The window that will open is pretty complicated, but we only need to worry about one thing: In the window pane on the left, select “home” — it’s the zone of operations CentOS knows comes from home networking traffic. In the window pane on the right, scroll down to find “samba-client” and select that box. The firewall immediately opens that channel for traffic only inside the router network.

Now test it by opening your file browser window. Look for something that indicates the Network connections and click that. Find the icon for Samba shares. Click and it should offer you a list of the Windows networks. By default, Windows computers will be set up to use “workgroup” as the name for this. Click that icon and you should find a list of Windows computers within that default workgroup. If you attempt to connect to any Windows “host” listed there with whatever name you gave it when you set it up (like “winbox”), you’ll need a name and password for any of the accounts on that machine. You can have your file browser window remember the password so you can log on at will. Once logged in, you can browse the file system as if it were your own on CentOS.

I’m not going to detail here the chase to find printer drivers for Linux; it’s pretty complicated. CentOS 7 comes with most of those available. You can find more at this page. Also, note that several major printer manufacturers have begun offering their own special Linux drivers, so do your own research. So let’s assume for now you know you have a Linux driver for a printer connected to your Winbox.

When you run the printer setup tool on CentOS, one of the options is a network printer using Samba (SMB). Click that option and fill in the information as required for your Windows Samba share. This assumes you’ve set up things on your Winbox to share and have given the printer share a simple name — I used “winprint.” Thus, it was a simple matter of smb://winbox/winprint for me. Then I chose the appropriate driver and set it up using the tool on CentOS. I was able to print a test page in just a couple of minutes.

The key was simply getting the firewall to open up for the samba client.

Desktop CentOS 7: Added Repos

Sunday 20 July 2014 Leave a comment

This is simply my own recommendation. In order to run CentOS 7 on the desktop, most folks want stuff you can’t get from CentOS directly.

For example, most of us still use websites that require Flashplayer. Adobe has set up a Yum repository that updates as it should with anything related to Red Hat. Using your CentOS box and your favorite browser, go here. The webpage should detect you’ll be running 64-bit and offer a button with a drop-down — select the YUM version and download. It’s an RPM you can install as root. Run “yum update” and you can then elect to install Flashplayer.

For almost everything else you would use on the desktop, I recommend you add the EPEL and Nux repositories. The quickest and easiest path is go here and read the short explanation. The Nux provider links back to the EPEL release as a prerequisite and puts it all in a simple single CLI copy-n-paste command for you:

rpm -Uvh http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm && rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-1.el7.nux.noarch.rpm

However, I prefer to download the linked release packages and install from Yum. These release packages will install the repo references to Yum, so run “yum update” again and you are ready. For example, one of the biggest things is adding the necessary packages to run a wider range of multimedia using the default Dragon player on the KDE4 desktop. It uses GStreamer as the backend, so all we need is the rest of the GStreamer plugins:

yum install gstreamer-ffmpeg gstreamer-plugins-bad-nonfree gstreamer-plugins-ugly

You can peruse the list of goodies on Nux and EPEL to see what else you might want. I note that EPEL is still considered a beta repo because they are still working on the packages and the collection itself. That should all update for you automatically once they feel it’s ready. I’m quite certain they’ll add the matching 32-bit packages after CentOS makes that version ready for CentOS 7. However, it’s highly unlikely you’ll need to mix the two architectures unless you just have to run something like Wine to enable running Windows apps.

In other words, using Nux and EPEL on CentOS 7 64-bit just about covers everything you are likely to need and it’s virtually hassle-free. Kudos to EPEL and Nux for the hard work to make us comfortable.

As a side note, building your own stuff from SRPMs requires keeping track of how RHEL/CentOS draws from both FC18 and FC19. I noticed that almost everything KDE is from FC18. I was able to build Bibletime, GKrellM, Xscreensaver (KDE’s screensavers seem perpetually broken in all versions), PySolFC and everything necessary to build them that wasn’t already available from CentOS. It can be time consuming, but you learn an awful lot when chasing the prerequisites through RPMbuild. Please note that you should check the Fedora Updates repository for both FC18 and FC19 as well as the “Everything” list.

PySolFC on CentOS 7: Tk Errors

Saturday 19 July 2014 Leave a comment

So you either built it from SRPMs or simply got the necessary libraries and got the source. Either way, you’ve got PySolFC on your CentOS/RHEL 7 machine and it won’t work. If you try to launch it from the CLI, here’s the error:

Traceback (most recent call last):
  File "pysol.py", line 26, in 
    init()
  File "/home/ed/src/PySolFC-2.0/pysollib/init.py", line 120, in init
    root = Tkinter.Tk(className=settings.TITLE)
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1745, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: unknown color name "BACKGROUND"

I fought with this for hours and no one wants to answer the question as to what causes this. Finally, I discerned it's a problem with no defaults for Tk interface elements. The color "BACKGROUND" is defined in the default theme. Most Linux distros work this out for you through various system scripts and settings. It's not included in the packages you can get or build on CentOS 7. The answer is to create a dot-file in your home directory: .Xdefaults. You'll need one line in it:

TkTheme: clearlooks

Save the file and run this command:

xrdb -load .Xdefaults

Try again to launch PySolFC. It should work now.

Mission Technology and Technology Mission

Friday 18 July 2014 Leave a comment

In terms of our meat space activity, the mission always comes first.

Nobody said you can’t have hobbies and entertainment, but you must evaluate them as to whether they hinder the mission. No one ever really grows up to the point they need no play time and God tends to be more indulgent than you know. The stern pretense of marching troops is completely out of place, but so is the wild and unrestrained lascivious tendencies of military break-time. I’ll even go so far as to say that inebriation in itself is no sin, but if it changes your personality, you need some serious help. The point here is that if you don’t seek the joy of the Lord in things that draw your attention, you will always be wrong no matter what you do.

I openly confess that much of my blather about computer technology is just a hobby. It happens to be a pretty useful hobby in that it permits mission opportunities I can’t otherwise see. For the poor soul wrapped up in computing itself as the ultimate mission, it’s a slavery that makes him the enemy of almost everyone he otherwise helps. You cannot dive too deeply into the technology without losing your soul and your link to the rest of humanity. That such lost souls are the captains of most hardware and software development is a major source of conflict between developers and users. I keep trying to remind them that computers serve human needs; otherwise no one can justify the investment of time and resources. Like fire, computers are grand servants and fearful masters. My primary justification for getting involved is human needs filtered through mission needs.

So while my activity essentially serves the user, I still have to help the user understand they can’t just seek their own pleasure through computers. Not that I waste much time moralizing to those I help — I’ll tell them frankly how to avoid getting in trouble with whatever vice they pursue. Most people are deeply confused about the difference between what works in meat space versus what serves well in cyber space, whether it be vice or virtue they seek. CompSec that works for one serves the other just as well. The morality of computer use is in the user, not the computer itself. That’s the part I play: I do my best to help them find their own way and let God take care of the parts He didn’t put into my hands. The core of our mission from God is guiding people out of confused mythology into the truth.

Too many of my fellow believers are deeply confused about how that works. The carry a huge load of crap about what God has placed in their hands, and presume far too much authority over the lives of others. Were I to operate by such false notions, I would be serving far fewer people; the rest of my mission would wither against a senseless barrier.

The bulk of my efforts are aimed more at mediating between the all-too-natural conflict between users and providers. Not just the software and hardware providers, but the service providers, too. I am by no means a technology wizard, just some fellow with more knowledge and experience than the average user. I’m trying to keep track of hardware, software and networking technology all together while also keeping track of human fashion (in the sense of what folks tend to want at any given time). From the midst of this maelstrom I have to feel my way along and keep a firm grip on the mission calling. I have to make sure I discard all the things that conflict with that mission.

To some, it appears I’m just a wandering mind that can’t commit to anything. I move my computers among multiple operating systems rather frequently. Guess what? That’s simply a reflection of trying to know each OS well enough to be helpful. I can’t afford to house and operate a half-dozen systems and what I can afford won’t run too many virtual machines, so I have to immerse myself in whatever it is I’m using until I have a firm grasp on how it will or won’t serve the users I encounter. No one system answers all needs. I know what I like for myself, but very few people share that interest. Even when my perception sings that one thing or another is the answer to all computing ills, I know better than to put on a big campaign to sell that. People are not that easily moved away from their comfort zone.

It would require a major catastrophe with Windows to get everyone to adopt something else. That could well happen soon. In a certain sense, it already has (given the Snowden disclosures) but the broad perception hasn’t caught up with reality. I’m not in a position to do much with that, given all the factors far beyond my control. Does it not occur to anyone that those evil forces using Windows like a virus to gain a foothold in every life will also control the message those victims hear? But for some, their personal mission demands using Windows because nothing else will serve the purpose. I can’t make that decision for them; it’s immoral to try.

So take this with a grain of salt: I’m very pleased with how things are going in my testing of CentOS 7. For now, it’s totally 64-bit, with no capacity for running 32-bit binaries. And it works just fine, which is a big deal. I can’t explain all the details and you aren’t likely interested, but I hope we can spread the awareness that 64-bit computing has arrived and is now viable on its own. Starting with the bulk of desktops and laptops sold in the past year or so, the hardware is ready. Open Source software is just getting there, in the sense that most of the hassles moving to 64-bit seem to be solved so that most software works. In the past I’ve had trouble building stuff for 64-bit, but it seems coding practices have improved across the Open Source community and compiling breaks less often. At the same time, Open Source is quickly eclipsing commercial software in terms of what the user wants and wants to do.

If you as a computer user can develop a stronger focus on the mission, and your mission is not bound to the software or OS itself, you might consider keeping an eye on my computer blather on this blog. I’m going to suggest that we can change the nature of the battle for most users. Instead of fighting external hassles, they would struggle only with themselves. I can promise that using something like CentOS 7 will reduce most external threats, and it becomes a question of whether you can make it work for your mission.

Still, the biggest question is simply understanding your own mission.

Computer Ministry Notes Mid-June 2104

Wednesday 16 July 2014 Leave a comment

It’s been a quiet few days. I spent the time upgrading my laptop to stronger network diagnostic and recovery tools, starting with installing CentOS 7. It’s currently all 64-bit, with none of the typical 32-bit support for now. This is a first among the Red Hat clones. The CentOS team is working on the 32-bit stuff, but some of the packages are tricky. They’ll announce the release of the 32-bit version (“i686″) as soon as it works.

Debian is still the very best way to learn Linux. However, some folks need the shortest path to something that works with lots of hand-holding, and that would be Kubuntu. I still like OpenSUSE, but it’s a little tougher. For serious work among Westerners, I recommend CentOS. You can use my introductory book on CentOS 6, the previous release. I don’t think I’ll be writing a new guide to cover 7, but will post a few notes here.

If you haven’t chosen an AV client for your Windows computer, I am now favoring BitDefender Free. For a malware cleaner, I’ve been experiencing trouble with Malwarebytes lately, and I’ve found that Super Anti-Spyware catches things the others missed.

Finally, Revo Uninstaller is a great tool for total removal of anything the spyware removers miss. What happens is most of this crap gets bundled and when you remove the critical gatekeeper package, the other junk won’t uninstall cleanly, if at all. Revo can wipe it all away and remove every trace of it, including Registry entries.

Remember, if it has “toolbar” in the name, you don’t want it.

CentOS 7 Install Notes

Tuesday 15 July 2014 Leave a comment

Go here and choose your mirror, then your ISO. The KDE-Live and GNOME-Live don’t install, just run from DVD to get a preview. The other Live-CD is GNOME but a lot of larger packages removed so it fits on a CD. There’s a regular installer DVD, then a much larger “Everything” DVD. I chose the Netinstall.

For now, only the 64-bit is available. The CentOS developers are working in a 32-bit version but, it’s a bit of work since the sources (Red Hat) didn’t release a 32-bit version. Keep in mind: Red Hat Enterprise Linux (RHEL) is the source and it is sold as industrial grade software. It’s not as if you can’t run 32-bit stuff on it, but you have deal with dual libraries for 64 and 32. If you don’t have 4GB of RAM or more, you should wait for the 32-bit release coming out later.

If you want to try booting with UEFI enabled on your system, feel free. It does boot on most hardware, but tends to freeze at some point on a lot of machines. Be prepared to reset your BIOS to legacy boot. There is a very brief visual walk-through here at Red Hat. A more detailed installation guide is here.

Most of the stuff requiring your direction attention is collected as icons on one single masterpage once you get past the most basic hardware configuration. You’ll see a caution icon on those items which absolutely require your attentions. However, take a look at all of them. You can’t proceed until all the icons have the caution marker removed. I wish I could give you a simple walk-through on setting up your install medium (hard drive, usually), but they made it complicated. Don’t be afraid to go back through it several times until you get it right. Look around at each page you see and realize a great many items are icons you can click. For example, when you finish each item, the “Done” button is oddly placed near the upper left.

If you choose the Netinstall ISO as I did, one of the first things you’ll need to do is set up networking before trying to select your download mirror. You’ll have to supply the URL by typing it in manually. The complete mirror list is here and what you have to type into the installer follows a standard format: baseURL followed by /centos/7/os/x86_64. Have this ready at hand when you start the installer.

Under the heading of software, you can choose one of several profiles. I am assuming most of my readers will want a standard workstation desktop. For now, you can choose between GNOME3 and KDE4. If you like GNOME3, there's no sense in discussing it. If you don't know what you want, you had best try KDE as less painful for most people rather new to Linux. There are plenty of places scattered around the Net on how to configure KDE4 once installed, so I won't duplicate that here. Maybe later the CentOS folks will offer something more sane like XFCE or Mate (GNOME2 continued) for a default desktop. Right now, Mate is an add-on and XFCE is not available from any existing software repository that I know about.

One more point for installation: passwords. Again, this is industrial-grade software and annoyingly elitist on some things. One of them is passwords. The installer will grouch about almost any passwords you are likely to choose. It won't be happy until you type in something you can't possibly remember, so don't be surprised when it complains. While the Netinstaller is pulling down the packages, you'll be presented with a page that notes both the root account and the user account(s) don't have passwords. You can set the passwords while its downloading everything.

I recommend the same thing I always have because it has never failed: Use a phrase or line from a song you know you'll remember. Don't try to string together recognizable words or names. Take the first letter from each word, making sure it adds up to at least ten characters, and twelve is probably close to max. Use upper case where it makes sense. Substitute digits and symbols so that you are likely to remember it. For example, in the old days one of my first passwords was based on the song by Twila Paris, "God Is in Control":

Ginctrl! God is in ... and "ctrl" is the abbreviation for the Control key on your keyboard ... followed by an exclamation point

Try to avoid repeating any character and consider using digits (4=for, 2=to or too, 7=t, 5=s, etc.) and other symbols for some letters (@=at or e, !=L or I, $=s, #=h, etc.) and don't be afraid to punctuate as normal, such as using a comma or ampersand where appropriate. The point is that you can repeat the phrase or line of the song and type out your password consistently.

You will need two such passwords; one for the user account and one for the administrator ("root") account.

I'm sure I've forgotten something, so feel free to remind me in the comments.

Enough CentOS

Monday 14 April 2014 Leave a comment

It drove me crazy.

Yes, I am competent to make it work for most things, but some issues were just too much trouble. Keep in mind that when RHEL 6 (followed by the clones like CentOS) came out, it was capable of handling XP hardware and some early Vista stuff. Try installing it as a desktop on a Win7 machine and you will suffer. Things keep breaking because the drivers don’t match the hardware quite well enough.

The desktop machine was given to me needing repair from a law office that had closed. Turns out it was still under warranty but only to a company no longer in existence. It came with Win7 Pro but I never could get along with that once I fixed it. So I’ve run several different things, but I keep coming back to Debian Wheezy because it’s the most sane. For sure CentOS 6 was just not up to it.

So I’ve finished the tutorial and it will be my next book in a few days. It’s just fine for SOHO stuff on older XP machines, but I am not doing SOHO stuff, nor do I have any old machines like that. And CentOS is pretty corporate straight-laced and no fun.

Linux on a Toshiba Satellite C855D-S5104 (Updated)

Saturday 7 December 2013 Leave a comment

This thing is pretty low spec, starting with a dual-core 1.3Ghz processor. It comes with Win8 and I would personally never tolerate that on any of my computers. While I am capable of helping my clients set theirs up and to fix a few minor issues, Win8 seems to be the final ultimate breaking point for me. I even tried downgrading to the Win7, as that would have been tolerable to me, but the drivers were simply not capable of sustaining life on this cranky hardware.

Linux to the rescue: I tried four distros. Those that should have booted in UEFI could not get past hardware detection. They all simply hung and did nothing. And frankly, all the 64-bit versions were noticeably slower than the 32-bit version of the same distro, so there was no reason to stay with 64. Also, please note I refuse to use any DE except XFCE.

Debian Wheezy: You’ll need the RealTek firmware package on a thumb drive before you start, and it has to be in the top directory. The installer will ask for it; with that, everything works out of the box. The stock radeon drivers produces really slow display changes on some items, so you'll want the Catalyst driver (AKA fglrx). However, you won't be able drop into console mode. With Wheezy, the system seems overall snappy enough, but when you run stuff like Iceweasel, you'll notice it bogs down a lot. It's no better if you build Firefox optimized from source or install the official tarball. Seamonkey isn't quite as bad.

Xubuntu 12.04: Everything installs nicely, but there has been a long-standing issue with the rtl-8188ce wifi chipset. Canonical elected not to fix it, but you can install the kernel backports for the wifi. At this writing the specific package name is linux-backports-modules-cw-3.8-precise-generic-pae. Otherwise, your wifi will never stay connected. (No, I don't mess with anything except LTS releases.) The automatically offered Catalyst driver works fine and is better integrated; I got a console. You have to chase down the instructions for re-enabling hibernate. Overall, it runs somewhat slower than Debian Wheezy.

OpenSUSE 13.1: This is the winner. Everything works out of the box. The built-in radeon driver is much better these days and I never felt the need for Catalyst. It's very snappy, so that dropping in and out of hibernate is relatively quick. Naturally, SUSE is very observant of the legal niceties about the font rendering patents, so you'll need to hunt down the muzlocker repo and procedure. At this writing, there are no packages for 13.1, but the Factory branch works well enough. For now, this one is the keeper. It's also the only distro where Midori as supplied was worth using, which is pretty light and quick against the other standard web browsers. One other oddity: There is a USB port on the left side of the machine on which the other distros kept choking, but SUSE handles it just fine.

I tested Scientific Linux 6 (latest release) and it would run okay, but fared poorly overall. That is, the screen paints were painfully slow with the bundled radeon driver but if you use the fglrx supplied by ElRepo it tends to lock up the GUI quickly and often, requiring a hard reset. I didn't try the build-your-own route using the download from AMD/ATI. I would wait until RHEL 7 comes out and either use that or wait for the clones to build their free versions.

I horse-traded for this laptop; it's not something I would go out and buy even if I had the money. The only serious redeeming quality is the battery life, easily hitting 5 hours without recharging running on any Linux I tested.

Update: Perhaps I could waste a lot of time listing all the things about SUSE that require me to relearn just about everything I do on a daily basis, but after trying to get used to, I decided it simply wasn't worth it. Now, while Xubuntu 13.10 does run as fast on this thing as SUSE did, it's just too darned buggy and fixes for some important stuff aren't going to happen. I checked the buglist of known issues and the attitude seems to be lack of interest on the things that bother me most. I'll go back to Xubuntu 12.04 because I know it works and it's less work than just about anything else.

Update 2:Xubuntu choked, refusing to use the PAE kernel and thus losing me a half-gigabyte of RAM. Dear readers, I have been slapped upside the head by learning some things I had missed previously. It changes everything. I found out the reason there is no console when running Wheezy is because of a package I needed called "firmware-linux-nonfree" -- something not easily discovered when chasing Debian information. A ton of drivers, but in the typical Debian politics, has to be separate. It includes some firmware for Radeon. Once installed, I had no need for the fglrx driver. This means I'll also have to rewrite the draft of my book on Debian for newbies.

Debian Wheezy is the winner.

CentOS 6: Broken Dictionary

Monday 9 January 2012 Leave a comment

On CentOS 6, the GNOME Dictionary is broken.

Apparently, I’m not the only one who has noticed this. Unfortunately, I’ve not seen where anyone posted a proper fix. It worked fine in both RHEL 6 and SL 6 on this same machine.

On the other hand, I never did like it that well. The good news is the best fix is to ignore GNOME Dictionary and replace it. That replacement would be Artha. You can get the SRPM here. Just scan down for it in alphabetical order, or use the “Find” function in your browser.

When building the RPM, you’ll need to add a couple of tools not likely already installed on your system, but they are all available from the standard Yum repositories for CentOS.

Once built, on the initial start, you’ll be informed of the default keyboard shortcut. Then it will simply load and run in your notification area. Double-click any word in any application, hit the shortcut (defaults to CTRL-ALT-W) and the dictionary window opens with the appropriate information. It takes very little of your computer resources, so I recommend leaving it running.

This is a great tool, and is what GNOME Dictionary should have been.

Categories: computers Tags: , , ,

Taming the Beast: CentOS 6.2 and Inspiron 1525 Laptop

Sunday 8 January 2012 1 comment

We all know Red Hat Enterprise Linux (RHEL) is the basis for both CentOS and Scientific Linux (SL). The differences are largely cosmetic from the user’s point of view, in which the clones are legally required to change only the artwork and remove the Red Hat logos. There are differences in how each clone project goes about building the product from common sources, but I doubt you’ll find any difference in how they behave. Everything I’ve written about RHEL and SL applies to CentOS. All I’m doing here is summing up the combined notes of how we get from putting in that install DVD to a usable system.

This is what I did installing CentOS 6.2 on a Dell Inspiron 1525.

1. Install options: I chose the minimal graphics driver, because this system has Intel graphics. The Linux kernel used by Red Hat has a bug with some Intel graphics framebuffer hardware (intelfb). It’s easy to work around and fix it later. Most of the other options should be obvious. When in doubt, I typically take the defaults offered.

2. However, I don’t like dual booting two or more OSes, so I chose to “Use all space” for the disk options. When it came up, I chose the standard “Desktop” profile without trying to adjust the package selection.

3. When the installation is finished, it will kick out the DVD and wait for you to press “Reboot.” In the post-install configuration, you should simply pay attention to the options and choose what fits your needs. For example, I chose to use NTP for the system clock, and made sure to un-check the UTC box in the lower left corner.

4. After logging in, I immediately click on the Networking icon on the upper right toolbar and set up the option to connect automatically. Then I open the Terminal under Applications > System Tools, and “su” to root. This is the time to fix the Intel driver issue. I also run:

yum update
yum groupinstall "Development tools"

Almost every time I update post-install, I receive a kernel update, so this is where I reboot.

5. Upon logging in again, I add a few select packages. You can do this through the System > Administration > Add/Remove Software application or from the commandline as root:

yum install xterm bitmap-fixed-fonts aspell alacarte gnome-games gnome-games-extra gimp units vim-X11 elinks dos2unix unix2dos

The first two items after "install" go together. In particular, you might want alacarte, which allows the user to edit the GNOME menu system. GNOME Games comes in two packages. I use GIMP from time to time, and whomever packages Elinks has recently begun tracking the original project itself; good text browser but requires a bit of work getting the options as you might like them. Units is a CLI conversion calculator between various types of measures, with a long list of metric, English, etc., units. Remember to hit CTRL-C when you are done to kill it. The rest you can figure out for yourself if you need them. Also, be aware you'll need to chase down Aspell's English language package on your own. I have no idea why it's not in RHEL's package repositories, but I built it from SRPM, pulled from Fedora 13's repositories.

6. This is the time to do the first half of font fixing. After adding my favorite TTFs to my ~/.fonts folder (you'll likely have to create it), then as root, fix the fonts by changing the settings for the whole system. Finally, I rebuild the Freetype libraries. That means chasing down the SRPM, and both SL and CentOS simply point you to the upstream RHEL ones. However, I've changed a few details from my previous tutorial: I use Yum --

yum localinstall nogpgcheck freetype-2.3.11-6.el6.8.i686 freetype-devel-2.3.11-6.el6.8.i686

Logout, hit CTRL-BKSP and restart the X server with the new Freetype libs. Fonts will look much, much better. Now's the time to adjust the appearance of your desktop and set your preferred default fonts. I've always imported the Dirty-Ice GTK2 look in the process. You can probably find a copy using your favorite search engine.

7. Next comes the JDK replacement with Oracle's latest 1.6 series (1.7 fails with OpenOffice and LibreOffice), because it's much faster than the bundled OpenJDK package. I also grab the latest fuse-ntfs-3g from RepoForge. That would be the one for "el6" in this case.

8. After testing one more time to be sure, I cannot recommend Dag Wieers' RepoForge because too many of the packages are way out of date, and they still exclude Mikmod, which I use. So if you want full multimedia and other advanced third party goodies, the best remains ATrpms. However, compared to my original tutorial, I typically leave off the Mplayer and extra codecs until I run into something which simply won't work after adding all the extra goodies for Gstreamer. However, nothing in Linux land compares to using FFmpeg for converting audio and video files.

9. However, for Broadcom wifi, I don't trust ATrpms to keep up when the kernel gets upgraded. It's best to simply grab the zipped driver package direct from Broadcom. The instructions bundled in the driver are pretty good, but the point is whenever the kernel is upgraded, you simply rebuild at your convenience and re-install the module. Check the link periodically to see if they have updated to a later version; the latest is from October last year.

10. I prefer the latest versions of Joe's editor and Lynx web browser. You can chase them down from the latest Fedora SRPMs; they've always built fine with RPMbuild. As of this writing, they can be found here. As time goes on, you can go there, jump up the "Parent Directory" links a couple of layers and back down into later releases of Fedora SRPMs. I also do the same with Alpine because I really prefer doing email from the commandline. You can learn how to configure Alpine here.

10. The last two items is adding Bleachbit and whatever browsers you might like. I seldom use Firefox for anything these days, but prefer Chrome and Opera. You can find them if you like them.

11. I also fix Vim. For some strange reason, on CentOS Vim also does not honor my textwidth setting unless I put that on its own set line in my ~/.vimrc and ~/.gvimrc both.

12. The last thing I do is turn off a few services I know I won't use on my laptop:

bluetooth
firstboot
mdmonitor
netfs
nfs
nfslock
sshd

You'll find this in the menu under System > Administration > Services. Make sure the items you don't need have a red dot to the left of them. Be very careful! You could easily cripple your system by accident by turning off something basic and essential, such as the keyboard driver.

At some point you may be requested to put in some password for GNOME Keyring. It's just your login password, so don't panic.

Enjoy!

Update: Recent issue with updating ffmpeg from ATrpms. When you try to update via Yum, or via the Update Manager (that bright orange icon in the notification area), you'll get an error something like this:

Error: Package: libavcodec53-0.10-54.el6.i686 (atrpms)
Requires: libvpx.so.1()
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Here is the simplest and quickest solution; just copy and paste as a single line into any terminal window:

yum update libvpx - --enablerepo=atrpms-testing --disableplugin=*

Yes, this will change one of the core libraries from the upstream provider (RHEL). It shouldn't break anything, but it could. You be the judge; it's part of the risk of using any external Yum repo.

Categories: computers Tags: , , ,
Follow

Get every new post delivered to your Inbox.

Join 415 other followers