New Oberon System 3 Release 2.1
Author Message
New Oberon System 3 Release 2.1

Quote:
> What is NEW in this release?

The question is, on afterthought, justified and deserves an answer on our part.

1 - The obvious (and not stated reason) is that many corrections have been made
to the now one and a half year old release 2.0. During this time, errors
detected by laborious, attentive, attentioned and co-operative users have been
collected and progressively corrected. On several occasions, collections of modules
have been cleaned up, partly re-written, and sometimes entirely re-written.
The Internet suite (Net tools) for instance has undergone many changes.

We make use of this excellent opportunity to warmly thank all those of you
who have contributed to improve Oberon System 3, which has now matured
considerably and is more robust.

2 - The not too obvious new element in the announcement text is the emergence
of Native Oberon System 3. Indeed, this may not seem new to those of you who have
already been using and testing the beta version of limited distribution.
Native is fully native (total control of the machine), completely 32-bit.
system faster.
- Disk controller: IDE/EIDE/ESDI or Adapatec 1520 SCSI
- Display controller: ET4000, ET4000-W32, S3-805, S3-924, GD54xx, V7 Mirage
- Network controller: 3COM Etherlink III
- Sound: Sounblaster 16, SB Pro, SB AWE32
- CD: ATAPI/IDE, Mitsumi CD

However, drivers are progressively being developed: without
these the bare system is of little value. More such drivers are always welcome:
who is volunteering?

3 - This release is distributed with the source code, with the exception of a small
Native kernel. This represents a change of policy. Users may now scrutinize the code and
on the FTP site: in the interest of the user community it is not allowed to modify
module interfaces. If a change is unavoidable (nothing is perfect or immutable),
contact the developer team.

4 - The Windows implementation now used Omega code (formerly OMI).
The Oberon compiler generates Slim Binaries per default. Slim binaries are
a new form of object files that contain a portable description of a module's
contents and are therefore portable and can be used on different Oberon Systems.
This idea was developed by M. Franz who implemented it together with
T. Kistler on Macintosh (68K and PowerPC) and Intel-based PC.
The Omega code is currently being ported to Native Oberon too.

5 - Gadgets have been updated: the PrintMsg and DisplayMsg have been merged.

6 - New system extensions have come into existence, some of them replacing
existing ones. "Old" extensions are progressively frozen into archive files found
in the APPS sub-directory. These packages must be installed after installing
the system itself. Columbus, a new gadget inspection tool for example, now
completely replaces the Inspector and the DetailInspector.
As another example, public and private
libraries are managed by yet another Columbus component which replaces
Libraries.Panel. The Windows implementation calls it Libraries2.Panel,
but that is a glitch which will soon disappear.

---------------------
The team of the Institute of Computer Systems of ETH Zurich

--- start of oberon mail ---

B
F
d
5T]=\^=_PL\_E^b]\SU^Ym=W;8AKH]KI1YH;KIM;8KKH9KIK8MO;8Y;J;;8MkK_;8O[K;;83[K9c
^
UM\d]\T5TR=_PT]QE\_E^Ym]e9;1IHY;M;[KYKJ]KII983;MP_e]UU\P<<L\_]U_5^UE^QU^Ye^U
5TeM^UE^c5TX153KhHO;KIKI7;MHH8LUkK?[L;kLWKJ]KIIKN1iHO3\<M98OZK1iL;[M;[L3;K1i
\
=_PD^U]UgE^YU^d]<I983[KL^_]]UU^Y]]UM^P\\^U>UKIIKN:70jb6BEdFV9e]d]\be]UU^PL^e
=]d]\P4U>]\d9MOkKIkLC98=kKU;8C[KW;M3[K7KI19J3kL1IMM;I;[L?kKMKI1IK3[K8J3[K?KI
f
1
6

BWYaf6fl2Bgn6WKI;KK1YK;kMBgg2Bjl=04Tg5]_54H33;KUKI3;Ic;85KIHMWKJMkI1IHM;IBgb

Quote:
c

YI[;KIKN1YK3;MC3A9MO;M3;K1iHO[Kl]\5T_e\PT>\]QM\X=]^]\YTUPL<K;LIKIYKIIKN1i<UI
F
8
1I;19ACkLG;87kKM3bfb:GM2bTBdRnbRVDRFdGLZ4=YPl]b5T1U\Q5^QU^UM\P<VeDV4TCMXC=Y
a
j
I
[
Quote:
>1iMC;MAkK[;MK8MAKIWKI19MAKI1YH3[L;;8WKNW;MfVYM>O[IbVdU^\]\Pd^QU]e]\^4T=m]b]

<
]cYL;;KHIVfiT\YM>UCaHIl^YU>19MAKI>ggFGi>fb2banFbFFF2bkV6PU5_S9LYKJO[K113;8WK
S
^iM>ga:gjBgdjfdZgb2BjR67kK4TQ9IK8J;;KQ;89KI5KM?kIC[K?c887Ci:7VFghLckLF6;;NY
4
e
\i]Q]m]T]>2bdPV=\S]\ceUP<YV5TQ5TS1<=FWQe^_=]T=\RU]U5TXd]_U^X=]^m<CkL2gb:GcFf
>
P
;
F
U
[
3
H
F
c
dgjVceUPDT?U]TETP\\hU>0662Gil<0VWVE^_E_Ue]P<]^U>6Fi>FdVFkFVV=]\QVm]ee]T]QYe
]
g

f
=
F
i
1W;8OS5UZ85TJ]^b=]S5]=\Q=0\$

Sat, 27 Feb 1999 03:00:00 GMT
New Oberon System 3 Release 2.1

Quote:

> 2 - The not too obvious new element in the announcement text is
> the emergence of Native Oberon System 3. [...]
> Native is fully native (total control of the machine), completely 32-bit.
> system faster.
> [....]
> 3 - This release is distributed with the source code, with the exception
> of a small Native kernel. This represents a change of policy.

Please do not take the following as an undue criticism. I am impressed
and amazed by your efforts, and I am equally impressed and amazed
by somewhat similar efforts at Linz, which seem to be taking place in
parallel to yours. I am thus sometimes asking myself: what is similar,
and what is different between the two? Obviously, there must be some
difference in implementation, and perhaps some deeper difference of
the design philosophy. I would be interested in reading a thorough
review paper, comparing lessons drawn from both projects. Is there
any such paper available? A recent "archetypal aspects..." by J.Gutknecht
concentrated almost entirely on System-3 and its perspectives, but
it left out a thorough comparison between System-3 and current generation
of V4 from Linz. IMHO, while there is certainly no match between ETH
System-3 and (now finished) ETH V4, there is a certain parallel between
System-3 and the "new generation" Linz V4. Are there any interesting
lessons drawn from a comparison of the two? Any particular areas,
where one is superior over the other, or vice versa for that matter?

Wojtek

Sat, 27 Feb 1999 03:00:00 GMT
New Oberon System 3 Release 2.1

Some time ago I asked if the comparison of Linz V4 and ETH System-3
was available. Somewhat surprisingly, it is not available. I received
a few e-mails saying it would be of interest, but nobody seems to have
enough time to write such an article. A prospective author needs to
know both systems in-depth, or else a few authors need to team up their
knowledge. I wonder if c.l.o participants can post some reflections
concerning key areas. It might also be worthwile to include Oberon/F
in the comparison, and also other systems/environments. Since it is not
likely that any single person knows all systems, the only feasible approach
is to collect contributions and maybe write a sort of a summary later.

I myself do not feel expert enough to coordinate such a comparison
or even a part thereof, but since I asked the question, let me offer
my ftp area ftp://nuchem.nsrl.rochester.edu/incoming/COMPARE/
if somebody feels like writing a contribution. Either myself or
someone else can attempt a summary later on. I am offering this
ftp directory since I will be away from my desk for about a month
and I will not be able to monitor and save c.l.o. postings.

with the aim of summarizing lessons drawn from following different approaches
to solve common problems, as asked a few days ago:

Quote:
> I would be interested in reading a thorough
> review paper, comparing lessons drawn from both projects. Is there
> any such paper available? A recent "archetypal aspects..." by J.Gutknecht
> concentrated almost entirely on System-3 and its perspectives, but
> it left out a thorough comparison between System-3 and current generation
> of V4 from Linz. IMHO, while there is certainly no match between ETH
> System-3 and (now finished) ETH V4, there is a certain parallel between
> System-3 and the "new generation" Linz V4. Are there any interesting
> lessons drawn from a comparison of the two? Any particular areas,
> where one is superior over the other, or vice versa for that matter?

My own list of key areas of comparison:

1. System features
- System-wide communication bus
- persistent object management
- efficiency of both above
- robustness of both above
- robustness of Native PC Oberon may deserve a special comment

2. Text-oriented applications
- support packages such as Gadgets, Dialogs, others: how complete?
- differences and similarities in design philosophy, tradeoffs and penalties
- how compatible/incompatible among themselves
- how easy to develop an application using these libraries?

3. Graphical applications
- same questions as above
Note: It seems to me one should consider text and graphical apps separately

4. Support for external world: database formats, graphical formats,
WWW-formats, whatever sticks out of the closed Oberon System box.

5. High-performance computing
- parallel processing
- network distributed computing
- numerics ( :-) )

6. Programmer productivity features
- using Elements, Watson, special editors such as XE to enchance
programmer productivity.
Note: this is necessarily a subjective part and I believe it should
occupy a minor part of the comparison. I believe one should
not praise/condemn a particular system only because
it offers/does not offer a particular productivity applett.
On the other hand, some comparison in this area seems interesting.

7. End-user packages such as wordprocessors, graphical packages, other
Note: I for one would like to know how good, complete and robust
are packages such as Leda for end-user work. Even though
we c.l.o are primarily interested in architectural issues,
it is still nice to know how well these were used
to develop actual shrink-wrapped products.

8. Interfacing with external libraries
Note: I know this is more an underlying OS issue, but still someone
may want to comment.

9. Any other areas one finds interesting.

Wojtek

Sun, 07 Mar 1999 03:00:00 GMT
New Oberon System 3 Release 2.1

Quote:
>> What is NEW in this release?

>3 - This release is distributed with the source code, with the exception
>of a small Native kernel. This represents a change of policy. Users may
>now scrutinize the code and help debugging and correcting system extensions.
>Please refer to the license.txt on the FTP site: in the interest of the
>user community it is not allowed to modify module interfaces. If a change
>is unavoidable (nothing is perfect or immutable), contact the developer
>team.

Dear team of the Institute of Computer Systems of ETH Zurich,

Is this a one-off arrangement, or does it represent a change in policy?
I noticed that the new release for Macintosh (1 November) does *not*
contain the source code.

Cordially,

Luc

Mon, 26 Apr 1999 03:00:00 GMT

 Page 1 of 1 [ 6 post ]

Relevant Pages