Re: [Infotropique] early May update

Delete this message

Reply to this message
Author: Nils Gillmann
Date:  
To: Nils Gillmann via Infotropique
Subject: Re: [Infotropique] early May update
Nils Gillmann via Infotropique transcribed 6.1K bytes:
> Hi,
>
> I made (some) (considerable amount of) progress.
>
> So here's a very short update, more details will be in the draft design paper
> soon'ish:


I made the already public repository public via webbrowser now:
https://git.infotropique.org/infotropique/design-paper/

It's currently copyrighted the way it is for 2 reasons:

1. I don't want any modifications unless discussed at this point in the design and proto-typing process
2. I haven't found a satisfying license for the content.

Also, I would not want anyone to copy or contribute to the document for there are many fixes
that still need to be applied. Half of that repository only makes sense with papernotes
and contents of my brain, but maybe it's interesting for you to follow before you get
"the real thing" to try out.

> I am currently creating 'plant', an adoption of Guix that stays license-compatible
> with GNU Guix (GPL3). It is stripped down, packages, services and other parts come
> in their own repositories. I wasn't able to implement infotropique OS with simply
> just Guix, the ability to modify Guix has limits and it's easier to roll your own.
> Since I'm trying out things that won't fit into Guix goals, but also things that
> are in Guix' scope (like GNUnet FS distribution), the creation of plant based
> on Guix was logical after almost 3 years.
> Some people would call it a fork, but I only call forks projects that do not
> commit their changes back.
>
> So what the heck is infotropique OS now anyway? Guile as a language in the family
> of the lisp languages gives us the ability to inherit code and replace it. This
> is the biggest part of the "magic". We take GuixSD, split some its modules apart[0],
> add our own defaults, construct a logic of templates, and so on. It would be better
> if I provided a tree view on how all depends on each other. This exists already in
> a repository, but I'm not happy with the state of the representation.
>
> It has reached a state where I've given it the name "An UNIX-like sonic screwdriver
> Operating System framework".
>
> The templates are intended to be written in Guile at the moment, for the first
> versions. I'm still experimenting with possibilities there. However, we want to
> support other languages later on as an addition. We had some initial ideas, but
> this is a project on its own with lexers, parsers and so forth. Basically take
> a file written in your favorite, supported, INPUT language, process it with
> COMMAND and get a file that is usable with what is equivalent to the operating
> system understood by "guix system".
>
> Since we're going all-in, incrementally, on building other Operating Systems
> with this approach this also means other userlands, other kernels. Other init
> managers will be difficult but I wouldn't call it impossible until someone
> tries it. Other package managers. Support for searching DISTFILES as provided by
> some Operating Systems (that build from source) in a well known location, as well
> as convenience functions to do the same for infotropique OS (grab distfiles).
>
> We will have some build servers provided, but the emphasis is on decentralized,
> distributed computing. That means:
> 1. For now I'm a student with a student's budget ;)
> 2. No way to accept large amounts of donations that would enable build servers
>    even if I don't expect to be hit with 20+ TB / month.
> 2.1 As soons as there's a tech demo, I'll talk to one of the non-profit umbrella orgs
>     for donations and more.
> 3. We really don't want to rely on the old web, but also know that we need a fallback
>    (for possible bootstrapping etc) and that experimenting with GNUnet FS is a long
>    journey to the goal (GNUnet FS distribution of binary substitutes and more).
> 4. You are encouraged to run and provide local or even global buildservers.

>
> More details on this will also follow later.
>
>
> I have run into a problem with my 'pkgs' repository, but I will try to send more
> emails now.
> Where those of you reading the list with previous Guix packaging experience is this:
>
> ports is intended to be the equivalent of "ports", "pkgsrc" and other sources
> in the BSD land. It's far from finished in the specification here, but commits
> already happen. ports exists in 2 forms. ports-wip and ports. ports-wip is
> briefly described in this *VERY* incomplete preview version of the website:
>
> https://www2.infotropique.org/software/ports-wip/index.html
>
> alternatively, just run:
>
> mkdir infotropique
> git pull https://git.infotropique.org/git/infotropique/ports-wip.git
>
> There might be some code left that is AGPL3 licensed, but I'm in the process
> of relicensing it to GPL3.
>
> Now, where I need is help is moving the whole batch of (gnu packages *) into
> the (ports-wip $category $name $name) structure and from there into
> (ports $category $name $name) [or (pkgs $category $name $name) for core packages]
> once the packages are in good shape.
>
>
> You can send patches via email to this list, mbox formated via the git format-patch
> option.
> Once I have finished the new website + the design draft paper and more of my
> intentions and how it all interacts with each other is clear to you, I hope
> some people will be interested enough to maintain ports or other parts.
>
>
> I do have tasks that can be worked on independent from packaging, so if you
> want to help me out send me a message and we can talk about it. Eventually
> I should just publish the design_doc repository URL which holds a good amount
> of information about jobs to be done, etc.
>
>
> What else did I work on?
> I moved back and forth between layouts, dropped some and am reconsidering the
> use of an original bmake+mk approach I had planned (isn't going to happen for
> now). I started "porting" (so far not really porting) OpenBSD software. First
> with the intention to replace the default core-utils and other software, now
> it's different. I might still make OpenBSD's core tools a default later on
> but for now there are some people I need to talk to and a really crappy solution
> to pledge() which I need to fix.
> I could say the first design is almost finalized, I am just not very motivated
> to finish writing the paper.
> I've started unbundling and repackaging some firmware for the firmware-package
> type to be used by the firmware_tool script (or whatever its ideas end up in).
>
> I probably forgot to mention a large amount of things I did work on.
>
>
> 0: The pkgs, ports, and ports-wip collection grew from a base of around 500+
>    packages I commited to Guix and around 70 guix branches which I had to be
>    commited to Guix (containing +/- 200 packages).
>    They also came from a growing, problematic amount of GUIX_PACKAGE_PATH
>    repositories (think of them as smarter versions of Gentoo overlays). So my
>    packages were already outside, just not with the intention to alter formats
>    and experiment towards new distribution ways.
>    The repositories (pkgs, ports, ports-wip) are far from finished.