[Oberon] Software Tracking Project

Wed Jan 31 15:32:58 CET 2018

Jörg,
I would say Windows is, like most systems, build up from "layers". Where
each layer has its API. And so it becomes a big wall / building. Oberon is
radically different in my view. In that it is "organic"; just like nature.
So you can only love it or leave it. The web structure is at the same time
its radical strength and its big weakness

I am very much a spiderweb man, but a while back I did an interesting
exercise: Make a proper API between layers of software. It took some
thinking but I did come up with a system in Ada that only took 4 machine
cycles per call. (gcc with the optimizer on).
For small embedded systems I will still often use a spiderweb structure.
But force of circumstance makes proper, documented layers very attractive.

The other thing I note is that the traces of Edsger Dijkstra are all over
Oberon. NW never forgot what he learned there!
(How to get on a bicycle from A to B, but much faster than in a motorcar ;)

The innercore is the only Oberon part that has a proper layer-API.

j.

On Wed, Jan 31, 2018 at 9:15 AM, Jörg <joerg.straube at iaeth.ch> wrote:

> Jan
>
> Yes and no. You are right that it is a spiderweb of modules. But isn’t
> Windows that as well?
> From a practical standpoint, the four modules of the inner core (Kernel,
> FileDir, Files, Modules) are different from the rest.
> These four modules can not be unloaded dynamically. If you want to change
> something there you have to link them statically into the boot area.
>
> br
> Jörg
>
> Am 31.01.2018 um 07:28 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
>
> Wojciech,
> 1. Any Oberon implementation or application coming from a university has
> been by definition a research project. Just to see how far the boundaries
> could be pushed in a certain direction.
> So I guess that is perpendicular on standardised easy portable
> application software.
>
> 2. The boundary between OS and application is non existent in Oberon. It
> is rather a spiderweb of modules. The web will over time extend itself into
> any direction depending on the need of the user / prograrmmer. So there is
> no OS API, but there are Module interfaces everywhere for you to use if you
> find a use for them.
>
> 3. So it follows that you hardly can port Modules, but you certainly can
> port brilliant ideas from the one system into any other.
>
> ("To be led up the garden-path" is an expression that describes Oberon
> very well.)
>
> j.
>
>
> On Wed, Jan 31, 2018 at 4:01 AM, Skulski, Wojciech <
> skulski at pas.rochester.edu> wrote:
>
>> Joerg:
>>
>>   I agree with you that both V4 and S3 are not applications. I also agree
>> that Oberon System is unique in that the distinction is blurry. Not "a
>> little", but very much.
>>
>> Looking at Windows, MS Word is an application. Under Linux, nano is an
>> application. Under Oberon System, is Edit an application or part of an OS?
>> On one hand, it is a wordprocessor. So it is an app. On the other hand, an
>> Element like Sisiphus is running inside Edit. So Edit is a framework which
>> is providing an API. So it looks like a part of an OS. Now we can start to
>> argue, which category Edit is belonging to.
>>
>> From a conventional Linux standpoint, it is fair to say that parts of the
>> kernel belong to the OS, while programs running in the user address space
>> are apps. This distinction does not apply to the classic Oberon, where
>> there is only one address space. We can say that everything is an
>> application, or everything is an OS. We can also say that command modules
>> are apps, while the imported modules are services. However, the top most
>> command modules can get imported into some even more topmost modules, in
>> principle ad infinitum. I am not sure, where to draw the boundary between
>> the OS and the apps, or between servers and clients. I am not sure if
>> trying to draw such a line is productive.
>>
>> My point was that both the ETH and V4 low level modules were
>> intentionally quite similar to the original Oberon System modules. If so
>> then it should be possible to plant both the ETH and Linz module trees on a
>> common set of low level modules. It should also be possible to use ETH Edit
>> to host Elements and Dialogs. These are the most important parts of V4.
>>
>> In my opinion, the benefit would be to mend the rift which somehow
>> developed over the years between the two systems. I am not sure why the
>> rift has developed, but I suspect it was not beneficial to the community.
>>
>> W.
>> ________________________________________
>> From: Jörg [joerg.straube at iaeth.ch]
>> Sent: Tuesday, January 30, 2018 2:07 PM
>> To: Skulski, Wojciech; 'ETH Oberon and related systems'
>> Subject: RE: [Oberon] Software Tracking Project
>>
>> Wojtek
>>
>> V4 and S3 are OSes not applications, although this differentiation is a
>> little blurry in Oberon.
>> In today's world, one could call your idea of running an OS on top of
>> another OS virtualization.
>> Or one could take the idea of Linux, with a common kernel and different OS
>> flavors on top.
>>
>> In the operating system A2 (aka Bluebottle, aka AOS, written in
>> ActiveOberon) it's possible to start the legacy Oberon OS as separate task
>> in A2.
>>
>> So, your idea is well possible (in SW almost everything is possible :-)
>> but
>> needs quite some work.
>>
>> br
>> Jörg
>>
>> -----Original Message-----
>> From: Skulski, Wojciech [mailto:skulski at pas.rochester.edu]
>> Sent: Tuesday, January 30, 2018 5:23 PM
>> To: joerg.straube at iaeth.ch; ETH Oberon and related systems
>> <oberon at lists.inf.ethz.ch>
>> Subject: RE: [Oberon] Software Tracking Project
>>
>> Joerg:
>>
>>   do not you think that V4 and S3 can coexist on top of the same lower
>> level
>> layer? You could possibly launch either one or the other, or perhaps even
>> both, though it would make little sense.
>>
>> Merging the two could possibly end the rift which was dividing the
>> community
>> for reasons which were hard to grasp from a distance.
>>
>> W.
>> ________________________________________
>> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg
>> [joerg.straube at iaeth.ch]
>> Sent: Tuesday, January 30, 2018 9:35 AM
>> To: 'ETH Oberon and related systems'
>> Subject: Re: [Oberon] Software Tracking Project
>>
>> Hi
>>
>> Isn't this request like: I would like to see Linux and Android merged?
>> They are similar: same language, same compiler (perhaps even same CPU,
>> same
>> Kernel). But some of the APIs differ.
>>
>> br
>> Jörg
>>
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Treutwein Bernhard
>> Sent: Tuesday, January 30, 2018 2:35 PM
>> To: 'oberon at lists.inf.ethz.ch' <oberon at lists.inf.ethz.ch>
>> Subject: Re: [Oberon] Software Tracking Project
>>
>> >I would like to see V4 and ETH System merged.
>>
>> I think this is an excellent idea.
>>
>> Maybe UV4 would be a good starting point:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourcef
>> orge.net_project
>> s_oberon_&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZh
>> HbOU&r=uUiA_zLpw
>> aGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcOmlMrjf7C4
>> H8TsPIxpkqLljZCQ
>> 9wns&s=mdw5q5iL8zSP_3yaqyCEu0f1Qh2Sr6YOoIrvCsDEIrc&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_projects_oberon_&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcOmlMrjf7C4H8TsPIxpkqLljZCQ9wns&s=mdw5q5iL8zSP_3yaqyCEu0f1Qh2Sr6YOoIrvCsDEIrc&e=>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourcef
>> orge.net_p_obero
>> n_wiki_Home_&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaq
>> QZhHbOU&r=uUiA_z
>> LpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcOmlMrjf
>> 7C4H8TsPIxpkqLlj
>> ZCQ9wns&s=BCyGCZty5GWxx7gh6dZCSwsvaF--hofW42_t0BG1DSM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_oberon_wiki_Home_&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcOmlMrjf7C4H8TsPIxpkqLljZCQ9wns&s=BCyGCZty5GWxx7gh6dZCSwsvaF--hofW42_t0BG1DSM&e=>
>>
>> --
>>   Bernhard
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.i
>> nf.ethz.ch_mailm
>> an_listinfo_oberon&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9
>> EI2eaqQZhHbOU&r=
>> uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcO
>> mlMrjf7C4H8TsPIx
>> pkqLljZCQ9wns&s=coZmt0X5ozfRQnjkEK2IiCurdoMPAHxU6iMuKVZ0Om8&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcOmlMrjf7C4H8TsPIxpkqLljZCQ9wns&s=coZmt0X5ozfRQnjkEK2IiCurdoMPAHxU6iMuKVZ0Om8&e=>
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.i
>> nf.ethz.ch_mailm
>> an_listinfo_oberon&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9
>> EI2eaqQZhHbOU&r=
>> uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcO
>> mlMrjf7C4H8TsPIx
>> pkqLljZCQ9wns&s=coZmt0X5ozfRQnjkEK2IiCurdoMPAHxU6iMuKVZ0Om8&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=nqDS5CyXZIYdcOmlMrjf7C4H8TsPIxpkqLljZCQ9wns&s=coZmt0X5ozfRQnjkEK2IiCurdoMPAHxU6iMuKVZ0Om8&e=>
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180131/28b1c1e9/attachment.html>