Skip navigation

Tag Archives: c02ware

If you take a look at the page for the Tritech Service System distribution of Linux, you’ll notice a few new things. The most obvious is that I’m redoing the c02ware site design; there’s now a basic logo, proper site navigation, a mobile-friendly layout, and a cleaner-looking color scheme. Consistency across pages has been greatly improved, and lots of unnecessary old junk and confusing content has been completely tossed out.

This change is being driven by my push to release the Tritech Service System with all of our proprietary bits included as a commercial product, with regular updates, bug fixes, and support. I will continue to release TSS without any proprietary bits as a public and completely free system, but for anyone in the PC repair business, the paid-for stuff can easily pay for itself in workflow acceleration and productivity boosts within a month, and we want to be able to bring that advantage to other PC service shops and I.T. departments. If you are interested in being notified when the Tritech Service System becomes available for purchase, send me an email and I will keep you in the loop.

A major goal in TSS is keeping the system as small as possible without cutting out basic features. In the effort to move towards this goal, I have released MiniTSS 2.9.0! The download is a paltry eight megabytes in size, and includes includes the following software packages:

  • busybox 1.21.1
  • chntpw 110511
  • cifsmount (mount.cifs helper)
  • dd-rescue 1.28
  • dropbear 0.52
  • fuse 2.8.3
  • glibc 2.10.1
  • libblkid 1.1.0
  • libuuid 1.3.0
  • ncurses 5.6
  • ntfs-3g-ntfsprogs 2011.4.12
  • pv 1.2.0
  • rsync 3.0.7
  • socat 1.7.2.1
  • sysfsutils 2.1.0
  • tar 1.22
  • tss-base-fs-mini 101
  • tss-bootstrap
  • udev 163
  • xz-utils 5.0.4
  • zlib 1.2.3

MiniTSS is not just a live CD/USB system. You can download the “source” archive, unpack it on your Linux system, add or remove packages to initramfs as you see fit, and rebuild your own custom version with whatever software you actually need. The system only provides basic tools and a command line interface, and therefore is aimed at intermediate-level Linux users.

So far, only a few bugs remain in TSS 2.1, which is currently at  version 2.1-alpha5.  There are some problems currently being worked out with KMS support, which is the biggest issue so far.  The entire “init” system has been rewritten to replace traditional “init” with the runit-init tools provided by BusyBox.  The move to a partially modular kernel has been done, and we’re testing that out on machines to make sure it behaves as expected.  (Modular support is necessary for drivers that must load firmware, like most wireless network adapters and some of the KMS video drivers in the kernel).

We haven’t set up the “beacon server” features yet, mainly because some security issues need to be addressed.  Persistent home support has been thrown out for now, since we will be replacing it with something more robust in the future.  We’re not too far from the 2.1 release.  It’s going to be pretty sweet!  Stay tuned!

Update (2011-04-08): Up to -alpha7b2, trying to help the Linux kernel developers with some serious framebuffer issues.  It seems that Intel i915 framebuffers (inteldrmfb) like to cause a completely black screen at boot time on plenty of computers (and that’s even using today’s most recent git pull of the kernel code).  Radeon and nVidia once in a while has the same issue.  In the meantime I’ve built a second kernel that has all the graphics stuff stripped out so that we can use console-only mode.

(If you just want the good stuff and don’t care about the story, visit the snd2remote web page. Bottom line: run a listener on the LAN, then on a Linux box type “snd2remote C:/WINDOWS/Media/ding.wav”)

Problem: You’re running applications on a remote Linux system across a LAN, possibly using an X server such as Xming or x11vnc to view them on a Windows machine.  The programs run fine, displaying on the Windows machine, but there is no way to hear notifications on events such as receiving an email or IM. Every program has an option that lets you “run a custom command” on notification events, or has an available add-on that enables this functionality. There is no custom command that makes sounds play on the Windows machine you’re actually using.

Solution: Roll your own solution using free tools that are already available!

I use Mozilla Thunderbird for email and Pidgin for all instant messaging services. For two years, I have sat directly in front of the server at the shop and used these applications. Now, however, I use an old Windows laptop that we can’t sell for technical reasons along with Xming to run these Linux apps on my sever and show them as apps on my Windows laptop.  Unfortunately, as I have been getting busier and busier, I have been forgetting to periodically check my mail window.  Thunderbird in Xming has no tray mail notification and no sound on the Windows machine at all; likewise with Pidgin, which (at best) can put a star in the chat window title.  However, Pidgin on Linux comes with an option to “use a custom command” for playing sounds.  Thunderbird doesn’t, but an add-on easily adds “during new mail notification, run this command” capabilities to it.

So, I know that I CAN do this if I can run a command which plays the sound on the Windows machine, but a brief Google hunt turns up nothing of interest.  Oh, I’m sure somehow I can use JACK or some other complicated audio system, but I could care less about setting that up and dealing with the extra admin overhead if there’s a simpler way!

It takes some real Linux geek thought processes to do, but I figured out a way that, regardless of which machine in my shop I sit at, I can get audio notifications for my Xming apps (or any app that can run a command to play a sound for that matter).  The answer: UDP broadcast the sound you want to play to all the machines on the network.

I created a bash shell script and a Windows NT/2000/XP command prompt  batch file (it uses SET /P which I don’t think DOS/Win9x/Me have) that pair together to trigger sounds on my Windows machine from my Linux machine. An additional constraint which I artificially imposed on myself to minimize the number of required downloaded files was to only use Windows batch commands and not “cheat” by pulling a UNIX-style shell, sed, grep, and other UNIX commands.  This also forced me to learn some ways to do things in a batch file that I had never done before, meaning that not only do I make this easier to duplicate for others, but I’ll be a better Windows admin too.

I had to download the following free tools and Linux packages to make it work (links provided):

Here’s how we do it. The computer which is generating the notification event needs to order the computer at which we’re actually sitting to play some sort of sound. Ideally, we need to be able to play lots of different sounds, too. So, the quick and easy solution was to use socat (and netcat for Windows since there’s no native socat port) to broadcast the names of sound files to play and receive those broadcasted names, then try to play them.  Most of the time I spent was actually on file scanning and filtering code rather than making the *cat tools behave nicely.

“snd2remote” on Linux can both listen for events AND broadcast them, and does some fairly clever search tricks to try very hard to play a WAV file that is not valid for the Linux machine as-is.  The Windows version is restricted to batch file commands, which means it’s much “dumber” and therefore needs more hand-holding; most of the clever logic is in the Linux side so the Windows side can afford to be dumbed down.

snd2remote taught me the following lessons and/or has the following nice features:

  1. You can make netcat exit immediately on receipt of a single UDP packet in listen mode by piping an empty “echo” into it. This drastically decreases latency because the 1-second timeout is unnecessary.
  2. The way to remove timeout latency in socat is to specify a “udp4-recvfrom” endpoint instead of “udp4-listen” and also specify the “unidirectional” switch.
  3. Translating to backslashes for dumb Windows batch listeners and letting Linux listeners translate them back to normal forward slashes makes life a thousand times easier.
  4. Making the Linux version assume UNC paths such as \\server\share\path\file.wav equals /home/share/path/file.wav on the Linux side allows the use of a default Samba home directory share as a source for both machines to fetch the same WAV files from.
  5. Letting the Linux script perform quick scans in a couple of obvious locations for alternate copies of the specified file makes it extremely easy to feed Windows-specific paths and have them still play on the Linux listeners without replicating the path to the same file on Windows.
  6. snd2remote in listen mode checks the ROOT of the executing user’s home directory, does full subdirectory scanning of a custom directory (defaults to $HOME/media), and performs the previously mentioned UNC path to home directory translation, in an exhaustive effort to find a playable copy of the requested WAV file.
  7. It’s better to use the shell construct $(commands) than to use (backticked) `commands` because the latter interprets special characters in a way that makes life very painful.

By running “snd2remote -l” on a Linux box or “snd2remote-listener.bat” on a Windows box, any other Linux box on the LAN can broadcast a sound event to all listening computers with a simple command:

snd2remote [-q] /path/to/file.wav

For example, to play the classic Windows “ding” on all listeners:

snd2remote C:/WINDOWS/Media/ding.wav

If you are interested in the internal workings of these scripts, they are heavily commented to explain in detail what is going on.  Lots of shell/command interpreter constructs and command combinations are used in them which I had not needed, or had rarely used, before; therefore, these scripts would be a good starting point to nudge your way into some interesting scripting.

The code has grown too long and complex to document everything here, but it is freely available at the c02ware snd2remote page.

%d bloggers like this: