unix

Odd reflection before bed

by

For the most part, the high point that Windows NT has achieved for me is “Not pissing me off by default” and becoming a fairly decent shell upon which to use the Linux things that I care about without needing a second machine or dual boot, thanks to WSL. The era of Windows 10 also brought iterative improvements to system components I care about like the command line environment. But versus native Linux, the main win for me is better access to DirectX games and Microsoft’s office apps.

But truth is, there are certain parts of Windows that are likely to always piss me off. Namely Bluetooth support, and to a somewhat lesser extent anything related to USB or networking will inevitably drive me nuts given enough time around NT.

Thinking about this as I finish up a few things before bed, I realize I typically like using MacOS. The aspects that piss me off tend to revolve around muscle memory, like how some common PC shortcuts are cmd+key and others are ctrl+key. Which are shell level uniquenesses not systemic design. On that note, I’ll add that I tend to find iOS/iPadOS rather more meh, or average than pleasant.

By contrast things that irk me so about using modern Linux as a desktop are the quality of mail clients, lol.

by

On one hand, I never paid much mind to the differences between PC and Mac modifier keys. And for the most part, if you just s/control/super/g most things will feel at home.

On the other hand, I’m pretty sure that the remapping of my various keyboards ctrl/super/alt based on how Macs do things, will confound and give me headaches when movements become like super+arrow = home ; alt+arrow = move by word; rather than fn+arrow = home; ctrl+arrow = move by word ; etc.

And then there is the fact that the key map in my head is basically an XFree86 key mapping….lol.

Because for the most part, I have lived in the land that Unix and CP/M wrought. Thus whenever I use quick editing shortcuts that are universal to GUI apps, as opposed to inspired by vi and emacs, I am very, very, very quick to execute actions like shift ctrl+left+left to select the previous two words.

If I am found laying on the floor, twitching, it’s probably Google’s fault. If I’m found laying on the floor spinning in circles, it’s probably because my Bluetooth keyboards are shared between a PC, and an iPad, and third things that are like PCs.

Fun with tmux & dtach

by

Generally the problem with running a terminal multiplexer like tmux or screen on a remote server: is if the server goes down so does your session. Like wise an issue will eventually crop up where in you have to SSH into another server or even the box you’re sitting in front of, if you don’t want a seperate xterm in order to do it; thus losing all that multiplexer goodness.

Well, I pretty much run the session (tmux btw) on my system, and then use dtach for running things I may want to detach from—like a big compile. One perk of this is I get to have my “notes” window in tmux without double the latency.

Today, I was thinking about how can I link this notes window to various tmux sessions? It is possible to link windows (linkw) in a session and entire sessions (new -t {other session}) but that is not what I want. dtach again to the rescue! My notes script already amounts to opening my “Scratch” note file in vim, and changing the window name to “notes” if used in tmux. So I modified it to be smart enough to run vim in dtach, or reattach. Thusly, I can have tmux sessions by project, home, etc, and share the same vim session between them using dtach.

Note tacular!

A case for autotools that I have only recently begun to understand

by
Like just about anyone who has ever had to install software from source has, I have /used/ autotools before. But like many barely ever scratched the surface. Lately I have been cuddling up with the autotools from a developer perspective, a lot more. To the point perhaps, that I am liking autotools better than I ever thought I would. Like anyone whose used more than 1% of autotools, I know you can (or are supposed to when the developer did it right) be able to run configure/make outside the source tree. Also I know about –prefix and most of the usual configure script goodness. Now, it’s far from the first time that I have mentioned it, but my “Holy Grail” of builds has long been a multi-tree build:  one tree for build files, one tree for distribution files, and trees for whatever source and data files are needed. Then because I may be doing a diverse set of platforms, this usually becomes a need to further grind down into having co-existing build/dist trees: for example to have FreeBSD, OpenBSD, Linux, and Windows NT builds in the same working copy. Including using different toolsets, such as GCC 3.x, 4.x; and MSVC 9.0, 10.0 on the Windows NT builds. Now that my main computer is an ARM, processor architecture will probably end up mandatory. I like stuff like Build/platform/toolset. Hacks to keep this sort of thing working under {insert random OS here} should be kept to a minimum. How well a build system supports helping me with this problem (and file system hier) is one way that I judge build systems. Over the years, I have tried…just about everything except ant and maven but hey, how many C/C++ projects do you see using those at home? Multi-lingual stuff is always idea. At present, my favourite build system is premake4 — it makes setting up such a build pretty painless. After that is probably Qt’s qmake, since it makes compiling fairly painless. With the GNU build system, it is pretty easy to do something like: 


    $ cd Build/Linux/ARMv7/gcc44
    $ ../../../../configure --prefix ../../../../Dist/Linux/ARMv7/gcc44
    $ make install

Which would give something well suited for testing, and there is a config file to save whatever configuration options I usualy test with in $prefix. The check and installcheck targets also do what I will typically do with a `make tests` or a `./tests.sh` in my own working copy. To top it off, autotools probably has one of the best tools for making a distribution: make distcheck. I do not need most of what autoconf can do, and usually prefer to skip it. The ability to have things fail at configure rather than compile time is handy. Being able to e.g. toggle between Deps/{pkg} and the systems {pkg} at configure time is great and something I already do with premake4. Automake can also pretty much do what you could get out of not having to hand write Makefiles. What REALLY shines however is libtool! We have all cursed at something or other involving autoconf, automake, or libtool. But the little secret is libtool is one of the best assets ever given to a developer. If you don’t think so, you should try to alcomplish the same thing in SCONS for a solid week, just to support three platforms with differing toolsets, unless much as changed in a few years: the amount of kludges is a recipee to be pissed off. libtool can pretty much do it all and for a lot of platforms. The real question is how well autotools would really play with doing a Windows NT build with Visual C++. I’ve never tried that. That is also the principal reason I’ve never used autotools on most of my projects lol.

by

Interesting findings. At work, my work station has always had problems using SMB/CIFS, in fact  it is almost useless but fortunately being Linux-oriented over here in Engineering, more traditional unix methods are favoured, so it is of little loss. Now the sad fact that most people use Windows, means that SMB/CIFS is easier to work with under Android than stuff like NFS or any of the multitude of similar techniques. As I rarely need to share stuff with multiple people, for my own stuff, I typically use SSHFS.

In fact, SSH is both such a part of my work flow between machines (here and espiecally at home), I wrote a handy script that lets me quickly mount my $HOME on a remote as ~/hosts/{hostname} locally. It’s useful. My workstation is setup both as a SSH client, server, and sshfs-mounter. But how to get stuff via Android, since I can’t just use CifsManager?

My ASUS Transformer obviously has support for FUSE, just looking at what `mount` says is enough to guess that. But there is no real support for SSHFS, all the goodies are missing. Since I have a very simple chroot of Debian stable, a quick `apt-get install sshfs` and bingo, all done :-). Since the stuff I’m interested in mounting at home (where SMB/CIFS works like a charm), I can just use SSHFS mounts and a shared socket. I.e. I can have things like my Dropbox mounted, get live sync, and even access locally!

Muahauhauauhuahuaaaa!!!!!!!!!!!!!!

This is a deplate of my Viki notes file on XRandR

by

1.1 Querying information

This was taken  with my ASUS 1015PE Netbook (Alice) hooked up to my LG
wide screen at home on 2011-07-23.

$ xrandr -q

Screen 0: minimum 320 x 200, current 2944 x 1080, maximum 4096 x 4096

LVDS1 connected 1024x600+1920+0 (normal left inverted right x axis y axis) 220mm x 129mm

   1024x600       60.0*+

   800x600        60.3     56.2 

   640x480        59.9 

VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm

   1920x1080      60.0*+

   1680x1050      60.0 

   1280x1024      75.0     60.0 

   1152x864       75.0 

   1024x768       75.1     60.0 

   800x600        75.0     60.3 

   640x480        75.0     60.0 

   720x400        70.1 

$

LVDS1 is Alice’s display. VGA1 is the monitor hooked up to the VGA
port on the side.

1.2 Positioning monitors

       

  • xrandr –output M1 –left-of M2 :: M1 is left of M2

    •    

  • xrandr –output M1 –right-of M2 :: M1 is right of M2
  • xrandr –output M1 –above M2 :: M1 is above M2
  • xrandr –output M1 –below M2 :: M1 is below M2
  • xrandr –output M1 –same-as M2 :: M1 and M2 mirror each other.

Where M1 and M2 are the short names given from xrandr -q. I assume that

    $ xrandr --output M1 --left-of M2 --output M2 --right-of M1

Is permitted, +/- using two xrandr commands for it, as well as being
redundant.

1.3 Setting monitor resolutions

    $ xrandr --output NAME --mode SIZExSIZE

Sets the monitor NAME to the given mode.

1.4 Turning monitors on and off

1.4.1 On

    $ xrandr --output WHICH --mode 1024x768

1.4.2 Off

    $ xrandr --output WHICH --off

VNC over SSH, the idiots guide.

by

Since I rather like to have options, I’ve decided to augment my usual SSH /w option of X forwarding to the option of VNC as well.

Objective: connect to my netbooks X session using VNC, tunnelled over SSH.

Implementation:

Since my netbook runs a GNOME centric distribution, I’m using the “Remote Desktop” preferences program on “System -> Preferences”. If you’re like me and to damn lazy to hunt and peck, this just runs the program ‘vino-preferences’. On here it’s possible to setup VNC access to your desktop. In essence, it just runs vino when you login. There are loads of good and bad write ups on VNC server setup and 3 or 4 click setup is good enough for me.

My iptables rules pretty much block such things as incoming VNC requests, which is good because I don’t want the session exposed across the network interface. Pretty much all there is for accessing my netbook is the SSH port.

Now on another system, it’s possible to connect using SSH forwarding. This gains us both encryption for the VNC session and less port exposure; that is good for security.

PuTTY client setup:

  1. Load/create your session in PuTTY
  2. Go to SSH -> Tunnels
  3. Add a port forwards
    1. source port: 5900
    2. destination: localhost:5900
  4. Login to the system using PuTTY.
OpenSSH client setup:
  1. ssh -L 5900:localhost:5900 username@host
There are options for both if disabling the shell session and only running the forwarding is preferred (PuTTY: SSH->Don’t start a command at all; OpenSSH -> RTFM for -n, -N, and -f). 5900 is the default VNC port running off the server end (my netbook).
Now on the client machine, connecting any VNC client (e.g. TightVNC) to localhost should give the desktop session over at user@host; in this case, my X session on alice!
This is the shortest, sweetest, non-non-sense, you’re assumed to know how to RTFM if you want to know the facts, kind of write up that I’ve seen on doing this. Hmm, maybe it helps that I already know how to use SSH port forwarding with OpenSSH, hehehe.
by

This blog entry by Michael W. Lucas, has got to be one of the most impressive ways I’ve ever heard, for integrating OpenBSD in a hurry.

by

Today, I really got a nice little reward. Basically, the company I work for was getting people together to go over the renewals with our medical insurance provider, and of course, eh, I’d rather be at  my work station getting something done. So this provided me with the impetus to setup my phone as  an impromptu in-building terminal.

Problemo is, I usually use VIM. While I’m stubborn enough to give that a go on a small screen with a virtual keyboard, my phones virtual keyboard doesn’t provide the *PC* keys: namely escape, control, and alt. It’s also not the most convenient to use the programs methods of side stepping this. So I got to thinking for a moment, what is an editor that is light and small enough to use over a text terminal, yet powerful enough to service a programmer without a lot of special keys? –> I found the solution right in my own skills repertoire, or as some say: the default text editor! Some years back, I took the trouble to learn how to use /bin/ed out of an interest in learning how to use vi/vim better.

After a couple minutes of thinking on this, it occurred to me: ed was designed in an era when terminals were SLOW, so slow in fact, that you could probably piss off someone by trying to print to much to standard output, which could be connected to a roll of paper and a true TTY >_>.

So it seems that learning /bin/ed was well worth it, because it makes one hell of a file text editor when using your phone as a terminal 🙂

by

I’ve been experimenting with window managers lately: fluxbox, openbox, awesome, and musca. Fluxbox and openbox, are pretty much just generic window managers, at least in my eyes. That said, they are well worth using, for most peopel. Awesome and Musca are tiling window managers, and a lot more, eh, minimalist. While I used to collect window managers, among quite a few other odds and ends back when I had time for it: but I have never done the “Tiling thing” beyond a very brief test drive of dwm.

Awesome and Musca create an interesting experience: you create the windows, the window manager, manages them. It’s almost alien lol. Normally you create a window, the window manager figures out where to draw it. You do the rest, e.g. by resizing and moving it around as necessary. In these tiling window managers however, newly created windows are automatically arranged and sized by dividing containers.

Launching your first window is like maximising, lauching a second window causes everything to resize and give each program half the screen, and so on based on some tiling pattern. The most used seems to be 1 half sized window left and 2 quarter sized windows right; works better than you might think. Rather than resizing the windows individual, you resize the containers. So if the screen is laid out as:



|         | term |
| Firefox |------|
|         | chat |


>

Selecting either the term or chat window and attempting to resize will resize all three windows. Try to enlarge the chat window horizontally, and Firefox will shrink and term grow, horizontally. Try to shrink the term window vertically and the chat window grows vertically, and so on.

It’s mind blowingly better than what the style of window management people are used to these days, which dates back to like Mac OS 2 or Mac OS 3 back in the ’80s. It is also a little bit awkward to let the computer take care of something, that you’ve been doing by hand for almost twenty years!

Relishing the experience however, has made me think of something different. I was just experimenting with the MinOverlapPlacementPenalties and MinOverlapPercentPlacementPenalties settings in FVWM, and it hit me. What if you could dynamically define what windows are important? I.e. what screen space should have more “Don’t cover this up unless necessary”, and how big a frame (i.e. for auto-tiling) should be, and so on?

It is technically possible, if perhaps computationally ‘interesting’ to figure out at the machine level. The windows that spend the most time focused or are most often gaining the focus, would be prime candidates. If the user ‘uses’ the window more than others, give it a larger chunk of available space scaled to its idea of how much space it needs, then prefer minimising the percentage of those windows being covered over or shrunken to absorb other windows in the same screen space.

It is food for thought!