modifications to /etc/rc.d/rc.inet1.conf

Hey everyone, just thought I'd share my modifications to /etc/rc.d/rc.inet1.conf. These are pretty simple, but very effective in my opionion.

Basically, I really had to learn the hard way the importance of /etc/resolv.conf, and how to set a hostname. I really don't like how you have to hunt in order to get these settings in place. In my opinion, editing a textfile by hand is fine, but doing it all in one place is simpler than going to different files.

Then again, people may view this as an abomination, and respond by saying things should be kept the old way. Take a look and let me know what you think :)

# /etc/rc.d/rc.inet1.conf
.

.

.


# Set hostname

# This will set your hostname as defined in /etc/hosts.
# This only works if you have a properly defined /etc/hosts file.
# In order for these settings to take effect, after properly modifying
# /etc/hosts, you must restart network (/etc/rc.d/rc.inet1 restart),
# exit your current shell, and log back in--or log in to a new shell.
# Please refer to man /etc/hosts for more information.

hsts=$(cat /etc/hosts | grep 127.0.0.1 | egrep -v 'localhost|Arnt' | cut -f 2)
if [ -n $hsts ]; then
        HOSTNAME=$hsts
    hst=$(echo $hsts | sed 's/\..*//')
    echo $hsts > /etc/HOSTNAME
    echo $hst > /etc/HOSTNAME_S
    hostname -F /etc/HOSTNAME_S
fi

# Config information for eth0:
.

.
# Default gateway IP address:
GATEWAY=""

# DNS Settings

# Either run dhcpd once to create a temp /etc/resolv.conf and copy values
# below, or get the values from your ISP / Router / Modem.
# Uncomment nameservers as necessary for your network.
domain=ph.cox.net
nameserver1=192.168.0.1
#nameserver2=68.105.28.11
#nameserver3=68.105.29.11

# Create resolv.conf

# Uncomment nameservers as necessary for your network.
if [ -x /etc/resolv.conf ]; then
 echo "" > /etc/resolv.conf
else
 touch /etc/resolv.conf
 echo "domain $domain" > /etc/resolv.conf
 echo "nameserver $nameserver1" >> /etc/resolv.conf
#echo "nameserver $nameserver2" >> /etc/resolv.conf
#echo "nameserver $nameserver3" >> /etc/resolv.conf
fi


So basically, to summarize, skip the comments and the ethernet section (those are still there but you know what it looks like). The parts I added was the hostname section, the DNS settings, and creating resolv.conf. These easily make resolv.conf for you when rc.inet1 is being run--in other words when network is being brought up. The hostname according to the hostname manpage is supposedly also setup when rc.inet1 is ran, but it doesn't accept changes to /etc/hosts on the fly. I didn't like this, which is why I modified rc.inet1.conf as such.

This script requires you to have a properly modified /etc/hosts, like such:

# For loopbacking.
127.0.0.1    localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1          bpm37093.centauri.net          bpm37093  
192.168.0.200   beta.centauri.net                    beta
192.168.0.210   v766.centauri.net                    v766
192.168.0.220   bpm37093.centauri.net          bpm37093    

The nice thing about adding this section is that, you can have your hostname update on the fly, all you have to do is restart the network (/etc/rc.d/rc.inet1 restart), and then make sure to exit and log back in to your shell/ log in to a new shell. And viola! Your hostname will now show up :)

The DNS settings, well ... the easiest way to get those is to either run dhcpd once--which will auto generate a resolv.conf for you. Once you have those settings  you can populate the DNS settings sections with what is suitable for your network.

Alternatively you don't have to run dhcpd. You can just get the settings from your router, or modem, and go from there.

Also, you may not need as many nameservers. Simply uncomment the appropriate nameserver variables/ echo statements as neccessary for your network. Also, you can add additional nameservers, you just have to add another nameserver line in the dns section and an extra echo statement in the resolv.conf section. However 3 is more than enough (2 is generally what most ISP's use, the 3rd is for your router if it supports it).

Below are links to the modified /etc/rc.d/rc.inet1.conf file and an accompanying md5 file (so you can sure what youre downloading isn't some bullshit garbage:b).
 - rc.inet1.conf - modified: http://www.datafilehost.com/d/57b5c9f0
 - rc.inet1.conf - md5sum: http://www.datafilehost.com/d/86fc1021

Mozilla Firefox 35: Profile Guided Optimization

While inspecting the Firefox SlackBuild, I noticed it had an elif statement dedicated to PGO (Profile Guided Optimization):

if [ "$ARCH" = "x86_64" ]; then
  PGO=${PGO:-yes}
else
  PGO=${PGO:-no}
fi

This feature is mentioned in the SlackBuild bundled w/ the 24.1.0 extended support release (i.e. the stock 14.1 package). I decided to investigate and see what this fuss is about.

From Mozilla's FAQ:

"The Mozilla build system contains support for building with Profile-Guided Optimization (PGO) with GCC 4 or newer and Microsoft Visual C++ 2005 (Professional Edition) or newer. A PGO build consists of two passes: a first pass to build instrumented binaries, then a second pass to re-build optimized binaries using profile information gleaned from running the instrumented binaries. The Mozilla build system will run both passes for you, as well as a profile generation script in between."

From Wikipedia's page on PGO:

"Optimization techniques based on analysis of the source code alone are based on general ideas as to possible improvements, often applied without much worry over whether or not the code section was going to be executed frequently though also recognizing that code within looping statements is worth extra attention.

The first high-level compiler, introduced as the FORTRAN Automatic Coding System in 1957, broke the code into blocks and devised a table of the frequency each block is executed via a simulated execution of the code in a Monte Carlo fashion in which the outcome of conditional transfers (as via IF-type statements) is determined by a random number generator suitably weighted by whatever FREQUENCY statements were provided by the programmer. ^[3]

Rather than programmer-supplied frequency information, profile-guided optimization uses the results of profiling test runs of the instrumented program to optimize the final generated code.^[4][5] The compiler is used to access data from a sample run of the program across a representative input set. The results indicate which areas of the program are executed more frequently, and which areas are executed less frequently. All optimizations benefit from profile-guided feedback because they are less reliant on heuristics when making compilation decisions. The caveat, however, is that the sample of data fed to the program during the profiling stage must be statistically representative of the typical usage scenarios; otherwise, profile-guided feedback has the potential to harm the overall performance of the final build instead of improving it."

I decided to compile Mozilla Firefox 35 w/ PGO enabled. It took approximately 4 solid hours to compile along with 8GB of disk space.

I decided to run some tests of my own to determine the validity of this optimization hype. A quick Google search for the term "browser benchmark," led me to futuremark's peacekeeper browser benchmark:

 http://peacekeeper.futuremark.com/

Peacekeeper tests a variety of operations, including:

 > Rendering: manipulate DOM tree in real-time.
 > HTML5 - WebGL: MJS Matrix/Vector package.
 > HTML5 - Video: tests supported video formats.
 > HTML5 - Web Worker: tests javascripts multithreading.
 > HTML5 - Game: 2D sprite game (modified version of Crafty). Sprites increase as test progresses to increase load.
 > Canvas: HTML5 Canvas.
 > Data test suite:
 > DOM operations: the Document Object Model Javascript API.
 > Text Parsing:

(A detailed explanation of the tests ran in the benchmark suite can be found at the following link.)

The results were very revealing! 

 - Mozilla-Firefox-35.x86_64:                             3521 Points
 - Mozilla-Firefox-35.x86_64.pgo-enabled:       3724 Points

(The above links provide the detailed results for each package.)

That settles the argument: Firefox compiled w/ profile guided optimization has a measurable performance gain.

I am currently using the pgo-enabled Firefox build and will continue to do so unless it: creates a security risk, introduces regressions, or breaks future builds.

I have provided a PGO-enabled Firefox package for those of you who want to try it out and don't want to invest the time (and disk space), to compile:

 -> mozilla-firefox-35.0.pgo-x86_64-1.txz
 -> mozilla-firefox-35.0.pgo-x86_64-1.md5

I encourage you guys to try out the PGO-enabled build on your systems and run through the peacekeeper benchmark! I'm very curious to see any differences in performance! Also, I know I haven't provided a x86 (32bit), build yet, that will follow soon for both the vanilla firefox-35 and the PGO-enabled build!

*Also, I am asking my readers a huge favor: if anyone has an ftp, a repository, or server where I can upload these packages, I would greatly appreciate any input! These packages deserve a proper home!*

Diego

Mozilla Firefox 35

Mozilla is currently on version 35 of firefox, and slackware current is on 34. I was aghast when I realized that I was still using version 24, and even more so when I realized that 14.1 had officially upgraded to 31 (extended support release).

I compiled version 34 and installed it in my system (14.1 x86_64), and then decided to try out 35. I grabbed the source from mozilla's ftp and built it against the slackbuild provided in current for version 34.

So far it works great! No issues whatsoever. I am currently re-compiling w/ pgo support enabled. Although pgo was enabled in the slackbuild by default in version 24 (stock 14.1 release), it has since been disabled in current. As mentioned in the comments it has definetely more than doubled the compile time, but I'm sticking it out to see if there is any performance enhancement with pgo enabled.

Below is a link I've provided for the lazy who wish to try out the latest (& greatest), Mozilla Firefox release 35 on there systems (and don't want to wait the hour or 2 to compile)!:

mozilla-firefox-35.0-x86_64-1.txz:
 - http://www.datafilehost.com/d/3ebe4440

mozilla-firefox-35.0-x86_64-1.md5:
 - http://www.datafilehost.com/d/2bd93007


I will build an x86 for on my poweredge later this evening. Stay tuned!

My first commit to Slackbuilds

This is my first commit to Slackbuilds! Not a very big contribution, but very cool nonetheless! Every little bit counts!

Robby Workman commit a2ecf74a7618ecd1341a70006af9d50bbb8bcf05
Author: Robby Workman <rworkman@slackbuilds.org>
Date: Wed Oct 15 16:39:32 2014 -0500

multimedia/flashplayer-plugin: Updated for version 11.2.202.411.

Thanks to Diego Pineda.

Modification to rsync_slackware_patches.sh

On the Slackware docs page, in the beginners_guide--Watching for updated packages section--I noticed a flaw/feature/something I didn't like in the example script provided. Just a simple mod really. The script by default has the arch hardcoded, when honestly it would be better pulled from the system.

There is the option to set the arch to something different, which is fine if you want to rsync for a different arch than whats on your system (say have a local copy for another machine at your employ), but I believe it should have been set to the following:

# What architecture will we be mirroring? The default is 'x86' meaning 32bit.
# Alternatively you can specify 'x86_64' meaning 64bit. The value of SARCH
# determines the name of the slackware directories.
# This value can be overruled via the '-a' commandline parameter;
SARCH=${SARCH:-"x86"}

It should be changed to this:

SARCH=$(arch)

This will set the correct arch according to what your system has. Using the case statement -a switch will also allow you to set it should you need to still.


Links:

http://docs.slackware.com/slackware:beginners_guide

rsync_slackware_patches.sh - original

rsync_slackware_patches.sh - modified

Regular Expressions

I suck with regular expressions.

I'm always finding myself in the situation where I am using google to try and find a solution to an answer.

So, today I was trying to figure out an expression to use in a script when, I stumbled upon the following site:

http://www.regexr.com/

The nice feature of this site: it allows you to test your expression on the fly, and show you your results on the site.

Interactive learning at its best. I was actually able to figure out the regex I needed after testing a few combinations.

Diego

Updating timestamp across filesystem

So my poweredge 750 still believed it was 2004. After updating the system time, I realized my x86 Slackware 14.1 install had all of the files installed with timestamps from 10 years ago. This is not good, and will make your computer blow up with a bunch of wierd errors. So I had to resolve to the ancient fighting art of bash fu to resolve it:

boot to install disk:

mkdir /foo

mount root partition to foo (in my case R0 array)

mount /dev/md1 /foo

mount dev, proc, and sys via bind mountpoints. First define temporary variable:

a='dev proc sys'


and then apply the following for loop:

for i in $a; do mount --bind /$i /foo/$i; done

I almost forgot to add this; you need to chroot into foo:

chroot /foo

Since we want to update all directories with the exception of dev, proc, and sys, we can make another variable containing all root sub directories except the ones we've mounted via --bind, and update the timestamps on the results.

I wrote the following script to accomplish this task:

#!/bin/bash
# update timestamp.sh

b=$(ls / | egrep -v "dev|proc|sys")
for i in $b; do
cd /$i && find . -exec touch -h {} \;; \
done

exit 0
‪#‎EOF‬

Notes:

It is important to update the hwclock of the system prior to running this script, otherwise it will keep whatever time was on the BIOS. If your system can access the rtc device, you can update via hwclock:

hwclock --set --date "11/23/2014 13:50:30"

at which point you can update the system time via:

hwclock -s

I've tried this script once before w/o the -h switch, but it screwed up my system. It updated all the timestamps on files great, with the exception of the important ones--symlinks. Think vmlinuz.. right. 

With the -h switch however it ran great and everything was good to go.

(I originally shared this in late august on my fb page, but realized it would be better served here since I only have like 4 friend in RL that understand Linux.)

Links:

http://www.linuxquestions.org/questions/linux-general-1/update-time-stamp-during-mount-4175520145/

Notes:

 - November 23, 2014: I realized that the script wouldn't run as it was written. The for loop needs to be changed from:

for i $b; do 
cd /$i \
find . -exec

to:

for i in $b; do
cd /$i && find . -exec touch -h {} \;; \

the 2nd iteration forces the find/touch command to be executed upon completion of the initial change directory command.