Setting up Optimus on an ASUS NV56VJ with Linux

• This laptop has an NVIDIA GeForce GT 635M card installed alongside the built-in Intel graphics controller.  This configuration is referred to by NVIDIA as an Optimus configuration

[root@localhost ~]# lspci |grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 635M] (rev a1)

• We can see here that the Intel controller is installed at PCI:0:2:0 and the NVIDIA controller at PCI:1:0:0.
• Following the ArchWiki instructions, I came up with the following /etc/X11/xorg.conf file (which includes a later update to fix a font rendering issue (i.e. the DPI setting)):

  Section "ServerLayout"
      Identifier "layout"
      Screen "nvidia" 0 0 
      Inactive "intel"
  EndSection
  
  Section "Device"
      Identifier "nvidia"
      Driver "nvidia"
      Option "DPI" "96 x 96"
      BusID "PCI:1:0:0"
  EndSection
  
  Section "Screen"
      Identifier "nvidia"
      Device "nvidia"
      Option "AllowEmptyInitialConfiguration"
  EndSection
   
  Section "Device"
      Identifier "intel"
      Driver "modesetting"
      BusID "PCI:0:2:0"
  EndSection
   
  Section "Screen"
      Identifier "intel"
      Device "intel"
  EndSection
  

• And since I am using KDE, I followed the additional instructions to append the following lines to the end of my /etc/kde/kdm/Xsetup file (which is hard linked to /usr/share/config/kdm/Xsetup):

  xrandr --setprovideroutputsource modesetting NVIDIA-0
  xrandr --auto
  

• If you're using Gnome instead of KDE, you would add those lines to the bottom of the /etc/gdm/Init/Default file, just before the "exit 0" line (at least on Fedora that's how it is).
• If this is a brand new install of Fedora, the packages you'd want to install are at least:

  kernel-devel akmod-nvidia vdpauinfo.
  

Some strangeness that I noticed with the new configuration (on Fedora 19 w/KDE, but not on Fedora 21 w/Gnome):

• The font rendering is smaller (or the fonts are just different) than my previous Intel setup
• The KDM login screen is now tiled instead of stretched and centered.

Other than that strangeness, everything seems fine. The glxinfo and vdpauinfo commands return what you want to see:

    [martin@localhost ~]$ glxinfo |head -5
    name of display: :0
    display: :0  screen: 0
    direct rendering: Yes
    server glx vendor string: NVIDIA Corporation
    server glx version string: 1.4

    [martin@localhost ~]$ vdpauinfo |head -3
    display: :0   screen: 0
    API version: 1
    Information string: NVIDIA VDPAU Driver Shared Library  340.29  Thu Jul 31 19:59:48 PDT 2014

For reference, here are the NVIDIA packages I have installed:

    [martin@localhost ~]$ rpm -qa|grep -i nvidia|sort
    akmod-nvidia-340.29-2.fc20.x86_64
    kmod-nvidia-3.14.27-100.fc19.x86_64-340.29-2.fc19.x86_64
    xorg-x11-drv-nvidia-340.29-2.fc20.x86_64
    xorg-x11-drv-nvidia-cuda-340.29-2.fc20.i686
    xorg-x11-drv-nvidia-cuda-340.29-2.fc20.x86_64
    xorg-x11-drv-nvidia-devel-340.29-2.fc20.i686
    xorg-x11-drv-nvidia-devel-340.29-2.fc20.x86_64
    xorg-x11-drv-nvidia-libs-340.29-2.fc20.i686
    xorg-x11-drv-nvidia-libs-340.29-2.fc20.x86_64

And here are all the xorg-x11-drv packages I have installed:

    [martin@localhost ~]$ rpm -qa|grep -i xorg-x11-drv |sort
    xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19.x86_64
    xorg-x11-drv-evdev-2.8.1-2.fc19.x86_64
    xorg-x11-drv-fbdev-0.4.3-9.fc19.x86_64
    xorg-x11-drv-intel-2.21.12-2.fc19.x86_64
    xorg-x11-drv-mga-1.6.2-7.fc19.x86_64
    xorg-x11-drv-modesetting-0.8.0-3.fc19.x86_64
    xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64
    xorg-x11-drv-nvidia-340.29-2.fc20.x86_64
    xorg-x11-drv-nvidia-cuda-340.29-2.fc20.i686
    xorg-x11-drv-nvidia-cuda-340.29-2.fc20.x86_64
    xorg-x11-drv-nvidia-devel-340.29-2.fc20.i686
    xorg-x11-drv-nvidia-devel-340.29-2.fc20.x86_64
    xorg-x11-drv-nvidia-libs-340.29-2.fc20.i686
    xorg-x11-drv-nvidia-libs-340.29-2.fc20.x86_64
    xorg-x11-drv-openchrome-0.3.3-1.fc19.x86_64
    xorg-x11-drv-qxl-0.1.1-3.fc19.x86_64
    xorg-x11-drv-synaptics-1.7.1-6.fc19.x86_64
    xorg-x11-drv-vesa-2.3.2-9.fc19.x86_64
    xorg-x11-drv-vmmouse-13.0.0-5.fc19.x86_64
    xorg-x11-drv-vmware-13.0.1-1.fc19.x86_64
    xorg-x11-drv-wacom-0.23.0-5.fc19.x86_64

CORS

Here is my current thinking of how CORS basically works, which is enough for me to use it.

The CORS configuration is essentially a non-binding agreement between the client and the server.  It is up to the client to enforce the rules (CORS), and if the client wants to enforce those rules then it is up to the server to behave properly by providing a valid Access-Control-Allow-Origin header in responses which lists which origins that resource is intended for.

• The domain name under which the JavaScript in the browser is executing is one origin.
• The domain name under which the server is hosting the web service (with which that JS is interfacing) may be a different origin, or the JS may be hitting web services on multiple sites, and therefore multiple origins.
• It is up to each web service to specify which origins they expect to be fielding requests from.

The server may be as lazy as possible by providing a wildcard Access-Control-Allow-Origin header:

Access-Control-Allow-Origin: *

Or it may be proper and provide the Access-Control-Allow-Origin head ONLY if the client presents an origin from the list configured on the server.

So, the way it works in practice is:

1. The client calls the web service route with the OPTIONS method (rather than one of the more typical REST verbs: GET, PUT, POST, DELETE) and with the Origin header specifying the origin.  It might look like this:
   
   

           OPTIONS /hello HTTP/1.1
           User-Agent: curl/7.29.0
           Host: origin1.foo.com:10215
           Accept: */*
           Origin: http://origin2.foo.com
   

   
   As we can see here, the domain name presented in the Origin header (the name the client is running the JS code under) is different than the name in the Host header (where the JS has been instructed to make the web service call to).
   
   For reference, this request would be made using the curl command (for testing) like so:
   
   

           curl -vv -H "Origin: http://origin2.foo.com" -X OPTIONS http://origin1.foo.com:10215/hello
   

   
   
2. If the server is configured for CORS and "http://origin2.foo.com" is in the list of configured origins for the /hello route, then the response from the server would be like this:
   
   

           HTTP/1.1 200 OK
           Server: nginx/1.6.2
           Date: Thu, 25 Dec 2014 23:00:49 GMT
           Content-Type: text/html; charset=utf-8
           Content-Length: 0
           Connection: keep-alive
           Allow: HEAD, GET, POST, OPTIONS
           Access-Control-Allow-Origin: http://origin2.foo.com
           Vary: Origin
   

   
   
3. If the server is not configured for CORS, or if "http://origin2.foo.com" is not in the list of configured origins for the /hello route, the response from the server would be:
   
   

           HTTP/1.1 200 OK
           Server: nginx/1.6.2
           Date: Thu, 25 Dec 2014 23:23:03 GMT
           Content-Type: text/html; charset=utf-8
           Content-Length: 0
           Connection: keep-alive
           Allow: HEAD, GET, POST, OPTIONS
   

   
   Note here the lack of an Access-Control-Allow-Origin header, which indicates that the server is either not configured for CORS or the client provided an Origin value which was not in the list of configured origins for the /hello web service.
   
   
4. If the server is configured for CORS, but is being as lazy as possible, the response from the server would be:
   
   

           HTTP/1.1 200 OK
           Server: nginx/1.6.2
           Date: Thu, 25 Dec 2014 23:23:03 GMT
           Content-Type: text/html; charset=utf-8
           Content-Length: 0
           Connection: keep-alive
           Allow: HEAD, GET, POST, OPTIONS
           Access-Control-Allow-Origin: *
   

   
   Note here the presence of the wildcard Access-Control-Allow-Origin header.

The old android with whom I am in love.

The decent man who washed my dishes for me and whom I call Friend.
The turbulent road by which I plant my wishes.
The open stream that flows beneath my casket.
The proud holler of a drunken mule sated on soft fallen fruit.
The purloined heart of a passing boy unable to keep his gaze.
The balmy girls alight on the yard's broad plain.
The delicate peal of a distant storm savaging our seedling crops.
The honest croak of a wooden door unopened since the first frost.
The soft brown of your thigh under my hand at the light.

The stoic brine of focus besieged.
The filthy spike with which   I sow these pots in memoriam.
The candid smile that turned my spirit and broke the spell.

The sloppy walk in wet socks across an empty summer deck.

Getting along with the old eMusic Download Manager for Linux

I've been a loyal eMusic customer for about five years, and I've been a non-proprietary OS man in my home for a lot longer than that, so I've dealt with the pain you're feeling, and I'm going to help you through it.

So you just upgraded to the latest Fedora/Debian/Ubuntu/whatever, and you can't get the old eMusic DLM working anymore?  Yeah, that happened to me too, but I fixed it.

If you just upgraded to Fedora 19, my help will be completely trouble-free for you.  Otherwise, you may need to adapt these instructions and possibly the package itself to your OS's needs.  If your OS doesn't use RPM, you should be able to do this with just the tarball that eMusic is still providing, or if they've stopped providing even that, you can install some RPM tools on your system and extract the archive from this RPM I'm providing.

Step 1) Install Firefox and the rpm-build package.  We're going to build an RPM in order to exploit its automatic dependency determination, and subsequently YUM's automatic dependency installation.  And Firefox because the old eMusic DLM only works w/Firefox, afaik.

        # yum install firefox rpm-build

The old DLM only works with Firefox, as far as I know.  I haven't been able to get it to work otherwise.

Step 2) Download the old eMusic Download Manager" in tarball format.  We're going to make an RPM.

        # wget http://www.emusic.com/apps/dlm/emusic_linux_current.tar.gz

Step 3) Create rpmbuild/SPECS and rpmbuild/SOURCES directories in your home directory

        # mkdir -p rpmbuild/{SPECS,SOURCES}

Step 4) Move the emusic_linux_current.tar.gz file into the new SOURCES directory.

        # mv emusic_linux_current.tar.gz rpmbuild/SOURCES

Step 5) Create a file called emusic-dlm.spec in the rpmbuild/SPECS directory with the following content:

%define userid          root
%define groupid         root
%define version         4.1.4
%define rel             4
%define debug_package   %{nil}
%define prefix          /opt/emusic/%{version}

# This should be set to the first two directories from the
# emusic_linux_current.tar.gz tarball, but without the leading slash.
%define archivelead     builds/emusicdlm 

Summary: eMusic Download Manager
Name: emusic-dlm
Version: %{version}
Release: %{rel}
License: Proprietary
Packager: It was All Me!
Group: Commercial
Source: emusic_linux_current.tar.gz
BuildArch: i686
BuildRoot: %{_tmppath}/%{name}-buildroot
AutoReqProv: yes

%description
The download manager for eMusic.  Set your firefox preferences to use
/opt/emusic/4.1.4/emusicdlm as the handler for emusic download files.

%prep

%setup -q -n %{archivelead}

%build

%install
rm -rf ${RPM_BUILD_ROOT}
mkdir -p ${RPM_BUILD_ROOT}/%{prefix}
cd ${RPM_BUILD_DIR}/%{archivelead}
find . | cpio -dumpv ${RPM_BUILD_ROOT}/%{prefix}

%clean
rm -rf ${RPM_BUILD_ROOT}

%files
%defattr(-, %{userid}, %{groupid}, -)
%{prefix}


%post

%postun

%changelog

You should now have the following files below your home directory:

rpmbuild/SPECS/emusic-dlm.spec
rpmbuild/SOURCES/emusic_linux_current.tar.gz

Step 6) Create the RPM using the rpmbuild command:

        # setarch i686 rpmbuild -ba rpmbuild/SPECS/emusic-dlm.spec

You should now have an RPM in the rpmbuild/RPMS/i686 directory called emusic-dlm-4.1.4-4.i686.rpm.

Step 7) Install the RPM and its dependencies using YUM

# yum localinstall rpmbuild/RPMS/i686/emusic-dlm-4.1.4-4.i686.rpm

Step 8) Configure Firefox to use /opt/emusic/4.1.4/emusicdlm for .emx files by opening Firefox and going to this URL, which will plant a cookie in the browser indicating that the DLM has been installed.

Step 9) Click on a download link for a song or album.  When presented with the "0.emx" file, choose "Open with", and browse to /opt/emusic/4.1.4/emusicdlm.  Also be sure to click on "Always do this".

A Homemade Relaxing Tea

I was at a SLOUP event tonight where one of the sponsors had donated some really delicious herbal tea (the sponsor was actually ReTrailer), and as I was sitting here tonight doing homework and wanting to drink some more tea, but also not wanting any more caffeine for the night, so I decided to take my own shot at making tea.  It seems to be a pretty awesome success!

Step 1: Heat up some water
Step 2: Pour the hot water into your mug and add:

• 1 cinnamon stick
• 1/2 tsp of lavender
• 1/4 tsp of ground cardamom

Step 3: Let steep for a minute or two

Step 4: Retrieve the cinnamon and lavender (using a spoon) from the mug

Step 5: Enjoy!

Understanding the self

Journal entry from 2/21/12

Like Dean Young says about Keats's Ode to a Nightengale:

"The self is not a fixed thing, rather a movement:  A collection of arrived-at and abandoned impulses and conflicting conclusions, one X over another." (The Art of Recklessness, pg 54)

But as much as our self wanders throughout the day, we, like Keats being dragged back to his forlorn self, always return to that place where we lay our head on the pillow.  Our routines bind us to an identity and give us an illusion of control in a constantly changing world.

Part of our fear of algorithms finding our patterns is that we cannot, or don't want to, break out of them.  Besides, if we do break out, how long before we fall back in?  Do we converge on an invariant identity, categorizable, well-defined, predictable?  Is it even possible to ever break out?  Breakouts become patterns of their own, part of the overall texture of a pattern.

But behold!  We break free, forth into the darkness or the light, ever-changing world where we try new things, jumping off the dock into green water, skiing through the trees, propelling ourselves into space, falling in love, adapting to change, creating new ideas, new things, new ways of being.  In the big picture, we are unpredictable, and in the microcosm of a moment we are as well.  It is only in the quotidien cycle of waking and sleeping, following our routines, that we are most predictable.

So then the most unpredictable we could be would be to change daily or weekly or cyclic habits.  But who would want to?  It is the cycle that gives us a sense of stability.  The predictability is good, reliable.

Christine Miller

"Death is not a fearful thing, it's living that's treacherous."

That is a quote by Jim Jones that I pulled from the second track of the amazing debut album from Cults, who pulled it from the notorious and profoundly sad Jonestown Death Tape.  I hadn't really thought much about the Jonestown disaster since I was little, when I remember seeing the pictures of the bloated bodies and the purple Flavor Aid in a book about photojournalism.  (Actually, come to think of it, that book introduced me to several major atrocities.)

After discovering the SDSU Jonestown website, "Alternative Considerations of Jonestown and Peoples Temple," I came across this incredibly sad and fascinating story of Christine Miller.  She alone stood in dissent of Jim Jones's horrific scheme, but she was ultimately suppressed by the crowd and possibly murdered by lethal injection.

Read.  Listen.