Re: problems with Starr Office and Debian 2.0


>>>> I have tried to install Starr Office on my desk, but it refuses
>>>> to work until now. When I try to use it, it sends the message
>>>> "Starr Office needs to be run in millions of dollars mode, only
>>>> 256 available". I also fear that this might be a hoaxed version,
>>>> because it keeps popping up dirty pictures.
>>>>
>>>> I tried to run dselect, but it answered : "Starr Office is not
>>>> compatible with package democracy. Remove democracy (y/n) ?"
>>>
>>> On my system this works very well.
>>> You should continue as follows:
>>>
>>> Remove democracy (y/n)? y
>>> Add package hunt (y/n)? y
>>> Which hunt? y
>>>
>>> Create new kernel image (y/n)? y
>>> Image name? clinton.
>>>
>>> You must boot clinton for the changes
>>> to take effect.
>>>
>>
>> Thanks for your hints; Starr Office works now, but I'm afraid this
>> could have raised some other problems.
>>
>> Namely, the new kernel, clinton, has a strange behaviour: whenever
>> Starr Office tries to read its process memory, it sends KILL signals
>> to other applications. I was trying to run a 'little chemist factory'
>> tutorial application, for example, when it crashed down with no
>> explanation. See the output of 'top' afterwards :
>>
>>   PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %SAT   TIME COMMAND
>>   180 root       8   0  8548 8548  1504 S       0  1.1 66.6   1:57 clinton
>>  1018 pascal     3   0   772  772   580 R       0  0.3  1.2   0:00 starr
>>     1 root       0   0   396  396   336 S       0  0.0  0.6   0:10 init
>> (etc.)
>>
>> I tried to deinstall clinton but it refuses to get deinstalled.
>> What should I do?
>
> I am afraid this is a problem with the Starr Office
> process server. The system calls employed by Starr Office for
> accessing protected  memory segments do not appear to me to
> be compatible with due process access rules as laid down in
> POSIX.democ.1 (working document).
>
> I managed to trace the problem to a modified system call:
> sub_poena(2), which implements protected memory access
> requests. The source is as follows:
>
> int sub_poena(struct tripp_t *buf) {
>
> #ifdef CONFIG_NO_SCRUPLES
>     volatile int __suspend_habeas_corpus=TRUE;
> #else
>     volatile int __suspend_habeas_corpus=FALSE;
> #endif
>
>     int silence = __lewinsky_didnt_talk();
>
>     if(__suspend_habeas_corpus==FALSE || silence) {
>         buf = (tripp_t *) NULL;
>         return(-1);
>     } else {
>         buf = __lewinsky_talks();
>         return(0);
>     }
>
> }
>
>
> You could try compiling with CONFIG_NO_SCRUPLES=1.
> But I am not sanguine about the results. The code looks very ugly,
> and too case specific for a system call. I think the trouble may well
> run deeper.
>
> The only alternative I can offer you is to try downloading the
> BETA version of Starr Chamber:
>
>  http://www.kstarr.gov/pub/linux/for.all.you.damn.liberals/starr-chamber-1.0.0pre2.tgz
>
> According to the README file it is based on Starr Office and
> has much faster execution times, because interprocess
> communication is based on global shared memory. I don't know
> for sure. I managed to compile it, on my test bed machine, but on
> rebooting was somewhat surprised to see that the usual boot
> prompt: LILO, had been replaced by
>
> ARBEIT MACHT FREI:
>
> Hitting tab gave me two choices:
>
> fascism    windows
>
> On booting fascism a shell appeared to be started. There was a
> prompt:
>
> heil#
>
> I tried many of the usual shell commands, but almost nothing
> would work. I always got heil: ???? command not found.
>
> top gave me:
>
>    44 root       2   0   516  516   372 R       0  1.1  0.2   0:00 top
>     1 root       0   0   348  348   276 S       0  0.0  0.1   0:18 init
>    48 root       2   0    14   14     8 R       0  0.0  0.0   0.08 heil
>
> I thought I remembered something, and tried:
>
> heil# sieg
> heil# sieg
> heil# sieg
> heil#
>
> It seems to work, but I don't know what it is doing.
> Uptime now gives me:
>
> 12:43am  up 0 days,  0:15,  1 users,  load average: 4.04, 4.06, 3.97
>
> I hope you can shed some light on this, because I
> don't think I can get much farther at the moment.
> I think I will have to stick to _ack_ MS Office for
> now.

Looks like some NSDAP to me (an old assembly-level OS which
was completely abandoned after having ruined a considerable number
of systems; all it could do properly was de-assembling). I can't
figure why somedy would want to re-use it today. If you want more
information, we have a small club of nostalgics here in North East
Germany.

As a matter of fact I found traces of something similar on some
old man pages here on my machine. After having identified the library
of system calls used by the Starr package (public_confession and
public_humiliation), I tried find some reference in the manpages:

europe# man -k public_confession public_humiliation
inquisition, fascism, stalinism (3)   - Routines to take control of all
processes
europe#

The manpages do mention these system calls, e.g. :

STALINISM(3)       C LIBRARY FUNCTIONS       STALINISM(3)
 
NAME
     public_confession,                       public_humiliation,
     mediatic_assassination -  put a process under all others

SYNOPSIS
     #include 
 
     struct pid_t *public_confession(name)
     char *name;

     struct pid_t *public_humiliation(name)
     char *name;

(...) 
 
DESCRIPTION
     public_confession, public_humiliation  and mediatic_assassi-
     nation can be used  one by one  or together  to take command
     over a given process,  put it below all other processes, and
     make it ready to receive any kind of INTERRUPT signal (...)

etc.

But the manpages are completely out of date, and the packages have
been removed for a long time :

europe# ls stalinism
total 15
drwxr-xr-x  2 root      512 Oct  3 1990 ./
drwxr-sr-x 18 root     2048 Sep 23 1998 ../
-rw-r--r--  1 root        0 Nov  9 1989 timestamp
-rw-r--r--  1 root       92 Oct  3 1990 README
europe# cat README
 
stalinism:
 
- NK, 02/14/56: OS obsolete, image archived
- HK, 10/03/90: archive destroyed
 
europe# 

By the way, as you guessed, these systems were not at the least
POSIX.democ.1 compliant. Why the newest version of a system designed
to run on a purportedly performing machine (USA station 10) should
unbury these old ugly patches of code is yet to understand.


Date: Su, 27 September 1998 18:00:02 +0200
From: Pascal Vaillant et al. <h1461b2d@hppool7.rz.hu-berlin.de>
Newsgroups: de.comp.linux.misc, de.comp.linux.x