Monday, April 11, 2016

eeePC 701 and Debian GNU Linux

After some attempts and adjustments, I decided to publish my notes about configuring my eeePC 701 with Debian GNU Linux "Jessie".

Initially, my idea was to setup Jessie to use the netbook as a smoker machine for CPAN. It turned out that those tips (which I gathered around and made some experiments myself) are generic enough for anybody trying to configure this particular eeePC model.

"Fix" the fans

The eeePC fans are somehow problematic, they won't work properly automatically after you install Jessie. But fixing it is basically two commands on the shell, so no big issue at all:

apt-get install lm-sensors fancontrol

Without fancontrol and configuration, the fans will be working all the time. Well, it could be worst, take a look at my previous post eeePC 701 and OpenBSD.

Problems with keyboard

My keyboard options were not taken correctly during setup, probably because I made some mistake or because I replaced the default keyboard on my eeePC for a Brazilian ABNT 2. Nevertheless, the commands below will take care of it:

apt-get install console-setup
dpkg-reconfigure keyboard-configuration
service keyboard-setup restart

Compile yourself a new kernel

It is useful to create a smaller kernel and save memory and disk space by removing unnecessary features for the hardware resources lacking eeePC 701 . Also be sure set the processor as “core duo” and disable all resources for virtualization.

This process will take a long time, but it will payoff later.

First, install the following packages: fakeroot, kernel-package and linux-source-<version> (where version is whatever version you're interested in).

Then copy /usr/src/linux-source to a pendrive and compile the kernel from there. "Why a pendrive?" you might be asking yourself. Well, eeePC 701 has 4GB of SSD space and this will not help you to compile a kernel due the size of the source and temporary files. Of course, any other media will work too as long as Jessie has the proper kernel modules to mount and use it.

Then set the already discussed kernel options and compile it. I'll not give you all the details about kernel compilation on Jessie, there are a lot of tutorials available for that.

Finally, don't forget to remove the installed packages to recover disk space after installing and testing the new kernel.

Configure improvements for SSD

That's a very important configuration for eeePC 701, not only to improve speed but also to extend the SSD life. Here are the steps:
  1. Set I/O scheduler to noop (configure the systemd to start the rc.local file) with a echo 'noop > /sys/block/sda/queue/schedule' >> /etc/rc.local
  2. Use ext4 as the file system. It already has good features for SSD by default.
  3. Add “noatime,discard,commit=30” to the respective /etc/fstab entry.

Configure to ignore lid closing to avoid suspend mode

This is somehow optional. But since I was configuring the eeePC to leave it running unattended, it seems an obvious option. The alternative was removing dust from the screen and keyboard everyday...

Edit the file /etc/systemd/logind.conf to include the following two lines:


Install local DNS cache

That's some kind of optimization I like to do myself for any Linux box, but since you're already at the shell, do yourself a favor and install this little guy to help you speed up DNS queries:

apt-get install dnsmasq


That's it! I found out that Debian "Jessie" was a good option to install on eeePC 701. It was lightweight (boot time is really fast compared to other distributions I tested) and setup was good enough. I didn't test configuring a Window Manager to it, but I believe that LXDE and Xfce are good options for the small screen of the netbook.

Thursday, April 7, 2016

Cross platform sleep with eScript

Actually this post should be split in two, but I mixing them here... anyway, you can adapt it to your specific needs.

Now and then you might find yourself in the situation that you're doing some processing with eScript and got some kind of contention that forbids the code to continue processing... could be a resource missing (delayed generation) or other conditions.

In those cases (specially if you're doing some kind of long batch processing and don't want to abort everything), you wish that the eScript related OS process just wait a bit.

eScript has this deficiency of not providing a function for that. You don't want also to put your code in a loop doing something just to expend time because it will use CPU time for that. You want it to just sit down for a while and check later if the condition regarding the contention changed.

For that, you could use SElib.dinamicLink method. This allows to load a library and execute a function from it. It is not efficient by any mean (to load an external library) but you will (hopefully) put your process to a sleep state without expending much CPU while doing it.

The library you're going to invoke depends highly on the OS you running the Siebel Server. For MS Windows, it should be "kernel32.dll". For Linux, "" will do it for you.

If you have a mixed composition of Siebel Server on different OS's, creating a reusable function gets more complicated. There are several workarounds to solve this, but I'm specially inclined in using environment variables to check for that. Those variables are easy to use and can be checked from eScript by using the Clib.getenv method.

Here is an example:

function sleep(time) {

    try {
        if ( Clib.getenv("OS") == "Windows_NT" ) {
            var miliTime = time * 1000;
            SElib.dynamicLink("kernel32.dll", "Sleep", STDCALL, militime);
        } else {
            SElib.dynamicLink("", "sleep", time);
        TheApplication().RaiseErrorText("Failed to invoke sleep: " + e.toString() + e.errText());
        return false;
    return true;


At least my MS Windows 7 box here has this "OS" environment variable by default. Linux doesn't have one, but you could create it as well.

And then you can this function whenever you need to put your code to sleep for a while, probably inside a loop.

You could also use Clib to invoke an external program that will sleep for you, but this can not be as efficient as using the OS library function for that. You should test if you find SElib to be too slow for your case.