Re: [9fans] There is no fork

[Lucio De Re]

On 2/13/18, s...@9front.org  wrote:
>>
>> That said, I deem it unfortunate that there isn't a drive to
>> consolidate the various flavours of Plan 9 into a single offering, or
>> at least identify and discuss the differences and provide for the
>> choices from a single source (pun intended).
>
> Have you considered providing this service?
>
> sl
>
Touche'. I'd certainly like to contribute, but herding the Plan 9 cats
is beyond any managerial skills I may have.

Actually, I think one needs to resist the temptation to write any code
until the underlying design, specially of the perimeter API/ABI has
been discussed to death. I know I find that extremely hard to do at
all times.

My own nature is one of cooperative development, but it is not the
current fashion and perhaps it suppresses the essential creative
spirit. Thankfully, I seem to have reached an  age when I no longer
believe it is up to me to make things happen: there are so many eager,
younger minds with so much more to offer.

Lucio.

Re: [9fans] There is no fork

[sl]

> On 2/10/18, Benjamin Huntsman  wrote:
>> Just curious as to the state of the union.  Is 9front pretty much the de
>> facto "official" Plan 9 these days, or does anyone still use or maintain any
>> of the following:
> 
> I'm with David (legacy), nearly all the way.
> 
> That said, I deem it unfortunate that there isn't a drive to
> consolidate the various flavours of Plan 9 into a single offering, or
> at least identify and discuss the differences and provide for the
> choices from a single source (pun intended).

Have you considered providing this service?

sl

Re: [9fans] There is no fork

[Benjamin Huntsman]

This has been a fascinating thread.

I was kind of surprised that no one came out and said "yes, 9front all the 
way", nor did anyone say they had 9atom working.
Ideally, I'd like to have 9atom on VMware, but since it isn't maintained 
anymore either, 9front looks like the way to go.  9legacy might be truer to the 
original, but it doesn't work on VMware out of the box.  I know VMware isn't 
the favorite virtualization platform of everyone on here, but there's a lot of 
production on VMware...

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 17:13 GMT+01:00  :
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
>> That's the marketing blurb, I've heard it a thousand times before. [...]
>> So, for the last 10-12 years, maybe more, mountains of software have been 
>> produced on the assumption that it will be easy to find and install all 
>> their dependencies. That's only true for users of big 'distributions' which 
>> have lots of people, a large professional team or many contributors, to 
>> create and maintain the package tree.
>
> From a different point of view, the problem is also that the developers,
> using some developing tools (for example the GNU automake and autoconf),
> don't really know what they are using, or, since "GNU is not Unix",
> don't verify that their code is POSIX compliant (and to what level etc.;
> when I began using Unix by discovering Linux, I remember reading a book
> explaining that for C programming, when linking, you will add always
> the Glib library because "there are probably things you will need in
> it!"...).

I might be proven wrong, but I doubt that developers not understanding
their tools can build useful software.

Or, if the software they build is useful, it may get enough traction
to be rewritten after learning from mistakes.

I cannot fix people linking glib just because it exists. Just like I
cannot fix people writing a new JS framework/library/wtf. In general I
cannot fix people.
But, whenever I have to hack on something that depends on cmake,
instead of autotools, I know it will take twice as much to get the
task done.

>
> The amount of dependencies of some packages is simply appaling. (One
> example is TeXlive, because using some macros involve using an amount
> not necessarily kwown of "other" macros, for a lot of people it is
> simpler to "take it all" just in order not to "fail"; and this is
> when you need only a part of it that you discover that this "all"
> depends on things that you do not have on your system---a C++
> compiler and so on).

My bet is that, when Jehanne will be the one true OS everybody will
hate, people will not install macro packages, but mount a remote file
server through a  caching file server, including the C++ compiler.
Now before going crazy about security, consider that the shell running
TeXlive will only see a limited namespace, containing only the file it
has to work with and nothing else.

But this is not going to happen soon... People do not hate Javascript
enough, yet... :-D


Giacomo

Re: [9fans] There is no fork

[Steve Simon]

rob’s sam editor for X11 circa 1993 was a revelation for me. 

beautifully written and trivial to port to a dozen different platforms. a 
salutatory lesson to all.

autotools is horrid, though, fgb’s config script can often get foreign stuff to 
build. if you want to import code rather than just port it then my mkmk (mkfile 
generator) can help.

-Steve


> On 12 Feb 2018, at 16:13, tlaro...@polynum.com wrote:
> 
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
 On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
 linux-style package managers and bsd-style port trees facilitate and 
 enable coupling.
>>> 
>>> What a package manager really facilitate is version management.
>>> That is when you want to use/update a software at version X that depends on 
>>> libraries at version Y and Z.
>> 
>> That's the marketing blurb, I've heard it a thousand times before. [...]
>> So, for the last 10-12 years, maybe more, mountains of software have been 
>> produced on the assumption that it will be easy to find and install all 
>> their dependencies. That's only true for users of big 'distributions' which 
>> have lots of people, a large professional team or many contributors, to 
>> create and maintain the package tree.
> 
> From a different point of view, the problem is also that the developers,
> using some developing tools (for example the GNU automake and autoconf),
> don't really know what they are using, or, since "GNU is not Unix",
> don't verify that their code is POSIX compliant (and to what level etc.;
> when I began using Unix by discovering Linux, I remember reading a book
> explaining that for C programming, when linking, you will add always 
> the Glib library because "there are probably things you will need in
> it!"...).
> 
> The amount of dependencies of some packages is simply appaling. (One
> example is TeXlive, because using some macros involve using an amount
> not necessarily kwown of "other" macros, for a lot of people it is
> simpler to "take it all" just in order not to "fail"; and this is
> when you need only a part of it that you discover that this "all"
> depends on things that you do not have on your system---a C++
> compiler and so on).
> 
> -- 
>Thierry Laronde 
> http://www.kergis.com/
>   http://www.sbfa.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 

Re: [9fans] There is no fork

[tlaronde]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
> > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
>>> linux-style package managers and bsd-style port trees facilitate and enable 
>>> coupling.
>>
>> What a package manager really facilitate is version management.
>> That is when you want to use/update a software at version X that depends on 
>> libraries at version Y and Z.
>
> That's the marketing blurb, I've heard it a thousand times before. [...]
> So, for the last 10-12 years, maybe more, mountains of software have been 
> produced on the assumption that it will be easy to find and install all their 
> dependencies. That's only true for users of big 'distributions' which have 
> lots of people, a large professional team or many contributors, to create and 
> maintain the package tree.

>From a different point of view, the problem is also that the developers,
using some developing tools (for example the GNU automake and autoconf),
don't really know what they are using, or, since "GNU is not Unix",
don't verify that their code is POSIX compliant (and to what level etc.;
when I began using Unix by discovering Linux, I remember reading a book
explaining that for C programming, when linking, you will add always 
the Glib library because "there are probably things you will need in
it!"...).

The amount of dependencies of some packages is simply appaling. (One
example is TeXlive, because using some macros involve using an amount
not necessarily kwown of "other" macros, for a lot of people it is
simpler to "take it all" just in order not to "fail"; and this is
when you need only a part of it that you discover that this "all"
depends on things that you do not have on your system---a C++
compiler and so on).

-- 
Thierry Laronde 
 http://www.kergis.com/
   http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] There is no fork

[Chris McGee]

Thanks everyone. This thread has been a fascinating read for me.

Chris

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
> On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
>>> linux-style package managers and bsd-style port trees facilitate and enable 
>>> coupling.
>>
>> What a package manager really facilitate is version management.
>> That is when you want to use/update a software at version X that depends on 
>> libraries at version Y and Z.
>
> That's the marketing blurb, I've heard it a thousand times before. [...]
> So, for the last 10-12 years, maybe more, mountains of software have been 
> produced on the assumption that it will be easy to find and install all their 
> dependencies. That's only true for users of big 'distributions' which have 
> lots of people, a large professional team or many contributors, to create and 
> maintain the package tree.

True, but part of cost here is the complexity of the package manager.

>
>> The use of dynamic linking make this complex and cumbersome. Also a single 
>> filesystem hierarchy does not help
>
> Dynamic linking is probably the largest, most visible part of the problem, 
> but your saying this makes me think you haven't tried to compile very much 
> software -- certainly not on anything other than Debian or a similarly large 
> distro where, these days, you can get all the dependencies by pasting a line 
> the package author provided.

Well, I use Debian from Potato, but I've got my headaches with
pinning, backports, conflicts and broken upgrades.

Also, I think I've compiled my amount of software.
As a rather recent example, automating the compilation of the gcc
cross-compiler for Jehanne took its time since I had to compile and
install locally specific versions of autotools and binutils, without
forcing users to install texinfo.

I think I have an idea of what I'm doing, but I'm pretty open to
suggestions and criticisms: the best time for them is now, since I did
no real work on the matter.

> The painful ones particularly included dependencies for otherwise nice 
> programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos!
> [...]
> Thinking about this stuff makes me bitter, so I ought to stop now. It's 
> possible the things you want won't intersect with the things which caused me 
> trouble, but I think I have considerable reason for pessimism.

Well, obviously I'm naive enough to try to do something better! :-D

I think the problem is really tied to the nature of software
development... just because bugs are.

To my money you have an alternative:
- to be mostly self contained (as Plan 9/9front does), which is the
optimal solution to the problem
- to leverage outside softwares which evolve outside your control

Both solution have to cope with bugs:
- in Plan 9/9front you fix them
- in other systems you can still fix them but if you contribute back
the fix things turn "complex"...

Versioning, dependency trees (or sometime even graphs) and all these
monsters comes from this problem.

The self-contained approach is way more efficient... and simpler. Thus
it's very attractive to me.

But, my insight is that these monsters need to be faced, and defeated. :-)
Since you can't stop (or control) the evolution of software you do not
code yourself, there's no way to avoid versioning and using that
software.

But again my insight is that using static linking and namespaces,
packages can be way easier to maintain.


Still, I'd really like to know details about your concerns and your
painful experiences, since they could put me on the right track.



> I'd like to think there are enough people who don't want to be tied up in all 
> this pain to create some semblance of a software ecosystem outside it, but 
> when you consider that few people want to start from the ground up, and how 
> poettering and fd.o have their tentacles in crucial parts of the 
> posix-related ecosystem, it looks impossible.

Well, actually there are several hobby OSes that do not support posix
and package management.
(and some have interesting ideas too...)

But the problem with your approach is not just posix compliance.


For example, in Jehanne most tools you are used in Plan 9 are not part
of the core system.

For example, porting Plan 9/9front games to Jehanne is trivial (could
even be automated), but their changes should not cause the core system
to "evolve".

So the solution, again, is installing them as packages, with their own
versions. And this is the reason why there are no games in Jehanne:
they are waiting for a package manager.


The problem, as always, is to get the axes right.


An OS core system should evolve as a whole.
But since its usefulness depend on the amount of things people can do
with it, it should also be able to run exogenous software.


The Plan9/9front approach is optimal because it's perfectly useful
exactly to the people it want to be useful to.


Jehanne is useless. It's just a toy, aka a research 

Re: [9fans] ReMarkable!

[hiro]

your features sound neat, but they don't solve the problem of inputing
longer text.

Re: [9fans] ReMarkable!

[Bakul Shah]

On Feb 12, 2018, at 5:44 AM, hiro <23h...@gmail.com> wrote:
> 
> i might even run acme
> for a day for you. but with mouse and keyboard, i would never replace
> them with touch input.

Ah, but where’s the challenge in that?!

Some ideas to give a sense of what I’m thinking: drawing a line across
the screen vertically or horizontally to create two windows. Scratch it
out to close a window. Lasso a filename and drag it in a window tag bar
to open it there. Select a word and type ? to search. Such ideas would
have to be iterated over and tried out to find out what works.

Re: [9fans] ReMarkable!

[hiro]

we have two of these devices here in the office and my coworker loves
to use it for making notes and sketches.

i like the device's size for reading pdfs with annoying layouts, and i
prefer this screen technology to the glaring normal displays i get to
use otherwise.
replace my main monitor with one of these and i might even run acme
for a day for you. but with mouse and keyboard, i would never replace
them with touch input.

for sketches i'll keep on using paper and pen :)

Re: [9fans] There is no fork

[Lucio De Re]

On 2/12/18, Ethan Grammatikidis  wrote:
> [ a neat rant I agree almost to the pixel with... ]

I (mostly) manage a (very small) team of younger programmers who only
really know Linux, and then the Debian or Ubuntu distros, almost
exclusively. My sentiments and Ethan's seem very similar.

I still compile all the NetBSD packages I install, sometimes at some
cost to my sanity, fully realising that my colleagues could not even
successfully install the necessary tools to do the same on Linux (I am
pressing them to use Go, it gives me an edge where they are unlikely
to  overtake my deeper knowledge - so that gets installed from
source).

I do believe the gospel of minimalism is hitting home though, because
I refuse to act as first line of defence, so by the time I'm willing
to help, their Humpty-Dumpty world lies shattered at our feet for me
to put together again. Not often enough, sadly.

Unfortunately, the difference between their "production" world and the
Plan 9 ecosystem is simply too big, they can't conceive of such
simplicity being viable and I can understand that. But there's a hint
of envy, even though there is so much Plan 9 does not support.

The message, of course, is that one should not need hundreds of
thousands of files deployed on a workstation and that there should be
packages to remove software, rather than install it. Who knows, that
may happen, one day.

Lucio.

[9fans] ReMarkable!

[Bakul Shah]

https://gizmodo.com/the-remarkable-e-ink-tablet-is-way-too-good-for-its-sof-1822612517

People like writing on its plastic screen much better than on iPadPro
with its glass screen. Even with a thin plastic protector screen on
the iPad, it does not fell like writing on paper - the screen doesn’t
“give” enough. ReMarkable’s simple interface and the fact it runs
Linux made me think it would make for an interesting experiment in
writing a touch/gesture based editor for handwritten text. On the
 iPad GoodNotes does a very good job of editing within text but lacks
other tools. Come to think of it, even regular text input on iPad isn’t
as fast as with a real keyboard and editing commands. A pen/stylus
opens up new possibilities. I put this out here hoping that one of you
gets inspired enough to write a “pen-based-acme” (in the sense of
having just the “right” editor primitives, but not specific commands).

Re: [9fans] software archaeology

[Lucio De Re]

On 2/12/18, Ethan Grammatikidis  wrote:
> On Mon, Feb 12, 2018, at 11:04 AM, Steve Simon wrote:
>>
>>
>>
>
>
> I almost want this for my wall. :)
>
>
>
Maybe the artwork can be released?

I'd pay money for a poster...

Lucio.

Re: [9fans] software archaeology

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 11:04 AM, Steve Simon wrote:
>  
>  
>  


I almost want this for my wall. :)

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
>> linux-style package managers and bsd-style port trees facilitate and enable 
>> coupling.
> 
> What a package manager really facilitate is version management.
> That is when you want to use/update a software at version X that depends on 
> libraries at version Y and Z.

That's the marketing blurb, I've heard it a thousand times before. It's almost 
as bad as the things git fanatics say. It's taking one small part of the 
problem and pretending that this is the important thing which it makes easier. 
The problem I'm talking about is not one small corner of the situation, it's an 
effect of the reason package managers exist. They exist to make it easy to find 
and install dependencies. So, for the last 10-12 years, maybe more, mountains 
of software have been produced on the assumption that it will be easy to find 
and install all their dependencies. That's only true for users of big 
'distributions' which have lots of people, a large professional team or many 
contributors, to create and maintain the package tree.

> The use of dynamic linking make this complex and cumbersome. Also a single 
> filesystem hierarchy does not help

Dynamic linking is probably the largest, most visible part of the problem, but 
your saying this makes me think you haven't tried to compile very much software 
-- certainly not on anything other than Debian or a similarly large distro 
where, these days, you can get all the dependencies by pasting a line the 
package author provided. I have. Many packages weren't bad, but some were 
downright painful. The painful ones particularly included dependencies for 
otherwise nice programs. I'd get 2 or 3 levels down the dependency tree, and 
suddenly, chaos! I always want to cite freedesktop.org who seemed to be leaders 
in making it painful, but it's been 9.5 years since i had anything to do with 
compiling their stuff so I won't say too much.

> Plan 9 does not suffer of this problems because of several reasons:
> - it does not support dynamic linking
> - it is developed as a whole "batteries included"
> - few external packages have being ported to it, and people who use them know 
> their stuff very well
> 
> Plan 9 (and 9atom/9front) is developed and distributed as "a whole system": 
> there is conceptually only one version for all the software and libraries 
> included.
> 
> Technically it's the simplest and optimal solution to the versioning problem.
> Indeed 9front uses a single mercurial repository (which is a versioning 
> system) to manage both development and system updates.
> 
> 
> I carefully considered this approach for Jehanne too, but decided to try an 
> alternative design.
> Obviously no dynamic linking will ever land in Jehanne, but I want to enable 
> more external softwares to run on it.

Two or more years ago, a #cat-v regular found insurmountable difficulties 
running X statically linked with musl. Oh look, there's freedesktop.org again. 
I think it was Red Hat who had found a way to make it so hard, their name 
certainly came up. It's not the first time Red Hat has caused problems, they 
were doing it in the first release following their IPO, in 1998. My Bourne 
shell skills were almost permanently harmed by attempting to learn from their 
massively complex init scripts at the time. Looking back, the message is clear: 
"You can't cope with this on your own. Buy a support contract now!" Oh look, 
Red Hat pay Lennart Poettering's wages... and now everything depends on dbus 
and systemd! Supercomputer software which has no reason to do anything but 
compute its stuff now requires systemd's logger.

Thinking about this stuff makes me bitter, so I ought to stop now. It's 
possible the things you want won't intersect with the things which caused me 
trouble, but I think I have considerable reason for pessimism. I'd like to 
think there are enough people who don't want to be tied up in all this pain to 
create some semblance of a software ecosystem outside it, but when you consider 
that few people want to start from the ground up, and how poettering and fd.o 
have their tentacles in crucial parts of the posix-related ecosystem, it looks 
impossible.

I'm now sticking to systems which have nothing to do with posix, at least for 
hobby use. I have a couple of android devices, but almost no desire to program 
them directly. I've even got qemu on one of them. I do use an emulator with a 
2-level dependency, but if it had taken more than a tiny bit of effort to set 
up, i would have dropped it and used something else.

--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] software archaeology

[Steve Simon]

<<< image/jpeg: EXCLUDED >>>

Re: [9fans] software archaeology

[Steve Simon]

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :

> linux-style package managers and bsd-style port trees facilitate and
> enable coupling.
>
>
What a package manager really facilitate is version management.

That is when you want to use/update a software at version X that depends on
libraries at version Y and Z.
The use of dynamic linking make this complex and cumbersome. Also a single
filesystem hierarchy does not help

Plan 9 does not suffer of this problems because of several reasons:
- it does not support dynamic linking
- it is developed as a whole "batteries included"
- few external packages have being ported to it, and people who use them
know their stuff very well


Plan 9 (and 9atom/9front) is developed and distributed as "a whole system":
there is conceptually only one version for all the software and libraries
included.


Technically it's the simplest and optimal solution to the versioning
problem.

Indeed 9front uses a single mercurial repository (which is a versioning
system) to manage both development and system updates.


I carefully considered this approach for Jehanne too, but decided to try an
alternative design.

Obviously no dynamic linking will ever land in Jehanne, but I want to
enable more external softwares to run on it.
This way I reduce the responsibilities of the project and size it to the
stable workforce (that is: I, me and myself).

It might seem counter intuitive to say that using gcc instead of ken-c
simplify the system.
It's true that it increase the complexity of the system during compilation,
but it reduce the scope of Jehanne itself.


So Jehanne's core system can follow the whole system development approach
of Plan 9, but it's a minimal system and an included package manager will
allow the installation of other useful software.


The problem is that the perfect package manager does not yet exists for the
Jehanne design.
Probably the nearest thing is BSD's pkgsrc, but it doesn't get advantage of
namespaces.

And which language should I use to code an alternative?
Probably C. But I wonder if a more high level language could make the job
easier without increasing too much the project scope.
So far candidates alternatives (that I still need time to evaluate deeply)
are Wirth's Oberon-07 and Obi's Myrddin.


Giacomo