Node.js breadcrumbs

Node.js is not properly installed until it's reliable in command line at the user level. Portions of node.js installed from Arch repositories are, of course, global to command line. The rest of the installation is mostly local to one project or another, as various modules become necessary.

global

For Arch, one can use pacman:

# pacman -S nodejs npm

These will work in any directory.

project

Suppose a user establishes a folder for their node.js project, and is working from that project directory. During their project, they recall that they need to install this or that module, say, express. The user roots up, runs # npm install express, then descends to user and continues working on their script, or some other operation which calls express. Eventually, to verify the express module's working, the user types "express" at the command line. Here's what would happen.

$ express
bash: express: command not found

Unlike pacman, npm is a node.js specific installer with its own directory structure. Node.js is roughly analogous to an independent LaTeX install: you can use $ tlmgr to update or control things, but not until the LaTeX directories are added to PATH. Likewise npm works from the command line, except that one must root-up when using it as an installer (# npm install [some package]). This is because the Arch version of npm places the modules into a root privilege directory /usr/lib/node_modules. This will hinder us throughout anything we do. We can place /usr/lib/node_modules/ in our PATH, which will allow execution, but we can never add or modify files in it. For this reason, I strongly believe that, like LaTeX, node.js should be installed in the HOME directory at user level, never requiring root privileges. If you install node.js with pacman, you'd have to pacman or yaourt every single module installed by node.js, or create PATH additions for each and every one that npm installs. No way, jose.

# pacman -Rs npm nodejs
$ rm -r .npm

nvm

For me, the easiest way to install a user-level node.js application was to use NVM volume manager to import node.js. NVM is upstream from node.js installations, so it can download and install any node.js version, allowing multiple releases to exist simultaneously on a system within the home director: users may select the version they wish to use directly from the user level.

The NVM script at the blog above downloads the latest git version of NVM, or just go directly to the install script here. I opened it with a word editor and reviewed it, then ran the script to download NVM.

$ sh ./install.sh

In addition to installing NVM at the user level, the install script appends to ~/.bashrc so the PATH is updated. I verified the changes, found them acceptable, and then sourced the .bashrc to activate the PATH change. Next, I verified nvm was detected and ran.

$ source .bashrc
$ nvm

npm

The next concept in user-space node.js is managing packages. Since node volumes can be placed using NVM, the packages for any version of node will be with a pacakage manager, NPM. it's good to use

no gvfs

The gvfs is a kludge and system hog. Its only value is a trashbin. I don't need or like a trash bin, I use udiskie2 for mounting USB sticks, I don't need thunar, and I don't need bookmarks in evince. Note: I also try to disable PAM and polkit, whenever possible. I've found that PAM has some hooks that require it to be installed, though I am able to turn it off in htop fairly often.

evince & gvfs

In 2021, an evince install requires gvfs (and fuse), even though gvfs is only for bookmarks. So I now use Okular, which has a 300MB KDE/QT Photon library installed with it. Outside of the HDD space, it's no problem because these libraries do not run except when Okular is running; the KDE dependencies are not a file system, and are not persistent. That said, Okular is not as tight an interface as Evince. If one disables the sidebar, it's pretty close. Prints fine.

undoing gvfs

To view gvfs dependent applications running...

$ psaux |grep gvfs

Amazing number of things, right. Uninstall gvfs, and any others on the list, but also manually rid yourself of its stuff in your home directory, such as its cpu-hogging kludge of metadata. However, a person can't just eliminate gvfs, because nautilus will complain.That's apparnetly because nautilus depends on gvfs-disk-utility and gvfs-disk-utility depends on gvfs. One order of operations could be:

# pacman -Rsn nautilus thunar evince
# pacman -Rsn gvfs gvfs-mtp
$ pkill gvfsd-metadata
$ rm -rf ~/.local/share/gvfsd-metadata

Reboot to check that things is a-workin'. Should be no trash can in Thunar. It will still remain so just delete the entire trash directory.

# rm -r .local/share/Trash .local/share/gvfs-metadata

Secondly, when gvfs installs, it routinely installs additional feature apps. Many of these, eg PAM, also cause permission conflicts. PAM is particularly hard to get off of one's system once it's been harkened. The real question then becomes not the alternative to gvfs, but what to do about gvfs and its friends once some application has inevitably and unfortunately installed and/or activated gvfs and company.

It's a little difficult to move everything from .bashrc to .xinitrc, as some of the command options of bashrc are listed in there by default, and where else can I see those commands? I've added a section below for its default configs.

1. get rid of .bashrc. Put all its regular commands for the terminal cursors and paths into .xinitrc
2. thanks to this page:

   nano .xinitrc
   GVFS_DISABLE_FUSE=1
   export GVFS_DISABLE_FUSE
   

more thorough

The above is enough for most, but on older machines, it won't be. Both gvfs and polkit are immense permission kludges. And you can do without polkit in favor of simply using sudo when needed. Polkit works through, I believe, the wheel group to address userspace priviliges. The Arch page on it. Invariably it's one of the top users of memory if you run htop.

default .bashrc

You'll need to move all of these into .xinitrc if you delete bashrc.

# ~/.bashrc
# file works on colors and alias commands
# do exports and paths in .xinitrc

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --group-directories-first --color'
alias ll='ls -l'

#PS1='[\u@\h \W]\$ '

# for Video (VDPAU)
#export VDPAU_DRIVER=r600

# for some games like solitaire where locale is important
# export LC_ALL="C"

# for TexLive
#export PATH=/home/foo/latex/bin/x86_64-linux:$PATH
#export INFOPATH=/home/foo/latex/texmf-dist/doc/info:$INFOPATH
#export MANPATH=/home/foo/latex/texmf-dist/doc/man:$MANPATH
export NVM_DIR="/home/foo/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm


[solved] vlc playback odds and ends

Links:

---

audio playback gaps

Several forums describe buffering issues with VLC audio. For me, it was during playback of files on my HDD. For example, in the previous post, I described using VLC with .m3u files to play with WAV ordering prior to burning a CD (assuming anyone still uses CD's). Playing M3U's which contain nothing but WAV's through VLC would trigger the audio gaps.

The symptom is a one second gap in playback, a simultaneous spike in CPU use, and generation of a two-line error. Subbing in some variables for actual numbers:

[0000x7f5d030f7df8] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 2232 ms)
[0000x7f5d030f7df8] core input error: ES_OUT_RESET_PCR called

Apparently a Program Clock Reference is called too late and, in response, VLC increases the delay for the Presentation Time Stamp delay. PCR and PTR are supposed to be related to MPEG playback, but this error appears in audio-only playback of WAV's, for example.

Most of the solution for me was found here, except for 1) which value to change, 2) increase or decrease and, 3) how much.

Since each setting has a pop-up, I read them. It appeared the item to change was "File Caching". On a guess, I adjusted the delay to near the pts_delay value noted in the error message above. Once set at 2000ms, I did not experience cut-outs during file playback.

the orange cone

Some don't like the cone at all; I dislike it during audio-only playback. It sits conspicuously where album art would go. I noted how to get rid of it in a previous post, but it bears repetition. During playback, to disable the orange cone when there is no album art: Tools, Preferences, Select All (Bottom), Interface, Main interface, Qt, unselect "Display background cone or art".

[solved] distributed install (Tex Live info also)

Typically, the details I need to operate within Linux are difficult to find on the Net, yet what I don't need seems written again and again nearly everywhere on the Net. I often must acknowledge to myself later that, what I couldn't find at the time was too simple for anyone to even bother typing.

Recent example. For years, I've wanted to backup my data directory quickly, so I could have a cron backup script to automate it. "Quickly" to me also meant "dd" (data destroyer, lol) instead of "rsync" or "cp". In turn, "dd" meant "unmounted" --- I don't want "live acquisition" for a directory as important as "/home". But I could not grasp how a separate, unmountable, partition for "/home" would work exactly.

The allocations for each partition seemed easy: I used...

$ du -ch

... to determine usage, and formulated a plan for splitting-up the drive: 10G swap, 30G install, the rest to /home. But I couldn't figure out how to do it. How would applications find the partition containing the data files? Dual booters run into that problem, for example.

fstab - the key

One day, I was struggling with the problem and I finally recalled a Linux basic: everything is a network, everything is a file. For example, how does a worker in Building A access his home directory on a server in Building B? Of course! fstab would simply mount it. Fstab was the solution and it was so simple it's little wonder no one had bothered to explain this in their distributed install instructions.

new Arch install

Solution in hand, the new install had 3 pieces: "/home", "/", and "swap" (some add a separate boot partition also). Using cfdisk, I sized each partition as noted above. Then...

# mkswap /dev/sda3
# swapon /dev/sda3
# mount -rw -t ext3 /dev/sda1 /mnt
# mkdir /mnt/home
# mount -rw -t ext3 /dev/sda2 /mnt/home
# genfstab -p /mnt >> /mnt/etc/fstab

...and all was good. The rest of the install was normal. Knowing the mounting commands and their order were the key. The root directory had to be mounted first, then other directories, such as /home.

I also put the TexLive distro (4.5G) into /home, since it's so large. I don't use the Arch repo version, since the full install is more complete. To install, create a directory called, eg., "/home/foo/latex" and, using command "D" during the install, supply the directory information. TL will create the necessary environment within your userspace, no root required. You will just have to update your PATH variables subsequently (see below).

$ cd /home/foo/latex/install-tl-20150525/
$ ./install-tl
command: D
/home/foo/latex/2015

After install, TexLive provides a reminder about paths.

Add /home/foo/latex/texlive/2015/texmf-dist/doc/info to INFOPATH.
Add /home/foo/latex/texlive/2015/texmf-dist/doc/man to MANPATH
(if not dynamically found).

Most importantly, add /home/foo/latex/texlive/2015/bin/x86_64-linux
to your PATH for current and future sessions.

Welcome to TeX Live!

You can test the PATH by attempting to compile,say,a small test TEX file with $ pdflatex test.tex". If the command isn't found, then bash needs the PATHs. You could 1) make a small executable to add paths in /etc/profile.d./ or, 2) add:

$ nano .bashrc
export PATH=/home/foo/latex/texlive/2015/bin/x86_64-linux:$PATH
export INFOPATH=/home/foo/latex/texlive/2013/texmf-dist/doc/info:$INFOPATH
export MANPATH=/home/foo/latex/texlive/2015/texmf-dist/doc/man:$MANPATH

Exit the X session and logout of the user (eg, "foo"), then log back in. The bash paths should be updated and TexLive normally available from non-X terminal, xterm, geany, etc.

backups

Simple now.The format of "dd":

dd if=[source] of=[target] bs=[byte size]

Essentially, "dd" goes from a device to a file. The easiest large file is probably an ISO. One other thing, "dd" copies the entire device, including the empty areas -- it's a copy -- so the target device has to be as large as the source, unless one compresses.
Steps: assume here that home directory /dev/sda2 is to be backed up to a usb drive, /dev/sdb1.

• boot-up into CLI
• determine the block/byte size of /dev/sda2 (typically 4k these days), by writing an extremely small file, far below the size of a full block (for example a file only containing the number "1"), and then checking its disk usage (du):

  $ echo 1 > test
  $ du -h test
    4.0 Kb   test
  

• Verify the file system format, eg Reiser, ext3, etc. You can use "lsblk -fs /dev/sda2" or "file -sL /dev/sd*".
• # umount /dev/sda2 (no writing to the partition; we want a clean backup)
• attach the usb drive (/dev/sdb)
• dd if=[source] of=[target] bs=[byte size]
• # dd if=/dev/sda2 of=/dev/sdb1/20150210.iso bs=4k conv=sync,noerror
• profit.

Profit unless you inverted your source and target drive names ("i" and "o" are next to each other on the keyboard) -- in which case dd wrote from the back-up drive to your HDD, destroying your HDD data.

[solved] ti-89 OS update, tilp

Links: manpage (ubuntu site) :: connect to system :: OS update (v3.1) :: ti planet (hella fun)

---

OK, I have a list of implicit derivatives --- better check them before I submit them. Whip out the handy TI-89 Titanium and...WTF?! No impDer function. Great. Check the OS. Oh noes, version 3.0. Gonna be a long night.

download fun

Nothing came up in pacman. Nada. Accordingly, prepared myself to waste hours and hours and hours installing TiLP and pray I can update the OS once inside the calculator.

Download and unzip the libraries and get to work compiling all three of them. What could possibly go wrong compiling and installing 3 libraries? Hahahahaha. Hey, let's try yaourt.

compile, install libs

$ yaourt -Ss tilp

Bingo.

yaourt install

Using the yaourt install was still kind of a drag because of the compilation of the libraries. A lot of messages showed up suggesting edits to the install, but I figured any alterations I made could create subsequent errors I wouldn't have notes for, so I just let it compile.

tilp

Probably because I didn't make the alterations, I got some error messages, but everything seemed to work OK in spite of this. Except the OS update. For that, I shut down tilp, checked the calculator again to be sure it was "on", and started tilp in root. At that point, I just dragged the new OS from the computer directory over to the calculator directory and let off the mouse. The software update program began to run and even showed a % progress reading. Once it was done, turned off tilp, disconnected and restarted calculator. Voila, software version was 3.1 and impDer available.

forcing lib location during configure

So many times I can't count, I'll compile and install an application and then the application, which compiles without errors, won't be able to locate its libraries. I know the dependencies are there, but why can't the package find its libraries when it installed them? Annoying as hell.

So I run strace <app>, find where the app is looking, run find to locate the libraries, and then create soft links. This solves the problem, but sux when I might have to create 10 or 20 softlinks.

I'd much rather avoid softlinks entirely and use "configure" options to force libs go where they will be found, but there's an apparent Catch-22: I don't know in advance which directories the application will seek its libraries until after its installation. So, although I'd like to force "configure" to install libs to those directories, how do I know where the application will seek them until I install it and attempt to run it? Additionally, is the answer within make or configure?

solution

The answer, it would seem, is to force make to compile the app so that it both looks for its libs where I tell it to look, AND installs its libs into that location. Can it be done?

configure or make?

Theoretically, it should be possible to change the installation directories either through manipulation of make or through configure. In make it would presumably be through a configuration file make.config or some such; in configure, by forcing the prefix each time, eg.

$ configure prefix=/usr

The easier route appears to be to change it in configure. By default, make on my system appends /usr/local. This means, for example, that libs will install into /usr/local/lib. The easiest way to repair this is via configure "prefix" command as noted above. Using the command above, libs would be installed in the /usr/lib instead of /usr/local/lib. It also means however, that the bin file will install into /usr/bin instead of /usr/local/bin.

conclusion

Although there's very likely something like a make.config file to change its settings, I was unable to locate such a file with some cursory searching. The fast solution appears to be forcing the issue in configure using ,eg.

$ configure prefix=/usr