My pretty face [ László Monda's Blog ]
Exploring the cyberspace, one quadrant at a time!

How to rule remote shell sessions with tmux and mosh

January 26th, 2013

If you're like most ssh users when your connection breaks it's bad news for you. Not only you have to reconnect but your session gets destroyed and you have to make all the moves to restore the previous state. This doesn't have to be that way. I'd like to say some words about two tools that solve these problems in the most elegant way possible.

tmux

tmux is a terminal multiplexer: it enables a number of terminals to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached.

In the world of tmux there are windows and panes within windows. You can think of tmux windows as workspaces on the desktop that are aligned in a horizontal manner. It's like having a number of virtual monitors next to each other each running different shell sessions. You can move across these windows as desired. With the use of panes you can split individual windows horizontally and/or vertically as desired, each pane housing a different session. This is pretty useful for tailing various log files in different panes and monitoring them at once.

You simply have to run the tmux command to create a new tmux session. Once a session exists upon reconnecting over ssh you have to invoke tmux attach to reconnect to your already existing session.

If you're like me you may want to use tmux by default upon ssh'ing to servers. To make this happen you have to include export LC_TMUX_SESSION_NAME=yourusername into your ~/.bashrc and wrap scp on the client side and invoke tmux automatically on the server side. On a related note you can also take a look at my tmux.conf which I believe defines more intuitive shortcuts than the default configuration.

There are a number of alternatives to tmux that I'd like to list starting with the most powerful towards the least powerful. GNU Screen is yet another terminal multiplexer but its feature set, usability and configurability is rather limited compared to tmux. dtach is like a minimalistic tmux featuring one pane inside one window and it only provides a minimal set of options. Finally, with the use of the nohup command you can make your (typically long-running) script immune to hangups and hence it can survive ssh disconnects.

mosh

Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

mosh is the other piece of the puzzle leading to the remote shell nirvana. After apt-getting mosh on the client and mosh-server on the server instead of invoking ssh yourserver.com invoke mosh yourserver.com. From this point on you don't have to worry about reconnecting to ssh or having to wait for the server to echo back your characters anymore.

My bias lighting setup

January 2nd, 2013

It should be no news for any real geek that bias lighting is good for your eyes. I've just recently implemented my setup which was surprisingly easy to put together. It only needed a self adhesive LED strip, an AC adapter, a switch and some wires. Click on the album below for your viewing pleasure!

My bias lighting setupMy bias lighting setupJan 2, 2013Photos: 5

Caching static server-side resources the easy way

December 30th, 2012

Static resources are static because those never change thus always should be cached forever, right? Well, more often than not some of those files eventually change in which case the files in question must be renamed to be updated by the client which is a pain, especially if you use revision control (which you should).

Lately I came up with a new way to cache static server-side resources as efficiently and effortlessly as possible. Consider the following nginx configuration fragment:

From this point on you can reference a resource like http://yoursite.com/images/background.png as http://yoursite.com/static/1/images/background.png to be cached forever which you can change to http://yoursite.com/static/2/images/background.png in case the contents of this file gets updated. Instead of incremental numeric values you may want to use the hash of the current Git commit or any other identifier.

Wifi is not designed for seamless switchover

July 13th, 2012

A while ago I embarked on the quest of extending wifi coverage to our whole backyard.

Having a venerable ASUS WL-500GPv2 sitting at the front side of the house, my natural approach was to place another access point (AP) near the back side of the house which would cover our whole backyard. That is, in theory. As it turns out in reality things are a little bit more complex.

After installing the AP I was getting complaints from my sizeable user base (my sister and my mother) that the connectivity of their smartphones and tablets got shitty beyond imagination. After investigating this problem I realized that upon entering the house from the backyard wifi devices connected to the AP and as they moved towards the front of the house this connection stayed alive despite the router having a much stronger signal level at this point than the AP did. I even set up a multiple-AP (roaming) network configuration as suggested but the same thing was happening, only that I couldn't see right away which AP I was connected to.

Wifi switchover fail
Close
Wifi switchover fail18-Jul-2012 19:45, Canon Canon DIGITAL IXUS 100 IS, 3.2, 5.9mm, 0.05 sec, ISO 400

I was dumbfounded by what I saw. I assumed that wifi devices always (re)connect to the AP with the strongest signal level. Wouldn't this be the Right Thing to do, after all? Well, not so much.

The first problem is switchover lag. Wifi is not GSM. With GSM you can travel through the country, move across dozens of cell towers without noticing a thing. With wifi, switchover lag is noticable and is highly unwanted when using streaming applications, especially VoIP.

The second problem is deciding when to switch over. The hardcoded client policy is to switch over when the current AP becomes totally unreachable. Another policy could be switching over as soon as there's another AP in the vicinity with a slightly stronger signal level. This wouldn't be optimal either, however. Just imagine being located right between two APs and taking some steps back and forth and back and forth. That'd result in lots of unwanted switchovers. I guess manufacturers could put two wifi transceiver into each device to solve this issue but it probably wouldn't justify the price and this method would draw excess battery power.

Given that clients implement a hardcoded switchover policy let's see what could we do on the server side. A buddy of mine who worked as an admin at an ISP suggested using RouterBOARD appliances with which one can specify a dB treshold below which the appliance disconnects the relevant clients so those clients can switch over to another AP in the vicinity. Unfortunately, such uber feature is out of reach for most and I don't know about any other devices implemeting this feature, not even OpenWrt.

So what did I end up with? My buddy also suggested placing my router to the attic and ditching the AP. Now the overall coverage is better than it used to be. It's not perfect but the signal is almost always within reach on our property. As a rule of thumb one should place the wifi router to the highest and most central location. I'm pretty happy overall, althought a wireless-N MIMO router would probably boost signal levels like crazy but I'm in savings mode right now and I don't wanna spend a ton of money on an ASUS RT-N66U Dark Knight until it's totally justified.

My case for a portable desktop

March 20th, 2012

About two and half years before I invested in a heavily capable laptop, an Acer Aspire 8935G.  After having spent all this time using my laptop I finally reached the conclusion that I'll avoid laptops like plague in the future.  I understand that it's quite a harsh stance, especially given a laptop of this caliber but there are too many reasons against them from my perspective.

My first reason of not buying a laptop ever again: Neither suspend nor hibernate works on Linux

Just tell me a more essential feature that you expect from your laptop.  When I go to sleep I wanna suspend my laptop to have a silent environment and to be able to continue my work from where I left off.  When I leave home for some hours I'd also like to suspend my laptop just to save some power.  Hibernate could also work (in a suboptimal fashion) in such situations except that it doesn't.  Upon resuming my laptop it freezes in no time. Let's also take into consideration that I use a really complex session with lots of applications spread across multiple workspaces and lots of passwords to type upon startup. This shit costs me about a boring quarter an hour every time I wake up.  It may not seem much but I despise this ritual and I cannot forgive for such an essential feature not working.

So far I've surely spent more than 100 hours trying to make resume work with no success.  I've tried a number of distributions, fiddled with various parameters of s2ram, tried to suspend from console, switched the graphics card and did pretty much everything under the Sun. According to my understand the major problem is that the iGPU gets resumed instead of the eGPU and the BIOS provides no options to disable the iGPU.  In general this BIOS is dumbed down crap, providing only a handful of options at most.  I'm not in the mood of elaborating in detail about this but it's been a sickening experience which I couldn't solve despite having a strong Linux background and spending a *lots* of time on this issue.

The major problem the way I see it is that most laptop manufacturers (Acer surely included) don't give a shit about Linux support.  I can't really blame them considing the 1% market share of Linux but it's sure as hell that I won't give them a fucking cent ever again for not being able to suspend such a crazy-expensive laptop.

My second reason of not buying a laptop ever again: I have to pay for the sub-optimal hardware and software configuration most of which I already have

Let's suppose that one already owns a laptop and is about to buy a new one.  Let's just go over of what hardware components could be used from the old laptop:

  • Screen
  • HDDs, SSDs
  • Keyboard
  • Wifi module
  • Bluetooth module
  • Case

(I didn't list the motherboard, the CPU and the graphics card because Moore's law ruthlessly obsoletes these components.)

Some of these components (HDDs, SSDs, Wifi module, Bluetooth module) could be easily reused in a new laptop, but manufacturers provide no means to order a laptop without these components.  Other components (Screen, Keyboard, Case) could also be theoretically reused in a new laptop but manufacturers couldn't care less about designing according to the need of reusability. As a result customers have to pay for all components every time when buying a new laptop.  This is the opposite of the PC world.

And let's not even mention that nowadays almost every laptop come with glossy screens which I utterly hate because of their reflection, hence my journey of searching for a replacement matte screen begins, making me spend a hundred-something extra bucks but only if I get lucky enough to find a replacement matte screen.

On the software side of things given that I dislike Microsoft as much as I do and I don't even use Windows my first thing to do is to send back the laptop to Acer for them to remove Windows which takes about two weeks and I almost don't get any money back because I have to pay for my laptop to be shipped to the Acer service center. Fail!

The portable desktop

My approach involves using 1 main station and N dock stations, N being the number of places that I frequently spend time at doing heavy computing. If you're like most people then you only heavily use computers at home and at work.  That's two places.  I personally work from home but I have two locations between which I travel on a frequent basis and spend some time every time, leaving me with two places, too.

The main station is a Mini-ITX box composed of:

  • Case
  • PicoPSU power supply
  • Mainboard
  • CPU
  • RAM
  • Graphics card
  • Optionally Wifi and/or Bluetooth depending on the motherboard and on your needs

A dock station is composed of:

  • Monitor
  • Keyboard
  • Mouse
  • USB hub
  • DC power supply

Price comparison

Let's pick a super-capable desktop-like laptop like the Acer Aspire 8950G which will set you back with about $1,600 and will be replaced in every few years. (So far I could only see laptops with 18.4" screens which I consider desktop-like from Acer.)

Versus...

The permament parts of the main station cost $216 and composed of:

The soon-to-be-obsoleted parts of the main station cost $474 and composed of:

A dock station costs $400 and composed of:

You surely won't get the parts for these exact prices but the numbers are in the ballpark. That's $1600 recurring cost vs. $1016 one-time cost + $474 recurring cost.

Conclusion

I personally never needed a laptop, I needed a portable desktop.  The pros of these solutions are fairly apparent but I list them for completeness' sake:

Laptop:

  • Portability

Portable desktop:

  • Cost
  • Having the exact hardware configuration that you want
  • Better compatibility allowing you to suspend, resume on Linux

Right now I'm not sure when will I ditch my laptop. So far I'm satisfied with its performance but the time will come eventually, inevitably.

Given the lack of portability my approach is not for everyone but I think it's thought-provoking because many people don't even think about the possible advantages of such a configuration in this laptop-centric world.

EDA tools going online

March 4th, 2012

According to Atwood's law this was a predictable happening. These are the ones that I know about but I'll be keeping this list up-to-date in the future:

Although the above webapps are schematic drawing tools I can foresee fully-fledged online EDA solutions getting implemented in the future.

Migrated my news blogging to Tumblr

November 3rd, 2011

Today morning it's been an experience to notice that Google has fucked up Reader so badly as nobody could foresee. As to how such abomination could have ever been created by a company that is supposed to create web applications of superior usability is surely beyond me, but as a result of this event I migrated from the abandoned shared items page to Tumblr.

This post could have been tweeted due to its small size but I ultimately decided to post it there because of its significance.

Deck 82-Ice keyboard disassembly

July 13th, 2011

I have mixed feelings about this keyboard. Although it's a solid build cosidering the robustness of the case, I cannot overlook the fact that the fonts look ridiculous, the layout is weird and the overall look is rather displeasing. Also, choosing PCB mounting over plate mounting is not fortunate because a drop of water can kill the electronics, not even speaking about the reduced robustness.

It seems that TG3 Electronics tried to play it safe and they've minimized the manufacturing costs to get some profit despite the moderate number of sales. This strategy shows itself in not only not having a plate, but using only a single custom manufactured injection molded plastic part that is the top part of the case.

PCB mouting reveals the whole electronics making an excellent PCB porn for your viewing pleasure. The board features dozens of MX switches, LEDs and diodes (full NKRO for the win) and a CY7C63413C MCU that makes things happen. Most of the parts are surface mount but there are some through-hole parts (where it made sense price-wise, I believe). The PCB looks very high quality, I couldn't find any glitches.

The "You've got a big Deck" slogan on the box of the keyboard is rather strange considering that it's clearly a small form factor keyboard. The User's Manual mentions that a PS/2 port can be installed and I've read on their site that additional LEDs can be added to the sides, making the Deck 82-Ice the most hackable board built so far.

Deck 82-Ice keyboard disassemblyDeck 82-Ice keyboard disassemblyJul 25, 2012Photos: 56

Launchpad feature set proposal: Bounties

June 8th, 2011

Abstract

The objective of this post is to propose a new feature set for Launchpad to provide a way for users to create monetary incentives for developers to fix specific bugs or to implement new features.

The problem

The latest and greatest release of Ubuntu, Natty contains more than ten thousand packages.  The sheer number of packages inevitably contain an even larger number of bugs.  At the time of writing there are 90198 open bugs in Launchpad.

Many times Free Software developers work on a project for the reputation of their peers and for the challenge involved but often they cannot devote enough time to their project because they have to make a living.  As a result their project suffers which manifests itself in a large number of bugs and / or missing features.

Millions of users of Ubuntu have to deal with these bugs on a daily basis, usually by working them around or tolerating them.  Sometimes bugs get fixed quickly but many times they don’t get fixed for a long time.  In the latter case users cannot do anything to make a bug fixed apart from reporting the bug or fixing it by themselves, the latter being very time consuming and requires lots of expertise.

If users could create monetary incentives for developers to fix specific bugs or to implement specific features then it would be more likely for those bugs to get fixed or those features to get implemented.

Proposed solution

The model to be proposed works like the online marketplaces designed for freelancers to be employed.  In particular, I’d like to highlight Guru.com because they’re on the top of their game and they’ve implemented various practices that make sure that the job actually gets done and all parties are satisfied.

The actors involved are:

  • Donor: A user is a donor from the point on he/she deposited a bounty for a bug.
  • Developer: Can be an upstream or third-party developer who’s about to fix a bug for a given bounty.
  • Judge: An independent and competent third-party who has to make justice if donors have any objections about the completeness or quality of the fix after the developer has claimed the bounty.

The process could work like this:

  1. If a user chooses to provide a bounty for a bug, a deposit gets created for the specific bug and the desired amount gets added to it using PayPal or credit card transfer.
  2. Other users can also add funds to this deposit.
  3. At this point any donor can withdraw his/her bounty at any time.
  4. As soon as the bug gets assigned to a developer the deposit gets frozen and donors won’t be able to add or remove funds to it.
  5. The developer should deliver the fix within an approved timeframe and claim the deposited bounty.
  6. The bounty gets transferred to the account of the developer if none of the donors have any objections within a week or so.
  7. If any objection occurs then related parties can discuss it or eventually they can raise the issue to the arbitration phase where a judge is involved.

Some further thoughts:

Because of their dedication, familiarity with the given codebase and proven track record, upstream developers could be given the privilege of being able to exclusively work for a bounty for a specific amount of time.  This exclusivity period could last about one week from the creation of the deposit, for example.

It should be made sure that no developer is able to block the resolution of a given bug.  This could be either done by defining close deadlines or by allowing for any bug to be assigned to multiple developers.  In the latter case whoever resolved the bug first could claim the bounty.

It may make sense for such a system to automatically notify upstream in advance and ask them to agree to merge the upcoming fix and also request the developer to provide a fix in a format requested by upstream.

Canonical should get some portion of the bounty for developing and operating Launchpad and they could also provide judges.

Why Launchpad?

Launchpad is the ultimate umbrella project of the Free Software Universe.  As such, it relates and highlights every upstream project in a consistent manner.  Mark Shuttleworth said at UDS-O that “For most Free Software projects I wouldn’t be surprised to find if there are more bugs filed against that piece of Free Software in Ubuntu than upstream.”

According to the above it makes sense to implement this feature set on top of the existing, state-of-the-art and proven infrastructure instead of creating a whole new site for it.

Conclusion

There are many details left to be answered and nothing is written in stone, but I hope that this post is thought-provoking enough to start further discussions about the viability and towards the implementation of this idea.

I have witnessed online marketplaces working both as a freelancer and as an employer, but this idea could be so much cooler in regards of Free Software where everyone benefits from the work of developers and everything happens openly.

I’m looking forward to talk more about this issue, so if you have anything to say, please don’t hesitate to let me know in the comments.

FC200RC/AB Leopold Tenkeyless Tactile Click Keyboard disassembly

May 20th, 2011

First of all, I'm not about to go into an in-depth analysis about this board as the geekhack folks did. I'm just about to express some of my opinions and provide some PCB porn pictures.

There are only few keyboards that I consider solid builds. This is one of them. I've preordered this one farily early, got it about two months ago and happily using it since then.

There are several attributes that make a solid keyboard in my opinion. One of them is the materials used and the thickness of the walls of the plastic parts. The switches being place mounted vs PCB mounted is another big indicator. As for this keyboard, the plastic seem high quality and the wall thickness is about 2-3mm which I consider very good properties. It's interesting to note the similarity between the my Filco and this Leopold model. The case construction is pretty much the same except some minor details. As for its design, I rather prefer the Filco because the rounded edges of the Leopold don't appeal to me that much.

The use of Cherry keycap stabilizers has definitely surprised me because I thought that those can only be PCB mounted but these are clearly plate mounted and they seem less wobbly than the Costar stabilizers which makes me consider them superior. I've found a very bad solder joint that has been bridged to a nearby trace but apart from that the quality is very satisffactory.