mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

323K
active users

#jehanne

0 posts0 participants0 posts today
Replied in thread

@fsniper

Uhm.. I thought it was, and in fact forked #Jehanne to further simplify and make it more powerful: jehanne.h--k.it/

But infact I was wrong: Plan9 is still inheritelly elitist. Even its best incarnation, #9front, while a superb enginering achievement, builds on top of a broken history.

People should not need to learn grep, sed or awk to manipulate text files programmatically. Even just their names sounds arcane.

Furthermore the reason why people do not use Plan9 is rooted in the huge military investments that funded (and still funds) the broken alternatives through several companies (microsoft, ibm, sun, google...) and universities that spread the broken tools.

Spreading computing literacy for the masses is never been a goal of such actors.

Today the cultural #hegemony that was built this way, makes it unthinkable to further explore the vast design space that could actually gives us a safer foundation for modern computing.

That is also why "the Plan9 lesson" must ignore the economical and geo-political forces that lead to its (percieved) failure.

And why you didn't mention an European os like #Oberon instead.

Jehanne Operating SystemJehanne is moving!Jehanne - Jehanne is moving!

@ekaitz_zarraga

To be honest it took an incredible amount of time (to me) to enrich libposix enough for newlib to support GCC need.

Yet #Jehanne deviated from #Plan9 enough to make the port slightly simpler as Jehanne support ELF binaries while Plan 9 and #9front only run (custom) a.out binaries.

And to be honest, I have no idea on how to change the output binary format of GCC.

@theruran

@miriamgreco

Certo, questa è una ottima obbiezione.

Quando ho iniziato il porting di #GCC su #Jehanne, non immaginavo assolutamente che avrebbe di lì a poco abbandonato il progetto #GNU. Né ero consapevole che la Steering Committee [1] fosse composta in ampia prevalenza da dipendenti di aziende con contratti miliardari con il DoD americano (9 membri su 13).

Perché potessi accorgermene è stato necessario che togliessero #RMS su richiesta di un dipendente di #Facebook.

D'altronde la questione è seria e ben nota sin dai tempi di "Reflections on Trusting Trust" [2] e molti ci stanno lavorando da anni, attaccando il problema da vari fronti.

Detto questo rassegnarsi, collettivamente, al fatalismo del "eh ma tanto è tutto insicuro" è ciò che lascia molti esposti ad innumerevoli vulnerabilità che potrebbero essere facilmente evitate.

____

[1] gcc.gnu.org/steering.html

[2] cs.cmu.edu/~rdriley/487/papers

@tassoman @loweel @fatualux

gcc.gnu.orgGCC steering committee - GNU Project

@ekaitz_zarraga Not an expert at all, but GCC made me crazy when I had to port it to #Jehanne.

Also, since the removal of #RMS from the #GCC SteeringCommittee I realized that its development is mostly in the hand of large US corporations with large DoD military contracts.

I mean, what can go wrong?

I started to port Jehanne to TCC but it's not that easy (in particular for the kernel parts) and after some days on that I moved to other stuffs. For now.

GCC is a cool tool(set).

Unfortunately, they forgot (or betrayed) the #GNU in their name.

@yogthos

I wonder why processes are not green by default in operating systems.

In #Jehanne, for example, pids are a scarse resource: #Plan9 needs to be able to export /proc over 9P2000 and this means you can have only 2000 process running at any time because of limits in the protocol... (limits that for once I cannot recall exactly because of... #wine... sorry :-D).

For the rest, processes are pretty cheap in #Jehanne.

What's other OSes excuse?

@be

@ekaitz_zarraga

Makefiles fasten compilation.

GCC/binutils apart, compiling #Jehanne from scratch take 2 to 3 minutes. A whole operating system, including kernel, userspace programs and all.

When makefiles where invented compiling and linking a simple hello world used to take minutes, so it was rational to spend computing cycles to minimize the amount of compiled code keeping track of the modified files and their dependencies.

But is this still true today?

To be honest, I don't think so.

Today makefiles and similar tools are used to tame the huge complexity of big codebases, while the right think to do would be to avoid writing such big codebase from the beginning.

That's basically why I did't port neither gnu make nor plan9 mk to #Jehanne: I don't think we should still use them.

In other words, I would suggest you to use a simple lisp (or rc, or sh or... whatever) script to build your code instead of make and similar tools.

With posixly, I emulated a posix system on #jehanne with less than 2000 lines of C.

Now I'd like to draft something similar the other way around, emulating the few Jehanne syscalls in posix systems.

In theory, it should be "easy".

But I hate writing C on #posix.

I just spent 20 minutes contemplating a powerful (and totally unsafe) text template engine I wrote for automatic code generation in #Jehanne.

In 5 lines of #sed¹

I'm too overwhelmed by the power of sed, to ponder consequences.

____
¹ piped to #Plan9 rc

```
There are two orthogonal forces at work in the Squeak team [...] the incremental improvement plane (which #AlanKey calls the "pink" plane) and the paradigm shift (or "blue") plane. [...]

The forces in the pink plane have to do with making an ever-better Smalltalk-80 system [...]

The forces in the blue plane have to do with [...] an exquisite personal comuputing environment. [...]

One aspect is that things must stay small and simple enough that they remain comprehensible and accessible to a single person.
```
From web.archive.org/web/2005040606

I'm always amazed to see how ancient is the quest for #simplicity.

#Jehanne, #Wirth's #Oberon, #TempleOS, #Squeak... we are all looking for the same Holy Grail, dreaming the same dream but in a different way...

web.archive.orgWhere Squeak was headed...

@ekaitz_zarraga

Fantastic read.

I wish I had something like this to read a few years ago. Having always worked with x86_64, I didn't know about constant pools or veneers, but in fact they are clever tricks.

To be honest I'm not sure if like #JIT compliation.

On one hand, it makes clear that code is data and data is code, that is a good thing.

But on the other it means that at runtime you cannot mark all writable memory as No Execute, that is a valuable security feature (I do this by default in #Jehanne and there is no mmap there).

Obviously a JIT compiler could compile the program, save it into a ELF executable file and fork/exec/wait for it, but all the speedup would probably go with the context switches.

As an alternative (fantasticating of a homoiconic language to build an homogeneous OS) could be to turn the kernel itself into a JIT compiler.

This way, the both the readonly and executable permission of a script would just be preserved in the compiled memory, while allowing the kernel to write it.

Well just thinking aloud... you know...

Anyway, great read Ekaitz, thanks for sharing! You are becoming incredibly good at writing divulgative texts about #Informatics!

Compliments!

At times I feel hopeless for the future of our cybernetic world.

Can computing be fixed?

#9front is a great operating system... if you know (its own) C and its (great) userspace tools.

#Jehanne should be simpler (a toy so far, but even if complete it would stay simpler) but even if ignoring the huge amount of work wasted to port #GCC before it was turned to yet another weapon of #US imperialism, it still requires to learn a lot of glibberish.

Why in 2021 I have to explain my daughters what `grep` means? `cat`? `xargs`? `git`?¹

Why we still use cli arguments (argc, argv) instead of a proper and uniform command language pre-parsed by the kernel?

But the problem is deep.

At times, I despair. 😢

Because I see how this lead straight to a terrible dystopia for future generations.
But apparently, nobody care enough.
____

1) Don't get me wrong: I like these software a lot and use them extensively everyday, but they are tools designed to maximize the productivity of an élite of experts, not to empower casual programmers.

Replied in thread

@natecull

I'd say that most of current day software complexity is unneeded but it's always either accidental or actively pursued to gain one sort of artificial and undue power over people (reduced to "users") or another.

But both accidental and pursued complexity usually stem from underlying systems (hardware included) that do not provide orthogonal abstractions to build upon.

Imagine if you had to define circles on a plane but with non-orthogonal axes.

The simple x²+y²=r² would not work anymore and you'd have to invent the weirdest tricks to get a formula that works.

And anything you'd have to build on top of such formula would be even more complex.

So the pursuit for simplicity is first and foremost a pursuit for orthogonal axes that can effectively describe any computation (a space that is way more complex than a plane) in the simplest (but exahustive) possible way.

That was what I was looking with #Jehanne, but I'm still unhappy of it.
Not just because of the lack of time to work on it or because of plain (but very expensive) errors like GCC.

It's still too complex and arcane. 😥

Replied in thread

@natecull

I'm reasoning about this topic too.

I was wondering how to teach #Jehanne to my daughters (it's pretty simple compared to other OS) but it's still full of arcane words, with ugly syntax and weird semantics.

I'm pretty sure we should know better: what wrong assumptions arr poisoning the future of computing?
(Yeah, capitalism apart...)

Why we cannot even think simpler languages (and systems) without so much glibberish?

All programming languages use weird syntax, one way or another, to "maximize programmer productivity" (for some definition of it, if any) with multiple equivalent ways to express a computation.

All use complex type systems (as system F and derivatives) that most people cannot really understand.
Or they use complex runtime rules to counter-balance the lack of any type system.

All scripting languages use different syntaxes, all use different data format (converging to json, that sucks in many ways...), all have different command line switches...

We can do better for sure!