Present Location: News >> Blog

Blog

> Fish Oil
Posted by prox, from Charlotte, on September 07, 2013 at 16:27 local (server) time

A few weeks ago I posted a blog entry about cholesterol, specifically the lack of my HDLs.  One of the suggestions I read about to increase HDLs involved taking fish oil.  So, I've been trying this.

I picked up some Barlean's Fish Oil and have been taking two teaspoons of it per week (Monday and Thursday, usually).  There was some question of whether it should be refrigerated so I decided to keep it in chilled.

I was going to give it six (6) months and see if it made any impact on my HDLs.  I figured it wouldn't have any other effect on my health but it looks like it might be giving me more energy while swimming.  Check out this graph of my swim times:

Swimming

My times have slightly improved.  I feel like I have more energy than I did before taking the fish oil, oddly enough.  However, correlation does not imply causation so I can't be sure that the reason I have more energy is solely because of the fish oil.  However, I will be continuing with it!

Comments: 0
> Junos and SLAX Stupidity
Posted by prox, from Charlotte, on July 31, 2013 at 21:28 local (server) time

Well, it's official.  I suck at SLAX.  I managed to find myself in a small situation at work where I needed to create an op script that's called by some conditions under event-options.  Anyway, I always get stuck on the most simplest of things with SLAX and today was no different.

I couldn't figure out how to activate and deactivate portions of the Junos configuration, of all things.  I'm talking about stuff like this:

{master:0}[edit]
prox@enterprise# show protocols 
bgp {
    group foobar {
        peer-as 64512;
        neighbor 10.0.0.2;
    }
}

{master:0}[edit]
prox@enterprise# deactivate protocols bgp group foobar 

{master:0}[edit]
prox@enterprise# show protocols                           
bgp {
    inactive: group foobar {
        peer-as 64512;
        neighbor 10.0.0.2;
    }
}

{master:0}[edit]
prox@enterprise# activate protocols bgp group foobar      

{master:0}[edit]
prox@enterprise# show protocols                         
bgp {
    group foobar {
        peer-as 64512;
        neighbor 10.0.0.2;
    }
}

For some reason, this was not easily searchable on Google or Bing.  I did manage to figure it out, though.  To deactivate a piece of the configuration, do the following:

var $config-change = <configuration> {
     <protocols> {
          <bgp> {
               <group inactive="inactive"> {
                    <name> foobar;
               }
          }
     }
}
var $connection = jcs:open();
var $results := { call jcs:load-configuration( $connection, $configuration = $config-change ); }
if( $results//xnm:error ) {
     for-each( $results//xnm:error ) {
          <output> message;
     }
}
var $close-results = jcs:close($connection);

The above was easily found by just doing something like "show configuration protocols bgp | display xml" on the CLI.  However, what I wasn't able to find was how to activate the section, again:

var $config-change = <configuration> {
     <protocols> {
          <bgp> {
               <group active="active"> {
                    <name> foobar;
               }
          }
     }
}
var $connection = jcs:open();
var $results := { call jcs:load-configuration( $connection, $configuration = $config-change ); }
if( $results//xnm:error ) {
     for-each( $results//xnm:error ) {
          <output> message;
     }
}
var $close-results = jcs:close($connection);

The active="active" piece was all that was needed.

I really would prefer to code op scripts in Perl or Python but I don't think I have much of an option when calling them from event-options.  Oh well.

Comments: 2
> Cholesterol
Posted by prox, from Charlotte, on July 25, 2013 at 21:50 local (server) time

I'm a little puzzled.  Every year or two (uh, or three) I have a physical and get my cholesterol taken.  It's constantly going down, which I suppose is a good thing and an indication my diet is not horrible:

Cholesterol Plot

This year, though, my HDL levels are lower than they should be.  According to my doctor, they should be 40 mg / dL for men.  Mine is now 38 mg / dL.

I've heard people say I should quit smoking, exercise, and keep my mass down.  I can't quit smoking because I never started.  I swim 2,600 yards ~3 three times per week and, at least according to Garmin Swim, burn 500+ calories every time.  I jog 45-50 minutes every 2-3 weekends.  I suppose I could improve on this, since I used to swim 4-5 times per week.  I think my mass is fine.

Other folks have told me to start taking fish oil.  To be honest, I thought taking fish oil was intended to lower cholesterol for folks who are in the severe red.  I eat fish once or twice a week (mmm.. salmon and tuna), but apparently even if I ate fish every day it wouldn't be sufficient.

What does everyone else think?  I'll have to admit I have done very little empirical research on this topic.

Comments: 0
> FreeBSD 9.0 and VirtualBox
Posted by prox, from Charlotte, on July 15, 2013 at 01:30 local (server) time

I finally decided to upgrade dax from FreeBSD 8.3-RELEASE to 9.1-RELEASE while stepping through 9.0-RELEASE.  As alawys, I hit a snag.

When stepping through 9.0-RELEASE to get to 9.1-RELEASE (I'm not sure if this is really required but I figured it wouldn't hurt) I ran into a nasty situation with the VirtualBox kernel modules.  Specifically, the kernel module vboxnetflt.ko in the 4.2.16 version of VirtualBox causes the FreeBSD kernel to panic before it's even mounted the root file system:

[.. output trimmed ..]
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
coretemp2: <CPU On-Die Thermal Sensors> on cpu2
coretemp3: <CPU On-Die Thermal Sensors> on cpu3
Timecounters tick every 1.000 msec


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address    = 0xc
fault code          = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80cb2717
stack pointer          = 0x28:0xffffffff80d17ab0
frame pointer          = 0x28:0xffffffff80d17ad0
code segment        = base 0x0, limit 0xfffff, type 0x1b
               = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process          = 0 (swapper)
trap number         = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff804d752e at kdb_backtrace+0x5e
#1 0xffffffff804a20e7 at panic+0x187
#2 0xffffffff806e9140 at trap_fatal+0x290
#3 0xffffffff806e9489 at trap_pfault+0x1f9
#4 0xffffffff806e994f at trap+0x3df
#5 0xffffffff806d3def at calltrap+0x8
#6 0xffffffff80c94c52 at supdrvCleanupSession+0x52
#7 0xffffffff80c94ee1 at supdrvCloseSession+0x11
#8 0xffffffff80c9622b at supdrvIDC+0x10b
#9 0xffffffff80cf3ee6 at supR0IdcNativeCall+0x16
#10 0xffffffff80cf40a0 at SUPR0IdcClose+0xa0
#11 0xffffffff80cf3809 at vboxNetFltInitIdc+0x79
#12 0xffffffff80cf3857 at vboxNetFltInitGlobalsAndIdc+0x27
#13 0xffffffff80cf312b at vboxnetflt_modevent+0x3b
#14 0xffffffff80cfb634 at ng_mod_event+0x44
#15 0xffffffff804912c8 at module_register_init+0xb8
#16 0xffffffff80456ac7 at mi_startup+0x77
#17 0xffffffff8027177c at btext+0x2c
Uptime: 2s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the system now.
Rebooting...

As a result, dax was stuck in an endless reboot for 15-20 minutes as I drove home, since I did the upgrade while mobile.  It also took me awhile to figure out how to not load the vboxnetflt.ko at boot since I only had access to the loader prompt.  The disable-module directive didn't seem to work:

OK lsmod
 0x200000: /boot/kernel/kernel (elf kernel, 0xa46fb0)
  modules: x86bios.1 io.1 ufs.1 kernel_mac_support.4 [.. trimmed ..] 
 0xc47000: /boot/kernel/linux.ko (elf obj module, 0x45078)
  modules: linux.1 
 0xc8d000: /boot/kernel/accf_http.ko (elf obj module, 0x17d0)
 0xc8f000: /boot/kernel/coretemp.ko (elf obj module, 0x29e0)
 0xc92000: /boot/modules/vboxdrv.ko (elf obj module, 0x59c40)
  modules: vboxdrv.1 
 0xcec000: /boot/modules/vboxnetadp.ko (elf obj module, 0x5bf0)
  modules: vboxnetadp.1 
 0xcf2000: /boot/modules/vboxnetflt.ko (elf obj module, 0x7568)
  modules: vboxnetflt.1 
 0xcfa000: /boot/kernel/netgraph.ko (elf obj module, 0x15440)
  modules: netgraph.12 
OK disable-module vboxnetflt
vboxnetflt was not found
OK disable-module /boot/modules/vboxnetflt.ko
/boot/modules/vboxnetflt.ko was not found
OK disable-module vboxnetflt.1
vboxnetflt.1 was not found

It would always load vboxnetflt.ko, for some reason.  Apparently the trick was to unload all modules, load the kernel manually, and then boot.  These steps got the system up and running again.  The first thing I did was rename vboxnetflt.ko, of course.

I'm hoping this problem is fixed in 9.1-RELEASE, which I don't have time to mess with now but I'll probably get to tomorrow evening.  I wasn't able to find much via web searching related to this type of problem, unfortunately.  I can't be the only one encountering this, can I?

Update: It looks like taking the vbox* modules out of loader.conf and loading them after the OS is started fixes the problem.  For some reason vboxnetflt.ko freaks out when loaded at boot.  Instructions here are good to follow, too.

Comments: 0
> LTE on The Nexus 4
Posted by prox, from Herndon, on June 04, 2013 at 18:53 local (server) time

We all know by now that the Nexus 4 sports an LTE radio that is unsupported and has recently been disabled by Google.  However, it does work if you enable it.  Should you bother, though?

I'll try to answer that question, given I've spent a few days with it in two locations (Herndon, VA and Charlotte, NC) on T-Mobile.

Nexus 4 on T-Mobile LTE

First, the radio will only work with the 2.0.1700.33 radio firmware, which is the original firmware that was installed on my Nexus 4.  This radio firmware works fine with Android 4.2.2, even though it was originally released in 4.2.1.  Although most people will say that radio firmwares aren't tied to specific Android versions, I've encountered at least one situation where this wasn't the case - so, beware.  This radio firmware can be downloaded from here.

Second, the radio only supports E-UTRA band IV.  This is AWS, with a center frequency of 1700 MHz.  Here's a handy list of all frequency bands used by the air interface of LTE, E-UTRA.  As a result, you'll be able to use it with T-Mobile USA, among other things.

Third, lots of things don't work.  This is hardly shocking news, since the darn thing is unsupported.  Here's a short list:

Other than the above, it does work.  If you decide to use it, be aware that the FCC has technically not approved the Nexus 4 for LTE operation and you'll most likely have to stick with the 2.0.1700.33 radio and some sort of unofficial Android build (CyanogenMod works) forever.

Comments: 0
> Punta Cana Vacation
Posted by prox, from Charlotte, on June 01, 2013 at 19:27 local (server) time

I recently went on a nice vacation in the Punta Cana area of the Dominican Republic.

I stayed at the Riu Palace Punta Cana, an all-inclusive resort on the beach.  It was the first time I've stayed at an all-inclusive resort so it took awhile to get used to the fact that yes.. everything is included.  The beach scene was fairly idyllic:

Punta Cana Beach

On the last day I took an excursion, which involved Snuba and driving a speed boat.  The Snuba experience was pretty fun but it's too bad there wasn't much to see in the area where we were.  Driving (piloting?) the speed boat was an interesting experience, one I would like to do again, given the opportunity!

One odd thing about the resort was its Internet connectivity.  There was included Wi-Fi powered by a bunch of what looked to be WDS repeaters on a flat 172.21/16 IPv4 network uplinked to a single MikroTik router with several low-speed Internet connections a few hops away.  As a result, it was horribly slow - I couldn't even break 1 Mbps.  Here's some CDP from the wire showing the repeaters:

00:23:02.907300 CDPv1, ttl: 120s, checksum: 376 (unverified), length 70
	Device-ID (0x01), length: 10 bytes: 'NANO1PCANA'
	Address (0x02), length: 13 bytes: IPv4 (1) 172.21.255.250
	Capability (0x04), length: 4 bytes: (0x00000002): Transparent Bridge
	Version String (0x05), length: 9 bytes: 
	  XM.v5.5.2
	Platform (0x06), length: 3 bytes: 'N2N'
	Port-ID (0x03), length: 3 bytes: 'br0'

The MikroTik router appeared to round-robin sessions through all of the Intenet connections, which resulted in my source IPv4 address changing constantly.  Since the Wi-Fi was not encrypted, I was connected via a VPN most of the time, which reconnected every 5-10 minutes.  I guess that is the cheap way of getting more bandwidth - I suspect the Internet connections were just low-speed DSL links instead of something more robust.

I managed to snag some bandwidth statistics from the MikroTik router through just following unauthenticated HTTP links:

MikroTik Graphs

The above is from the one "LAN" interface on the MikroTik box.  There wasn't too much traffic considering the resort is pretty large.  I guess the Internet connectivity was too slow that nobody bothered with it (or they were doing more vacation-ish things).

Anyway, I took a bunch of photos with my Nexus 4, Canon 60D, and GoPro HERO3.  The HERO3 actually performed admirally during the Snuba and speed boat appearance considering I had 720p@60 video running most of the time.  I was concerned the battery would die, but it didn't.  One thing that sucked, though - I switched the video mode to 1080p@24 to get some more detail and was sorely disappointed when I played it back.  For some reason the video exhibited very poor tearing like it was taken with 5-year old cellphone.  I recall that didn't happen at 1080p@60, though.  So, for some reason that low frame rate introduces some buffering problems on the HERO3.

Comments: 1
> Android Bugs
Posted by prox, from North Brunswick, on April 07, 2013 at 14:52 local (server) time

If you follow me on Google+, you'll know that I'm a big Android fan but am starting to get annoyed with the constant OS bugs that plague platforms running vanilla Android (eg, Google's Nexus line of devices).

One of my recent posts had me wondering if I should ditch Android and switch to the iPhone.  Ultimately, I'd lose too much (IPv6 on T-Mobile, certain apps, etc.), so I'm probably not going this route.

Anyway, here's a list of some recent bugs that continue to plague vanilla Android (more or less - I'm using the M2 build of CyanogenMod 10.1) running on my Nexus 4 along with the fixes or workarounds that I've found.

The Camera Stops Working

This is documented in issue 40996 and happens maybe once a week to me.  All applications that use the camera freeze and require a kill.

I haven't really confirmed this yet, but the supposed fix is to switch to video mode and then switch back.

Mobile Data Stops Working

This only happens to me once a month so I haven't really been able to research it too much.  Even though mobile data is enabled, a GNU/Linux interface (rmnet0, p2p1, etc.) is not created in the OS so applications cannot access the Internet.  If the PDP context is just IPv4 or just IPv6, the behavior is a little bit different; the data connection connects for 3-4 seconds and then disconnects.  It does this every 20-30 seconds or so.  Most of the time bad network conditions (no service, very poor signal, etc.) trigger this condition.

The fix that I've found is to enter the testing screen (*#*#4636#*#*), go to Phone information, and select the "Select radio band" in the menu.  The application crashes but then mobile data starts working again.  It's weird.

Bluetooth Stops Working

Sometimes after switching Bluetooth on or off or enabling or disabling airplane mode, the Bluetooth subsystem stops working.  I took a video of this behavior:

This is documented in issue 42255.  This one is frustrating because Google fixed this in 4.2.1 but it came back in 4.2.2.

The only workaround I know of is to never disable Bluetooth and never use airplane mode (turn off the wireless radio in the Phone information screen after using *#*#4636#*#*).

Comments: 1
> Snow!
Posted by prox, from Charlotte, on February 17, 2013 at 14:17 local (server) time

After almost two years of not seeing any snow here in Charlotte, we finally got a good snowfall last night.  I took a few photos at night and the next day.  Strangely enough, even though it snowed for a few hours, the majority of the accumulation happened over a three minute period.  I have a few time lapses of driving home and at my condo that I might put up on YouTube, later today.

Snow in Charlotte!

Snow in Charlotte!

Snow in Charlotte!

Snow in Charlotte!

In other non-news, people really don't know how to drive in the snow, down here.  Shocker, I know!

Comments: 2

Previous PageDisplaying page 2 of 116 of 923 results Next Page