Showing posts with label productivity. Show all posts
Showing posts with label productivity. Show all posts

02 October 2013

About those doughnuts ...

In a recent post, I closed:
Dollars to doughnuts, there is 'more than one roach' lurking.
I'll cover a bet that there are not tested backups in that shop
I had occasion to speak with that person again the other day. No backups, no thought to plan for such by that person's predecessor, and so by definition, no Disaster Recovery Plan
Staufs storefront
I am looking forward to getting a box of doughnuts -- from the DK would be nice. Please make sure two Apple Fritters are in there, as the other coffee vultures always grab the one I wanted. The Doughnut Kitchen is close to Staufs

13 June 2013

Phone call: 'I've got this sick machine ...'

me:  well, why it is sick?

them:  yum complains about a missing signing key

me: so install the key; it is down in /etc/pki/rpm-gpg/, and rpm --import ... will do the trick

them: that directory is not there

me: who set up the machine?

them:  well, I was handed it, and ...

me: so, take a level zero backup and then clean up the machine before trying to work on it, or deploy a new one

them: well, I can't

I just got off that call from a friend in a new employment situation

The technical fix was outlined by me long ago, and I sent an email with the link along to the person calling

BUT: Fixing the mindset inside the caller's head: do not try to work in a undefined (here: broken) environment is harder

But the caller has a problem in their work-flow process; a fix has to be done; sooner is probably better than later; a broken machine in production is 'technical debt', pure and simple.  Fundamental expectations are not met; binary partition will not work well to isolate problems, as more than one piece is probably broken.  It will break again, and a perception may well form that the caller may be the problem, rather than the broken environment they were handed

Be sure to make a note to yourself to also address the broken process that permitted that machine to escape into production.  Dollars to doughnuts, there is 'more than one roach' lurking.  I'll cover a bet that there are not tested backups in that shop

21 September 2010

sitting in great connectivity ...

... sure makes a difference, seemingly

I do daily checkouts from the FreeSwitch project, and run the same build script on a CentOS box inside our local network (which is nominally down a data link that is 3 x T-1 wide), and another that is up at a data center, and has the ability to sustain a 3.5 GByte/sec transfer rate indefinitely (it has been the disaster failover site for the periodic 'Victoria's Secret' soft pr0n 'strut their stuff' webcast)

I synchronized builds on the two boxes yesterday, so they happened to be at the exact same checkout from upstream's version control system level. Today, I opened a couple of consoles, and fired off the build commands within a second of one another. The first part of that script is to checkout current to HEAD, and then off into the builds. I've marked the two units in alternating colors so the comparisons stand out better

Unit A:

Unpacking objects: 100% (38/38), done.
From git://git.freeswitch.org/freeswitch
184f395..f7d16ec master -> origin/master
Updating 184f395..f7d16ec
Fast-forward
libs/freetdm/src/include/private/ftdm_types.h | 2 +-
src/mod/applications/mod_spandsp/mod_spandsp_fax.c | 6 +-
src/mod/codecs/mod_codec2/Makefile | 14 ++
src/mod/codecs/mod_codec2/mod_codec2.c | 161 ++++++++++++++++++++
src/mod/endpoints/mod_sofia/mod_sofia.c | 23 +++
src/mod/endpoints/mod_sofia/mod_sofia.h | 1 +
src/mod/endpoints/mod_sofia/sofia_glue.c | 21 +++
src/switch_ivr.c | 4 +-
8 files changed, 226 insertions(+), 6 deletions(-)
create mode 100644 src/mod/codecs/mod_codec2/Makefile
create mode 100644 src/mod/codecs/mod_codec2/mod_codec2.c

real 0m1.105s
user 0m0.425s
sys 0m0.090s
/home/herrold/vcs/git/freeswitch

Unit B:

Unpacking objects: 100% (38/38), done.
From git://git.freeswitch.org/freeswitch
184f395..f7d16ec master -> origin/master
Updating 184f395..f7d16ec
Fast-forward
libs/freetdm/src/include/private/ftdm_types.h | 2 +-
src/mod/applications/mod_spandsp/mod_spandsp_fax.c | 6 +-
src/mod/codecs/mod_codec2/Makefile | 14 ++
src/mod/codecs/mod_codec2/mod_codec2.c | 161 ++++++++++++++++++++
src/mod/endpoints/mod_sofia/mod_sofia.c | 23 +++
src/mod/endpoints/mod_sofia/mod_sofia.h | 1 +
src/mod/endpoints/mod_sofia/sofia_glue.c | 21 +++
src/switch_ivr.c | 4 +-
8 files changed, 226 insertions(+), 6 deletions(-)
create mode 100644 src/mod/codecs/mod_codec2/Makefile
create mode 100644 src/mod/codecs/mod_codec2/mod_codec2.c

real 0m15.607s
user 0m0.168s
sys 0m0.096s
/home/herrold/vcs/git/freeswitch

One box is running an 386 kernel, and the other x86_64; memory is somewhat smaller on the x86_64. The 'horsepower' of each is roughly the same

Unit A:

[herrold@centos-5 ~]$ ssh freeswitch.pmman.com uname -a
Linux freeswitch.pmman.com 2.6.18-194.11.3.el5PAE #1 SMP Mon Aug 30 17:02:48 EDT 2010 i686 i686 i386 GNU/Linux
[herrold@centos-5 ~]$ ssh freeswitch.pmman.com free
total used free shared buffers cached
Mem: 6226068 4427212 1798856 0 303156 3936312

Unit B:

[herrold@centos-5 ~]$ uname -a
Linux centos-5.first.lan 2.6.18-194.11.3.el5xen #1 SMP Mon Aug 30 16:55:32 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
[herrold@centos-5 ~]$ free
total used free shared buffers cached
Mem: 3072000 3036352 35648 0 291852 1790652

Unit A:

[herrold@centos-5 ~]$  ssh freeswitch.pmman.com dmesg \| grep -i bogo
Calibrating delay loop (skipped), value calculated using timer frequency.. 3990.15 BogoMIPS (lpj=1995079)
Calibrating delay using timer specific routine.. 3990.04 BogoMIPS (lpj=1995020)
Total of 2 processors activated (7980.19 BogoMIPS).

Unit B:

[herrold@centos-5 ~]$ dmesg | grep -i bogo
Calibrating delay using timer specific routine.. 6652.60 BogoMIPS (lpj=13305207)

Unit A:

[herrold@centos-5 ~]$ ssh freeswitch.pmman.com cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.224
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3990.44

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.224
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3990.02

Unit B:

[herrold@centos-5 ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz
stepping : 6
cpu MHz : 2660.050
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu tsc msr pae cx8 apic mtrr cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni est ssse3 cx16 lahf_lm
bogomips : 6652.60
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz
stepping : 6
cpu MHz : 2660.050
cache size : 4096 KB
physical id : 1
siblings : 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu tsc msr pae cx8 apic mtrr cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni est ssse3 cx16 lahf_lm
bogomips : 6652.60
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

But ...

Unit A:

Wrote: /home/herrold/rpmbuild/RPMS/i386/freeswitch-sounds-0.0.20100921.git-1.i386.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.3898
+ umask 022
+ cd /home/herrold/rpmbuild/BUILD
+ cd freeswitch-20100921
+ '[' /var/tmp/freeswitch-0.0.20100921.git.root '!=' / ']'
+ rm -rf /var/tmp/freeswitch-0.0.20100921.git.root
+ exit 0

real 17m56.699s
user 13m18.982s
sys 3m10.880s

real 24m50.468s
user 18m2.521s
sys 4m56.827s
[herrold@freeswitch freeswitch]$

Unit B:

Wrote: /home/herrold/rpmbuild/RPMS/x86_64/freeswitch-sounds-0.0.20100921.git-1.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.90424
+ umask 022
+ cd /home/herrold/rpmbuild/BUILD
+ cd freeswitch-20100921
+ '[' /var/tmp/freeswitch-0.0.20100921.git.root '!=' / ']'
+ rm -rf /var/tmp/freeswitch-0.0.20100921.git.root
+ exit 0

real 27m27.666s
user 8m27.160s
sys 3m25.909s

real 48m25.064s
user 11m34.027s
sys 5m15.264s
[herrold@centos-5 freeswitch]$

That is, the older, 2GHz Xeon is running away from the newer 2.6 GHz Core Duo. Quite the discrepency there, but the numbers don't lie. Perhaps due to the local load of being a X-desktop on 'centos-5' [no local xen domU are presently running on it], and NOT running X on the remote server. Interesting 'food for thought' of a problem to research as to the why's and wherefore's on causation

09 September 2010

office background noise

A question in IRC: Do you listen to music online?

17:07 =orc_orc> xmms is playing: Peshay / Pacific atm
17:08 =orc_orc> the library has more to 'rip' than I will ever be able to grow
tired of, for free
17:08 =orc_orc> NFS makes the OGG files available freely, throughout the LAN
17:08 =orc_orc> (through an RO export)

As I recall, I used 'grip' build under CentOS 4 to populate that music archive, which xmms randomly wanders through

27 July 2010

This one needs to be written while it is fresh

I write about CentOS, annoyances, and nuisances all the time. 'Lest people consider me a grumpy old man, never pleased, I'll drop my guard a bit here and now, and perhaps just this once

I just posted this in Joe Landman's comments section to his blog, but it might get lost. It bears repeating

Russ Herrold says:
July 26, 2010 at 6:23 pm

Hi, Joe

I have not had the chance to write the blog post, but it will get written.

My Dell laptop died, and I sent it to the following folks for refurb, based on some strong recommendations in a TX LUG mailing list

It came back fine, but then died.

http://twitpic.com/20p796

jailhouse stripes on the laptop

I was a slacker and did not ship it back right away. Even after the warranty interval expired, however they took it thru their intake, ID’d a bad video card they had added during the refurb, and swapped it out. gratis

And then shipped it back to me FedEx ... again gratis

One guess who I’ll be using from now on, for out of warranty repairs of Dell kit

http://www.parts-people.com/
512-339-1990

Tell them I sent you ;) Please say 'thanks again' for me

– Russ herrold

15 January 2009

One view of Contacts, everywhere

Rolodex
I've been working through cleaning up my Gmail Contacts entries the last few days. Google released an extension of their mobile application suite which does a basic but workmanlike bi-directional sync between the webbish Gmail Contacts information, and my Blackberry's internal store from the mobile device's point of view. Thanks, Gmail team at Google.

I had looked in to writing a 'third party control' synchronization tool, so that I could have an authoritative store safely behind the firewalls, and in a CentOS LDAP backend. Google publishes the needed API; RIM is less open, but the API and a device simulator is available as well behind some Export Control disclaimers, identity harvesting, and such. In the FOSS world, the fruit from the barry project is maturing nicely as well, but tackling cracking open the datastore blobs (which RIM manipulates with some Java code in their implementation and SDK) is somewhat tricky and it is not for the timid.

I write this having 'bricked' the phone a couple nights ago, and had to fall back to restoring from a backup image.

You _do_ take and test Level 0 backups at least weekly, right?
Blackberry Curve 8320


Just as I thanked Google, RIM also deserves 'kudos' for continuing to roll out fixes, and feature set upgrades on the phone chassis; it has added video movie capture, dictation ('voicenote') from them, and as it has a sufficiently 'open' API, I have been able to easily add applications from Google mobile, Remember the Milk, and Jott all co-existing on that chassis. Add Google Docs, and drop.io tools, for mobile productivity completeness.

High recommendation for a high end approach to their portable devices, but the trackball retention ring on my unit is cracked and the dirty trackball issue others mentioned is also there. Apple probably had it right early on, choosing the touch screen approach which the iPhone uses. But Apple and ATT think they can profit maximize with an exclusivity (i.e., non Free and non-discriminatory access to the platform) deal in the US; They are free to their opinion, of course, but not with my support.

Back to the matter at hand, the Blackberry and the Gmail Contacts sync works sufficiently well that I'll leave it running; I need to learn a bit about how to do edits and sync in stages, rather than doing all ACDs ('Adds, Changes, and Deletes') in a single pass, so that I don't end up with 2, then 4, then 8 slightly different records shuttling back and forth. The proper sequence is probably: Edit to a single record first and sync; Delete the strays and sync. Add's seem not to be a problem.

Apple emac PPC all in oneOnce I have the process down, I'll still have to face that LDAP and third party local control [CentOS from the office] issue. I'll probably pick up an Apple Mini based on the Intel processors for some other development needs, and so I can retire my trusty PPC eMac, which will not handle the OS/X 10.5 OS level. The later OS/X versions have markedly beter LDAP and synchronization tools, and unlike RIM, Apple is pretty clear about the need to 'keep up' with the hardware franchise in order to get later enhancements.