GNU Planet

Richard Stallman, and others, have explained rather well important legal and social reasons for why clearly Mono should not become a default part of a Debian GNU/Linux install, or similarly used for core applications of the GNOME desktop. This is especially true I think in regard to the Debian social contract which is meant to assure that core packages are built from and use free (as in freedom) software, that is without encumbrances or surprises. The ECMA process allows for patent surprises even in the core language specification itself, which can be patent licensed under RAND terms. I happen to believe there are additional valid technical reasons for not including Mono as a core part Debian.

While some may be surprised I should speak so strongly on this topic, given my involvement with Debian and Ubuntu, I found it an ethical requirement to speak out about this, and especially given my past involvement in dotgnu, I have come to feel that the community is being deliberately mislead by some about the what I think the role of Mono probably should have been. While I can see why Mono can be an important tool for promoting and enabling cross-platform development, a role that has been neglected, I believe in fact for this very reason Mono applications should NOT be used to build core required applications or be part of the default install of a distribution, just as for example Java applications are not used to build default core Solaris specific applications for Solaris, or (shutter) Visual Basic was used to build default applications shipped with Microsoft Windows (I am assuming they never did that…).

Hence, I do not see Mono as particularly useful for developing GNU/Linux specific free software applications, but rather in better enabling legacy proprietary ISV’s to build cross-platform add-on/value add applications and migrate to the free world. In this role, there would then be pressure from these ISV’s, many of whom may participate in Microsoft development, to keep Mono/.NET honest and truly cross-platform compatible. When we use Mono to build core GNOME applications, such as Tomboy, Banshee, and Beagle, we remove this pressure, and encourage what should be a cross-platform technology to be used as a single platform one, making it easier for Mono and platform specific GNU/Linux free software written with it to be more effectively ghetto’d by Microsoft. The greater there is this dependency on Mono for core parts of the GNU/Linux platform, the greater the vulnerability to those risks Stallman outlines.

Furthermore, if only a few “core” applications require it, and there are alternative applications that do not, why drag a 40 or 50 meg dependency onto everyone? Mono dependency might well be enough to be the difference between a single live CD distribution or one that requires DVD media to fit. While Microsoft’s proprietary legacy platform is tied principally to Moore’s Law and desktop computing, GNU/Linux is not. GNU/Linux is a free software platform for current and next generation hardware such as smartbooks, and is platform agnostic. Just getting Mono to sorta run on ARM has been a major distraction that should not have been necessary in the first place.

I also think an important goal of a default core distribution should be a GNU/Linux experience that is both GNU/Linux specific (unique) and works well for users. If, as we see in tomboy vs gnote, or tracker vs beagle, there is such a large discrepancy in performance and resulting user experience, then I think clearly Mono is the wrong choice to make even for purely technical reasons alone.

Part of that user experience is a consistent packaging and operation within the rest of a GNU/Linux system. In this respect, I have read the Debian packaging policy for Mono applications, and it highlights the fact that fitting Mono on a Debian GNU/Linux system is actually more awkward than packaging Java for Debian. Essentially, it suggests one creates a /usr/lib/progrname directory, and fill it both with the applications libraries and executables, and then write a wrapper script for /usr/bin. This is because Mono carries certain policies and expectations one finds on Microsoft Windows, where applications and dependent libraries were often bundled together under a private directory because binaries were never shared between vendors. This wasteful inefficiency and inability to cooperate that is the hallmark of proprietary software practices creates to me a very unnatural packaging policy requirement for Debian.

I know of course this viewpoint is at odds also with at least some others that are involved in Debian and Ubuntu, but it represents what I do think and feel is the best course of action. I personally do not fear nor dis-favor Mono, I simply do not personally believe it belongs in a core or default install of Debian or Ubuntu GNU/Linux distribution, and should not be used to build critical or default applications for GNOME. Other use cases individual developers must consider, especially given, as a cross platform technology, many of the licensing issues involving Java have been resolved, and Java is more platform agnostic. However, putting free software platforms at risk simply because certain individuals and Novell made a large investment in Mono only to find it cannot succeed as a cross platform technology against Java is to me a very selfish motivation.

Of course at the time Mono first appeared, Java was not licensed as free software and there was uncertainly around it. That being said, I do of course feel more comfortable with the present licensing situation of Java than with that of Mono. However, I would not suggest, even on purely technical merits, writing core parts of GNOME in Java or requiring Java as part of a core distro install, just as strongly and for many of the same reasons as I would not with respect to Mono either.

Finally, I recognize a lot of excellent work has been put in making Mono a viable technology, and I believe this work has it’s best chance to endure with it being far more clearly and honestly presented in the role of a cross-platform enablement technology. That also is the best way I see to reduce the risk of potential patent traps by Microsoft.

I use Bazaar personally but have waited to put anything online because I didn't want to use my personal web space. SpeedX uses Bazaar and the current source of SpeedX can now be browsed at http://bzr.savannah.gnu.org/lh/speedx

or downloaded by

A month of the Hurd: Git migration, stand-alone libpthread and updated status. Details.

This month Thomas Schwinge finished migrating the main Hurd, GNU Mach, MIG, libpthread and unionfs to Git. You can find the new repositories at http://git.savannah.gnu.org/cgit/hurd/.

Also, he made libpthread buildable stand-alone by separating its build system from the Hurd's.

Additionally, Olaf Buddenhagen wrote a usability report about his experience with the GNU Hurd for everyday work.

Hi,

I am working on the debugger for VisualGST :

imagik.fr

Now you can step, step into, run and inspect the stack.

http://visualgst.bioskop.fr/

Cheers

For many years we've had an entry on the games tasklist item for "A realistic train-driving simulator." I've found two projects that might satisfy this requirement: http://www.openttd.org/ (which is GPL licensed) and http://openbve.trainsimcentral.co.uk/ which is public domain. Both take different approaches to the idea of simulating train traffic, and both look pretty interesting in their own ways.

The source is now maintained in a Git repository. See https://savannah.gnu.org/git/?group=gettext for details. The CVS repository is now out-of-date.

So here I am, happily hacking along at my first Iliad web application, when I get all fancy and want to set it up on a public server.

Heh ... a bit of fiddling required, since neither "my" Iliad nor "my" gst are out of the box anymore, but applying two patches is not too hard work.

Now I have everything ready: patched gst starts the REPL, gst-package builds OnlineTester.star, gst-load -viI ot.im OnlineTester ... throws an error, while starting Swazoo. Ah, yes, I think quickly, that port is already in use here. So I change, rinse and repeat ... and the error is still there. A FileError? When opening a socket. What?

read more

Hi,

At last, I finished my exams And there are some news about GNU Psychosynth.

1. A Gmane gateway has been created for the project lists. This improves archiving and eases reading and posting using an Usenet interface, so you don’t have to receive everything in your email. More info here.

2. Alexander Morgado has contributed some Ubuntu packages for Psychosynth. It should ease things a lot for those Ubuntu users having problems compiling the software. Many thanks Aleks! Mor info here.

See the release announcement here:
<http://lists.gnu.org/archive/html/bug-vc-dwim/2009-06/msg00002.html>

So here we go again ... this time using native Smalltalk code to describe package contents in a DRY way:

Eval [
  PackageBuilder new
    name: 'MyPackage';
    namespace: 'MyNamespace';
    prereq: 'Package1';
    prereq: 'Package2';
    ...
    testsBelow: 'Tests' matching: '*.st';
    filein: 'File1.st';
    filein: 'File2.st';
    ...
    buildXml
]

read more

I have read Russel Coker’s nice article on identifying use of thread unsafe functions. This reminded me of a script I wrote a long time ago that is part of GNU SASL’s regression suite: threadsafety.

As you can see, my script looks for functions mentioned in the latest POSIX specification as being thread unsafe. In the last POSIX release, they actually removed some older interfaces (e.g., gethostbyname) so the script also checks for thread-unsafe functions mentioned in one older POSIX specification.

Russel’s approach is to look for man pages of functions ending with _r and labeling the non-_r-function as a thread unsafe function. Russel’s and my approach are quite different, so I wanted to compare the results. There is potential for me to add more functions to search for. I still want to preserve my approach of explicitly listing known thread unsafe functions, though.

Running Russel’s command, I get a list of functions that my script catches that Russel’s doesn’t, and vice versa. For reference, the functions that my script catches that Russel’s doesn’t are:

basename catgets dbm_clearerr dbm_close dbm_delete dbm_error dbm_fetch dbm_firstkey dbm_nextkey dbm_open dbm_store dirname dlerror endgrent endpwent endutxent ftw gcvt getc_unlocked getchar_unlocked getenv getopt getutxent getutxid getutxline inet_ntoa l64a lgamma lgammaf lgammal localeconv nftw nl_langinfo putc_unlocked putchar_unlocked putenv pututxline setenv setgrent setpwent setutxent strsignal system unsetenv wcstombs wctomb

The list contains lgamma, lgammaf, and lgammal which are all excluded by Russel’s command. I don’t understand why — according to the man page, the functions uses a global variable for sign, which doesn’t seem thread safe. So it seems right to include them?

What’s more interesting (for me) is the list of functions that Russel’s script catches that my script currently doesn’t. Here is the list:

erand48 ether_aton ether_ntoa fgetgrent fgetpwent fgetspent getaliasbyname getaliasent gethostbyname2 getmntent getnetgrent getrpcbyname getrpcbynumber getrpcent getspent getspnam getutent getutid getutline initstate jrand48 lcong48 nrand48 qecvt qfcvt random seed48 setstate sgetspent srand48 srandom tmpnam

I started looking into each function. For erand48 there is a erand48_r function in glibc, and the former does indeed seem to use a global variable. However, as far as I can tell from the POSIX specification, erand48 should be thread safe. So I filed a glibc bug about it. The same concern may hold for jrand48, lcong48, nrand48, seed48, and srand48.

I noticed that initstate, random, setstate, and srandom are defined by latest POSIX, but not mentioned as a thread-unsafe functions. Possibly a bug in the POSIX specification?

I also noticed that I had missed to include tmpnam even though it is mentioned separately in the POSIX link.

The rest of the functions are not documented by POSIX, and presumably thread unsafe (although I didn’t read the man page or source code for each of them).

In the end, I ended up adding several new functions to check for. The latest script is always available from:

http://git.savannah.gnu.org/cgit/gsasl.git/tree/tests/threadsafety

So, finally, did the updated script catch any use of thread-unsafe functions in GNU SASL? Nope.

In the previous part, I explained the basic concepts behind Iliad Applications and Widgets, through the simple counter example. This part will show how to use Magritte to automatically build views and editors with data validation.

read more

Hi again,

it took me some time today with big support from Nicolas, to figure out how to using an own version of a session.

And before you run into the same mistake than me, I would like to decribe the really simple steps to use an own Session for your Iliad-Applications.

I made some errors in reasoning, which was my problem at the end. But here's how a session could be subclassed and used.

read more

If you are used to having one class per file, package descriptions tend to get a bit unwieldy. Take a look at Iliad's Core/package.xml, as an example. What you see is a lot of typing, some of it, gasp, even repeated. Let's DRY this up a bit.

read more

Hi!

Just a short example of the #show:onAnswer: method of Iliad.

You can call an additional web-page in Iliad and continue afterwards, if the user ends the work on that page, in the same web-page, where you started the call to this page without wild tricks...

So I created a new page for the I forgot my password case for the login dialog.

read more

Hello again.

The weekend ends and I used today, to get a bit deeper into Iliad.

I created the login-dialog, which shows you, that if you open it again, the same data apears again that you already typed in and I used the session, to store a switch, if the user is logged in.

So, the first thing I did, was to overwrite the Application initialize method, to initialize the new switch, which I want to save into the session.

initialize [
    super initialize.
    self session preferenceAt: #userLoggedIn put: false.
]

read more

Hi Guys,

  Here are the highlights of the changes in the GNU toolchain over the last month:

  * There is a problem/feature with ELF based versions of the ARM port
    of gas.  If a binary value is inserted into a code section (via a
    .word pseudo op for example), then it is marked as being data.
    This means that when objdump disassembles it for example, the
    binary value will not be displayed as instruction, but rather as a
    hexadecimal constant.  This behaviour is deliberate.  Binary
    values in code sections are usually jump tables or constant pools
    and they should not be decoded.

    Sometimes however it is desirable to be able to insert a binary
    value and have it be treated as an instruction.  A patch to create
    a new pseudo-op .iword as rejected as being too simplistic, but a
    more a complicated patch is being worked upon.  In the meantime
    however objdump has been fixed so that if a file is disassembled
    using the -D (or --disassemble-all) command line switch then the
    data values will be disassembled.


  * Work continues on support for the new STT_GNU_IFUNC symbol type.
    Essentially this adds the ability for the run-time system to
    programatically choose a function to satisfy a call into a dynamic
    library. So for example if a program contained this piece of code:

      int num_cpus = get_num_cpus ();

    and gen_num_cpus was a dynamic library function which returns the
    number of CPUs available on the current system.  In a normal
    library gen_num_cpus might be coded like this:

      int
      get_num_cpus (void)
      {
        return syscall_num_cpus ();
      }

    Where syscall_num_cpus is a (made up) system call.  The problem
    with this version is that it has to make the system call each time
    it is invoked.  This could be fixed by caching the result:

      int
      get_num_cpus (void)
      {
        static int cached_num_cpus = 0;
        if (cached_num_cpus == 0)
          cached_num_cpus = syscall_num_cpus ();
        return cached_num_cpus;
      }

    Which is better, but it is still less efficient that this version
    which makes use of the STT_GNU_IFUNC functionality:
   
      int one_cpu (void) { return 1; }
      int two_cpus (void) { return 2; }
      int four_cpus (void) { return 4; }

      typedef int (* int_func)(void);

      int_func get_num_cpus (void) __attribute__((ifunc));
 
      int_func
      get_num_cpus (void)
      {
        switch (syscall_num_cpus ())
        {
        case 1: return one_cpu;
        case 2: return two_cpus;
        case 4: return four_cpus;
        }
      }

    So the first time that get_num_cpus is called the loader will
    invoke the real get_num_cpus function.  This returns a function
    pointer however which is then used to replace get_num_cpus in the
    dynamic library's lookup table.  Then the function pointer is
    invoked to generate the value to return to the user.s code.  From
    now on however calls to get_num_cpus will be short circuited to
    the much simpler non-system call using versions, making for an
    even after response.

    All of this functionality is still under development at the
    moment, but it should prove useful once it is ready for prime
    time.
   

  * Half-Precision Floating Point.

    On ARM targets, GCC supports half-precision (16-bit) floating
    point via the __fp16 type.  You must enable this type explicitly
    with the -mfp16-format command-line option in order to use it.

    ARM supports two incompatible representations for half-precision
    floating-point values.  You must choose one of the representations
    and use it consistently in your program.

    Specifying -mfp16-format=ieee selects the IEEE 754-2008 format.
    This format can represent normalised values in the range of 2^-14
    to 65504.  There are 11 bits of significand precision,
    approximately 3 decimal digits.

    Specifying -mfp16-format=alternative selects the ARM alternative
    format.  This representation is similar to the IEEE format, but
    does not support infinities or NaNs.  Instead, the range of
    exponents is extended, so that this format can represent
    normalised values in the range of 2^-14 to 131008.

    The __fp16 type is a storage format only.  For purposes of
    arithmetic and other operations, __fp16 values in C or C++
    expressions are automatically promoted to float.  In addition,
    you cannot declare a function with a return value or parameters
    of type __fp16.

    Note that conversions from double to __fp16 involve an
    intermediate conversion to float.  Because of rounding, this can
    sometimes produce a different result than a direct conversion.

    ARM provides hardware support for conversions between __fp16 and
    float values as an extension to VFP and NEON (Advanced SIMD).
    GCC generates code using the instructions provided by this
    extension if you compile with the options -mfpu=neon-fp16
    -mfloat-abi=softfp, in addition to the -mfp16-format option to
    select a half-precision format. 

    Language-level support for the __fp16 data type is
    independent of whether GCC generates code using hardware
    floating-point instructions.  In cases where hardware support is
    not specified, GCC implements conversions between __fp16 and
    float values as library calls.

   
  * A new warning flag has been added to GCC: -Wjump-misses-init.

    This produces a Warning message if a goto statement or a switch
    statement jumps forward across the initialisation of a variable,
    or jumps backward to a label after the variable has been
    initialised.  This only warns about variables which are
    initialised when they are declared.  This warning is only
    supported for C and Objective C; in C++ this sort of branch is an
    error in any case.

    -Wjump-misses-init is included in -Wall and -Wc++-compat.


  * A new command line option has been added to GCC to allow the
    automatic comparison of code generation with and without debugging
    enabled: -fcompare-debug[=<opts>]
   
    What this option does is to tell GCC that if no error occurs
    during compilation, run the compiler a second time, adding <opts>
    to the command line.  Then dump the final internal representation
    in both compilations, and print an error if they differ.

    If the equal sign is omitted, the default option -gtoggle is
    used.  This option turns off generation of debug info, if leaving
    out this option would have generated it, or turn it on at level 2
    otherwise.

Cheers
  Nick

Iliad comes with several examples: the seaside-like counter, a simple blog using Magritte, and a todo list application.

I'll try to explain the basics of Iliad through those examples. I will start with the counter example because it is the simplest one and it will look familiar to Seaside users.

In the following it is assumed that Iliad is correctly installed.

Elements and Widgets

To use Iliad, you need to understand two important parts of the framework: Widgets and Elements.

read more

The source is now maintained in a Git repository. See https://savannah.gnu.org/git/?group=libiconv for details. The CVS repository is now out-of-date.

The source is now maintained in a Git repository. See https://savannah.gnu.org/git/?group=libsigsegv for details. The CVS repository is now out-of-date.

The source is now maintained in a Git repository. See https://savannah.gnu.org/git/?group=gperf for details. The CVS repository is now out-of-date.

Hi again.

Now I want you to show, how to use the subclassed Iliad.Application class as a real dispatcher.

First, I will create a menu-class, that our web-pages has a seperate menu. And this menu is the same on every page, I created an extra class for that.

read more

Hi!

The last one and a half week, I was playing with seaside, but now, Nicolas Petton introduced a new web-development framework which is called Iliad http://smalltalk.gnu.org/blog/nico/iliad-new-lightweight-web-framework-gnu-smalltalk that seems so interesting, that I decided to try it out for a new web application, which is currently in a planned status.

And because the documentation and howtos for Iliad is currently not widely accessible, I decided to write a bit about my expiriences.

read more

http://www.freedink.org/screenshots/eeepc-701.jpg

...and the people rejoiced.

Now everybody can get a piece of gnupod by running

This creates a gnupod sub directory with the current
bleeding edge development version of gnupod.

One more
autoconf configure make install

and you've got it installed.

Please uninstall a previous version of gnupod if you installed
it from your distribution's packet management system (in Ubuntu
and Debian the packet is called "gnupod-tools") as the paths for
installing perl modules might differ and you may end up with two
installed versions of some gnupod modules and executables.

A new lightweight web framework for GNU Smalltalk named Iliad is available for download.

svn co http://bioskop.fr/svn/gst/iliad/trunk iliad

We're working on this framework since a few months now, and we just wanted to share the code with others.

For our personal needs, we wanted to have the following features in the framework:

• standalone stateful widgets
• REST-like applications
• simple API
• easy to setup and deploy (no complicated configuration step)

read more

GNU License to V3 and Automake cleanup

The Letux 400 has a wide-VGA screen, 800x480 pixels. Bright, crisp and well readable, but sure an uncommon format. 800x600 was common for laptops for a long time.
How do standard desktop applications fare on the Netbook? Some just don't fit, but there are several which just work and allow to have a small workspace available.

The first screenshot shows that albeit crammed, the Workspace is fine. The panel with the folders could be closed to gain even more space. Behind you can see the Terminal application. Sure, only one can be seen at a time, but it is enough to work.

Then we have the AddressManager showing up in all its glory. Fits tight but fits. A really useful application on a Netbook!






The last image shows the Vespucci browser on the Letux. Works fine.

Note: Screenshots are from applications actually running on the Letux 400, not mock-ups.

http://ftp.zresearch.com/pub/freeipmi/0.7.10/

0.7.10 - 06/16/09
-----------------
o In all tools, properly deal with workaround flags when specifying
different devices than what workaround flags are intended for.
o In bmc-config, fix bug setting volatile vs. non-volatile settings.
o Fix in-band probing priority ordering to fix issues with machines
that support multiple drivers.
o In ipmi-sensors and ipmimonitoring, continue reading sensors after a
"command response cannot be provided" error.
o Add additional workaround handling into Sun 2.0 workaround.
o In ipmimonitoring, fix sunbmc driver interface bug.
o In ipmiconsole, consider IPMICONSOLE_ERR_BMC_IMPLEMENTATION a
non-fatal error.
o Update workaround documentation with additional motherboards.