Skip to content

Blog Entries

  • 5 min read

Test procedures for new memory installations

When you buy a new computer or get one and you are not sure of the quality of memory that it has, or when you buy, upgrade or add new memory you should test it before going on to simply use it. The reason is quite intricate. In most probability the memory with will either work or won't and if the machine works it will be a good indication that the memory works fine. But in a few of the cases your machine may exhibit very strange behavior indeed. Various programs crashing, machine freezes, kernel crashes and the like. In that case, which may happen some time after the upgrade you may fail to connect the symptoms with hardware memory issues and attribute them to other factors like OS upgrades, driver installations or other peripheral failures. This may lead you, as it has led me, on wild goose chases after non issues which will certainly drive you insane or into writing blog posts at 4 AM. So what do I suggest? A simple and short 2 step procedure to be executed when using new memory in order to be sure that your memory is functional and well configured. This can also save you money since from my experience the probability of buying faulty memory is very high (at least 15% from my statistics).

First phase is to run the ubiqitous memtest86+. This is available via the boot menu of most current linux distros. This test runs for some time and long years of using it have led me to a solid statistic according to which if memtest does not find a problem with your memory in the first 30 seconds it will not find any problems in the next 30 hours. But, then again, this is just a statistic, feel free to run this for as long as you wish. If memtest fails return the chips to the manufacturer and get new ones (if you feel that it is the chips fauls - see the note below). If it succeeds then you need to go on to the second phase of configuring the memory properly.

Once the memory is installed open your bios configuration and see how is it configured. How are its parameters (speed and 4 more numbers) set. Is it on automatic or is it on manual? Do you have heterogenous memory banks? If so what is the speed of each and what is the overall speed of the entire memory subsystem? Why should you know all of this info, you rightly ask. Well, in a perfect world you would just buy memory, plug it in and the BIOS would configure and use it properly. Alas, this is not the world we live in. In reality you usualy buy the motherboard at date X and buy the upgrade or new memory at date Y. Y is a couple of years following X. This means that the memory you are buying is too fast for your motherboard. Shouldn't your BIOS be able to handle this? Well, yes and no. In lots of cases it does manage to handle it but in some it doesn't and believe me, you don't want to get stuck in the latter.

In my case I installed a DDR2 800 MHz memory on a standard Intel board which did not complain and the BIOS ran that memory at the auto-selected optimal speed of 800 MHz. There was no problem with the memory and so memtest ran smoothly. It's just that when the 2 cores were accessing it together with high speed then put more pressure on it than memtest did and memory faults started happening.

Second test is to just see if the memory is working properly with multi core. This phase can also be used to "overclock" your RAM and to make sure that you will not be experiencing any weird side effects from this overclocking. In this phase we will test the memory in practice using the N cores. I found that the best way to achieve this is to just compile the Linux kernel on the machine using make -j N where N is the number of your cores. Whenever I had memory problems this compilation would crash in some spectacular way and in random places and so served as a clear indication of RAM issues.

If you want to learn more about memtest and dual core checkout this and this in the memtest86+ discussion board. It seems that memtest86 (as opposed to memtest86+) does have multi core support. Cool. The problem is that on Linux systems usually memtest86+ is the only one installed...

If you want to know how to compile a Linux kernel learn more at this URL.

memtester: There is a package called memtester in Linux which will test memory from user space. In Ubuntu this package is simply called memtester. It is developed here. I have tried it out and it is a fine piece of code but does not do multi-threaded testing with CPU affinity. You have to do that on your own at the command line by running two instances of memtester and assigning them to different CPUs via taskset. Another problem with memtester is that you need to let it know how much ram to test which is very hard to do since you want to test as much as possible. This means that you need to calculate the size to test which is roughly total_ram_size-(size_of_os+size_of_all_currently_running_programs) which is a hard to calculate and if you miscalculate the program may fail since it locks the memory that it gets using mlock, which you need to have permission to perform. It may also throw other programs that you are running at the time into swap (since they are not locked into memory).

The kernel compilation mentioned above is better in my opinion due to the following reasons: it uses all of your CPUs and it also uses every last bit of RAM you have since the kernel is big and during the compilation stage will use up all of your Linux cache which means all of your spare memory.

Note: as mentioned in the memtester documentation, if you do find any problems with your memory it may not be the fault of your memory chips at all. It may be the fault of your motherboard not supplying enough power for the chips or the CPU, it may be an overheating CPU, a mis-configured BIOS or other reasons.

Please leave comments if you think that I am wrong in any of the above and I promise to improve the post if you convince me that I could do better...

  • 3 min read

Configuring ssh server for pubkey + password authentication

In a struggle to secure my home computer I did battle with the ssh server once again to configure it "just the way I want it" (tm). I prefer pubkey + password since this ensures that if I lose the laptop/phone/whatever then the lucky finder will not find his/her way into my home computer.

So, without further fanfare here are various bits that need to be done.

Configuring the ssh server edit /etc/ssh/sshd_config and use the following entries: Protocol 2 # protocol 1 is outdated PubkeyAuthentication yes # I want public key to be used for authentication (and possibly to be combined with a pass phrase)

And of course there a bunch of authentication protocols that are not needed: ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no PasswordAuthentication no UsePAM no

Creating the keys Still on the server in the home folder of the user you want to login remotely with, create the private/public pair using ssh-keygen -t dsa in ~/.ssh (the default location for ssh-keygen). You get two files: id_dsa (private key) and id_dsa.pub (public key).

I used dsa keys in this post and you can use rsa keys if you pass -t rsa to ssh-keygen.

In the same folder on the server create a file called authorized_keys which has the public key (it can just be a copy of id_dsa.pub but has the potential to contain many keys - possibly one per user that can connect to said account or one per roaming device).

When creating the key pair you will be prompted for a pass phrase. This is where you choose whether or not you will need a pass phrase (which acts as a password) in order to access this account. If you leave the pass phrase empty you're allowing key only access with no password which is dangerous since if anyone gets a hold of your roaming device he/she can access your account with no extra data.

Distributing the keys Copy the private key ~/.ssh/id_dsa to the roaming devices you want to access the server from (laptop, phone, whatever). If the roaming device is a Linux box then put the private key in the same location (~/.ssh/id_dsa) in the home folder of the user that wishes to access the server. If you are using some other ssl tool besides command line ssh on a Linux box to access the server then it should have a place where you plug the private key into. If it doesn't have such a place then dump it. Putty (a widely used ssh client on windows) has an option to use a private key for connection.

Note: While trying this out a lot of people seem to fail because they do all the experimentation on a desktop. In a desktop there is a system called ssh-agent which does the authentication for you in order to save you typing the same password multiple times. This agent is a problem when doing experimentation since it needs to be notified that you switched keys. So, every time you switch keys (regenerate the ~/.ssh/{id_dsa,id_dsa.pub} files) you need to run ssh-add to let the agent know this. Another option is not do all of the experimentation from a desktop but rather from a login shell (Ctrl+Alt+1 or whatever) so that the agent does not come into the game (which is complicated enough without it). Only after everything is setup re login to the graphical desktop and try everything out.

  • 3 min read

Real time programming tips: running critical tests at application startup

There is much accumulated wisdom in the embedded systems programming field as to how to correctly write a real time application. Examples of this wisdom could be found in the methodology of breaking up the application to a startup phase and a run phase, avoiding exiting the application, avoiding dynamic memory allocation and deallocation at runtime and more. There is also much accumulated wisdom in the programming field in general where a very important principle is ones control of ones software, as opposed to the other way around, and the notion of finding bugs and problems early whether that be in code writing, QA, deployment or beginning of execution.

The combination of the two aforementioned elements forms the principle of critical condition testing at application startup. According to this principle you should put all environmental concerns as tests to be executed at the startup phase of your embedded application. Environmental conditions to be checked may include, among others, the following:

  • Operating system or C library versions as the software may be adjusted for specific versions of these.

  • Real time patch availability and version as the software may require real time capabilities.

  • System real time clock accuracy as the software may require the availability of an accurate system clock.

  • User under which the software is running as the software may require special permission or user at some point in it's execution.

  • Free disk space availability as the software may require some disk space.

  • Free memory availability as the software may accidentally be run on a system with less than the required amount.

  • A previously running instance of the same or other software that may hinder the softwares operation.

  • The availability of certain APIs of the kernel or certain kernel modules which are required.

  • The availability of certain devices (/dev files) with permission to access these.

All of these checks should be run in the first second or so of the software's execution and, contrary to normal wisdom, should cause the software to halt and not proceed with normal execution. The reasons for this scary tactic is that:

  • You may miss error printouts from your application and so run around trying to find errors in all the wrong places.

  • You want the errors to show up early and anything that can be made to show up early should be made so.

  • I have seen programmers confidence in their hardware/OS/environment break too many times and lead to endless hours of wasted effort which could have been prevented by using this strategy.

Some requirements are of the make or break type and you really should not go on running without them.

  • Some of the requirements of real time and embedded systems are so subtle that you would not even notice these break as error in runtime but rather get weird behavior from your system. These are very hard to pin point and should be avoided.

These checks should also be written in a way which enables them to be easily removed when the system has stabilized, when it's environment has stabilized (like when the system moves to production) or in order to reduce boot time.

This principle is especially important to real time and embedded systems programmers because of a few factors:

  • real time and embedded systems are harder to debug and monitor.

  • real time and embedded systems have less tools on them that enable one to find bugs.

  • real time and embedded applications are much more sensitive than other types of applications to various changes in the environment.

  • embedded systems programs usually interact with other systems which are in the debug phase as well and so may throw the developers on endless bug hunts which waste valuable time and cause the developers to mistrust their entire design or the system and tools that they are using.

  • embedded software systems usually run 24/7 and have only an end user interface. if at all. Due to this many embedded applications only output a long log and as such either encourage the user to disregard the log completely or make the task of discerning which log lines pertain to critical errors a daunting task.

  • 1 min read

Command line id3 2.4 tagging in Linux

In the past couple of weeks I have been dabbling with command line to tag and inspect tags of mp3 files. Linux has an abundance of tools to fill this niche and it's confusing to know what to use. What follows are my conclusions.

id3: only handles 1.1 tags. id3v2: does not handle 2.4 tags. id3tool: does not handle 2.4 tags. Not maintained. eyeD3: handles everything (especially 2.4 tags), has lots of options and seems to be supported.

So it's fairly obvious what to choose. Please let me know if you have any more candidates to add to this list or you disagree with any of my conclusions.

  • 1 min read

Musical tempo name to BPM table

I needed a concise, modern and easy to use tempo names table and couldn't find a good one on-line (which came as a surprise to me - maybe I'm not adapt at this Google thing...). The article on "Tempo" in Wikipedia has a lot of information but lacks in this regard. So here is a table for my and hopefully your use. This table is derived from a standard modern metronome that I use (Korg KDM-2).

NameBPM range Largo(-)40-60 Larghetto60-66 Adagio66-76 Andante76-108 Moderato108-120 Allegro120-168 Presto168-200 Prestissimo200-240(+)

  • 1 min read

I sometimes need to find all broken symbolic links in a folder, recursively or not. find(1) is the all UNIX right tool for the job as far as finding files is concerned but it does not have an explicit -and -type brokenlink option...

Some solutions involve sending the output of find(1) to some other tool. These solutions are sub-optimal in that once you leave the comfort of find(1) you give up the ability to use many of it's fine features and run into other problems (file names with white space characters just to name one such problem).

Other solutions involve doing find -L . -type l which forces find(1) to follow all symbolic links and ultimately only print those which it cannot follow. This solution has other drawbacks. One is that you do not necessarily want find(1) to follow every symbolic link since this may cause it to wander to huge areas of your hard drive that you do not wish to scan. Another deficiency is the fact that there is a difference between a symbolic link that cannot be followed and one which cannot be read.

My solution is this: find . -type l -and -not -exec test -e {} \; -print

  • 1 min read

Altering the character set of a MySQL database

It happens often that I forget to change the default character set of a database to utf8 and so find out late in the development cycle that many of my fields are based on non utf8 character sets (mostly latin1). Then I go in and modify each field in turn using ALTER TABLE [table] MODIFY [field name] [field type] CHARACTER SET [charset]. After some digging I found the ALTER TABLE $TABLE CONVERT TO CHARSET [charset] syntax which converted all fields in a table to a certain character set. I looked for a similar syntax to convert the entire database and found ALTER DATABASE which, unfortunately, only changes the default character set and collation but does not affect the existing tables, fields or data.

So here is a script that repeats ALTER TABLE / CONVERT TO on each table in your database:

#!/bin/bash

# parameters...
USER='[your db user name]'
PASS='[your db password]'
DB='[your db]'
CHARSET='[character set (utf8?)]'
COLLATION='[collation (utf8_unicode_ci?)]'

# here we go...
QUERY="SELECT table_name FROM information_schema.TABLES WHERE table_schema = '$DB';"
TABLES=$(mysql -u $USER --password=$PASS $DB --batch --skip-column-names --execute="$QUERY")
for TABLE in $TABLES; do
        echo "ALTER TABLE $TABLE ......"
        mysql -u $USER --password=$PASS $DB -e "ALTER TABLE $TABLE CONVERT TO CHARSET $CHARSET"
        #mysql -u $USER --password=$PASS $DB -e "ALTER TABLE $TABLE CONVERT TO CHARSET $CHARSET COLLATE $COLLATION"
done
  • 1 min read

Switching Java versions on a Debian/Ubuntu system

I recently found some issues with the openjdk Ubuntu/Debian default Java implementation. Specifically I had issues with their web start support (javaws). I found that the Sun implementation of Java did not have such a deficiency and the Sun implementation is available through the regular Ubuntu/Debian package sources. I installed the Sun implementation and wanted to switch the default Java to that version.

So what have I found out ?

When you want to switch to the Sun implementation: sudo update-java-alternatives --set java-6-sun

When you want to go back to the openjdk implementation: sudo update-java-alternatives --set java-6-openjdk

Notice that once you do any of the above you leave "auto" mode which means that new installation of Java implementation will not switch your default one. If that is what you want then ok. If not you can return to "auto" mode with: sudo update-java-alternatives --auto

  • 2 min read

Using "noatime" on a running Linux system

When upgrading my Ubuntu system my /etc/fstab got overwritten by the upgrade process. It seems that the new /etc/fstab file did not keep my old preferences for file systems. I didn't notice this for some time but what I did notice was that my system was sluggish. After some time I recalled that I had previously used noatime as a mount option for all of my hard drives which gave me some more speed and treated my hard drives with a softer touch.

First lets explain what noatime means. atime or Access Time is an attribute stored by all well behaved UNIX file systems for each and every file. It is one of 3 dates stored: meta info modification time - ctime, last modification time - mtime and last acces time - atime. Out of the 3 atime is the most controversial since it means that for every read from the disk there is a write operation. This is one of the worst defaults in your UNIX system.

The solution is just to disable atime altogether. Warning - this may cause some weird applications that rely on atime to break. If you want your system to be as "default" as possible don't do what I suggest. If you want better performance and hard disk lifetime and on the other hand don't mind parting ways with one or two misfit applications then this trick is for you.

How do you do it? Just edit /etc/fstab and add noatime at the 4'th column where file system mount options are for any file system you want to avoid access time updating. Reboot your system. Run mount(1) to see that all your file systems are mounted correctly. Enjoy.

What applications break? Actually - I have yet to see an application break because of this change. I have been running with "noatime" for 2 years now and all the applications seem to behave well. If you know of an application that breaks please let me know...

  • 5 min read

חוץ וביטחון: יותר ביצים משכל?

זהו מאמר ישן שפירסמתי בזמנו באתר אימאגו...

מחלוקת עתיקת יומין בקרב פילוסופים למדעי המדינה נטועה בדילמה: מה חשוב יותר בשליט או שיטת שלטון - האומץ והיכולת לקבל החלטות או השכל להבין לעומקן בעיות קשות ולדעת את ההחלטה שיש לקבל. מכיון שלא ניתן לקבל הכל בחיים הרי שנרצה לקבל תשובה לשאלה זו על מנת שנוכל לבחור את שיטת השלטון העדיפה לנו. במאמר זה אנסה להתמודד עם שאלה זו.

אם יש משהוא שמתחוור לאנושות עם הזמן הוא שהעולם בו אנו חיים מורכב לעין שיעור מההפשטות הבאנאליות של אריסטו או אפלטון. אם יש צורך בדיברגנצים ותורת החבורות על מנת לחשב את מיקומו של קוארק בודד, איזו משמעות יש לדבר על אסטרטגיות למדיניות חוץ ובטחון אשר מערבות מיליוני בני אדם בסיטואציות מורכבות מאוד, כאשר כל אדם הוא מושבת תאים אדירה משתפת פעולה וכל תא הוא אוסף אדיר של קוארקים? לכאורה נדמה כי אין מוצא מן המבוך. המציאות מסובכת מדי ולכן אין שום דבר אינטיליגנטי שאנו מסוגלים לומר עליה - במיוחד ברמות כה גבוהות כמו מדיניות חוץ ובטחון.

ברור לנו כי המציאות מסובכת אולם הבסיס לדיסיפלינות כמו כלכלה, היסטוריה ומדעי המדינה הוא שלמרות המורכבות המדהימה של המציאות ניתן לזהות בה ברמות המאקרוסקופיות של אדם וחברה תבניות סטטיסטיות יציבות, והן המסקנות שאנו מסוגלים להסיק בתחומים מעין אילו. אין אדם בר דעת שיערער על מסקנה זו ולכן לא ארחיב בנושא.

אם אכן אנו מקבלים את המסקנה שניתן לומר דברים אינטיליגנטיים על ישויות גדולות כמו אנשים ומדינות, למרות המורכבות הפנימית הגדולה של ישויות אילו, אזי נשאלת השאלה האם מדיניות חוץ ובטחון חייבת להיות מורכבת? התשובה המפתיעה היא לא. ישנה מדיניות חוץ ובטחון אשר במובנים רבים היא אידיאלית ולמרבה הפלא אף פשוטה ביותר.

כיצד נתור אחר מדיניות פלא זו? הבסיס נמצא בהבנת הקבועים ביחסים בין מדינות. אין ספק כי מדינות מרויחות משיתוף פעולה הדדי ומפסידות מחוסר שיתוף פעולה, חד צדדי או הדדי. יש לשים לב כי הרוחים המוזכרים מתיחסים לאזרחים ולא לשליט זה או אחר. זוהי תכונה של הטבע סביבנו והעובדה שניתן להפיק ממנו יותר בכוחות משותפים. תכונה זו אינה ארעית ועדויות לה קיימות לאורך ההיסטוריה עקובת הדם של המין האנושי. עוד תכונה מעניינת המתארת יחסים אלו בין מדינות, היא שאם אף אחת מן המדינות לא תעלם, הרי שהמדינות נידונות להחליט החלטות אלו על שיתוף פעולה מול עוינות שוב ושוב ללא קץ.

האם יש בנמצא מודל מתימטי המתאר במדויק תכונות אילו ביחסים בין מדינות? אכן יש! זוהי דילמת האסיר (Prisoner's Dilemma) המפורסמת אשר נחקרה רבות בתורת המשחקים המתימטית לצרכים כלכליים, פוליטיים, ביולוגיים ואחרים.

בדילמת האסיר תופסת המשטרה שני עברינים. אם שניהם ילשינו זה על זה, שניהם יפלילו האחד את השני וילכו לכלא לתקופות ארוכות (שניהם יפסידו). אם אחד ילשין והשני ישתוק, אזי המלשין יקבל עונש קל בלבד וחברו ילך לכלא (אחד מרוויח והשני מפסיד), אם שניהם ישתקו אזי שניהם ילכו לכלא לתקופות קצרות (שניהם ירוויחו).

נשאלת השאלה מהי האסטרטגיה העדיפה כאשר אנו משחקים את דילמת האסיר. התשובה החד משמעית היא להלשין. הסיבה היא שאסטרטגיה של שתיקה היא אסטרטגיה נשלטת על ידי הצד השני. כלומר, אם אנו שותקים אזי אנו משאירים את גורלינו לקביעה על ידי הצד השני אשר מנסה למקסם את הרווח שלו ולכן יבחר להלשין. מכיון שהשיקול הזה ברור לשני הצדדים, אזי שניהם ילשינו.

משחק שונה הוא דילמת האסיר החוזרת. במשחק זה אותם שני שחקנים ישחקו את דילמת האסיר זה מול זה פעמים רבות מאוד. אם אותם שני עברינים יקלעו לאותה סיטואציה שוב ושוב, נשאלת השאלה, מהי האסטרטגית ארוכת הטווח אותה עליהם לאמץ?

בספרו המרתק The Evolution of Cooperation מתאר מדען המדינה רוברט אקסלרוד (Robert Axelrod) ניסוי בעריכת טורניר בין אסטרטגיות שונות למשחק בדילמת האסיר החוזרת, אשר הוגשו על ידי מיטב המוחות כתוכניות מחשב. האסטרטגיות שוחקו, בכל הזוגות האפשריים זו מול זו. המנצחת בהפרש ניכר בסיבוב הראשון היתה האסטרטגיה "מידה כנגד מידה" (Tit For Tat) אסטרטגיה זו טוענת כי יש לעשות ליריב שלך את שעשה לך בסיבוב הקודם. אם בסיבוב הקודם שיתפו אתך פעולה אזי שתף פעולה ואילו הלשנה תתוגמל בהלשנה. לאחר שיידע אקסלרוד את משתתפי הטורניר בתוצאות הסיבוב הראשון, ביקש מהם מקצה שיפורים ולמרבה הפלא, אף שכל הפרופסורים ידעו שמידה כנגד מידה זכתה בסיבוב הראשון, התוצאה היתה זהה.

הסיבות העיקריות לכך שמידה כנגד מידה זכתה בטורניר הן: פשטותה ולכן בהירותה לצד השני, הענשתה באופן עקבי חוסר שיתוף פעולה, תגמול באופן עקבי שיתוף פעולה והמסקנה הברורה שהסיקו כל המשחקים מולה שהדרך היחידה להרוויח במשחק נגדה היא על ידי שיתוף פעולה איתה.

למעשה קיימת התאמה מופלאה בין דילמת האסיר החוזרת לבין היחסים שתוארו בין מדינות ולכן התוצאה מדהימה: ישנה אסטרטגיית חוץ וביטחון פשוטה, ברורה ואידיאלית. מכאן המסקנה טריויאלית: לא צריכים להיות אסטרטגים גדולים על מנת לנהל מדיניות חוץ וביטחון! הדבר היחיד שצריך הוא אומץ ויכולת שלטונית לקבלת החלטות קשות על מנת לישם את אסטרטגיית מידה כנגד מידה, גם בקונפליקט וגם בשלום.

מסקנה זו תומכת בעמדה שהדבר החשוב בשלטון הוא השילוב בין קבלת ההחלטות הנכונות אך הפשוטות, כמו מידה כנגד מידה, לבין היכולת השלטונית לבצען. נראה כי מה שאנו צריכים הוא דיקטטור לא חכם במיוחד אך בעל יכולת קבלת החלטות קשות כמו יציאה למלחמה או עשיית שלום.

מצד שני שינוי שיטת השלטון מדיקטטורה למשטר נציגים (או כפי שהוא קרוי כיום בטעות או במזיד - דמוקרטיה), הביא להפחתת כוחו של השלטון המרכזי. קשה לערער על הקביעה כי שינוי משטר זה היה שינוי לטובה, לפחות לרוב האוכלוסיה. מכאן נדמה כי הפחתת כוחו של השלטון המרכזי היא יתרון. באשר לדילמה שהצגנו נראה כי עמדה זו תומכת בכך שהאומץ והיכולת לקבל החלטות חותכות אינו מרכיב קריטי בשיטת שלטון מוצלחת וכניראה ששכל מהווה מרכיב חשוב יותר.

כיצד ניישב את הסתירה בין המסקנה המפתיעה של אקסלרוד לבין העובדה הברורה ששלטון הנציגים נראה כהצלחה? הפתרון פשוט. השלטון הרודני כה גרוע עד כי הוא חסר את דרישתנו הראשונה: "קבלת ההחלטה הנכונה", למרות שהוא חזק ביכולת ההחלטה והביצוע. השלטון הרודני בעייתי במידה כזו שההפסד בהקטנת יכולת ההכרעה שלו במעבר לשלטון נציגים קטן בהשוואה להקטנת הכוח לקבלת החלטות גרועות מאוד. זוהי הסיבה העיקרית להצלחותיו היחסיות של שלטון הנציגים. המסקנה היא, אם כן, שאקסלרוד צדק אולם אנו עדיין רחוקים מאסטרטגית החוץ והביטחון הנובעת ממסקנותיו ונאלצנו לטפל קודם כל בצורת קבלת ההחלטות הקאטאסטרופאלית של הדיקטטורים. אין צורך בשליט בעל אסטרטגיות מתוחכמות שכן האסטרטגיה הנדרשת היא פשוטה. אך קודם יש לודא שהחלטותיו של השלטון המרכזי הן שפויות.

האם כדאי ללכת רחוק עוד יותר ולהקטין עוד את יכולת ההכרעה של שלטון הנציגים? נראה שהתשובה המתבררת בשנים האחרונות היא "לא". שלטון הנציגים נראה כמתאים יחסית להחלטות בקנה מידה קטן ובינוני אך אימפוטנטי בהכרעות הרות גורל. מספיק אם נזכיר את חוסר יכולתו של השלטון הישראלי להכריע במלחמת לבנון הראשונה על ידי החלטה עקרונית לחסל את יאסר עראפת ולאחר מכן את חוסר יכולתו להוציא את הכוחות במשך 18 שנה. האם השלטון כאן הראה שהוא שולט במציאות או שהמציאות שולטת בו? נראה ששלטון הנציגים חלש במידה מסוכנת ולכן דיבורים על הקטנת כוחו מיותרים. למעשה כאשר אנו מרגישים כי העם רוצה מנהיג חזק, נמצא כי הסיבה תהיה היכולת של מנהיג חזק לקבל החלטות ששלטון הנציגים אינו יכול לקבלן. לצערנו הגדלת כוחו של השלטון גם היא בעייתית. כמות האנשים האוחזים בשלטון קטנה ואנו עלולים להחליק במדרון החלקלק המוביל אותנו חזרה לחיבוק הדוב של הדיקטטור.

האם אין מוצא מהמבוך? האם אין שיטת שלטון בעלת כוח של דיקטטור לישם אסטרטגיות כמו מידה כנגד מידה, שאין לה את הנטיה של דיקטטורים לקבל החלטות הרות אסון לאוכלוסיה? שלטון הנציגים אימפוטנטי מדי מכדי לענות על דרישות אלו ודיקטטורים שנראים בתחילה חייכנים מתגלים כחובבי אורניום מועשר.

אל דאגה, הפתרון כבר כאן!