Re: [Infotropique] temporary log location (was: Re: notice)

Delete this message

Reply to this message
Author: Nils Gillmann
To: Nils Gillmann via Infotropique
New-Topics: [Infotropique] more research
Subject: Re: [Infotropique] temporary log location (was: Re: notice)
Change of plans:

I am cleaning up the layout and structure of my old blog,
so I might write occasionally in there about infotropique related work.

I won't do this all the time or regular - that won't work out.

Things are still moving with regards to code, which is part of
the reason why I don't feel comfortable writing about it at
the moment. What I would write and what I have written already
is a snapshot in time. I want to do it this way, but maybe I
learned down the road that "this way" is not going to work.
I've drawn enough conclusions already, and there's many more

This is as much research into dissecting projects as it is work on
writing one. It won't end up as just research, because I am using
this for myself already throughout the entire process. Certain
features (looking at gnunet) will take a long time, but we'll
get there eventually.
I ditched the "ROADMAP" for plant, it's just a "TODO" file I need to
push as soon as it is done.

ports (distro packages):
Roughly 2000 packages done, 7000 or so to go. I wished guix would have
made it possible to match package definitions per empty line
separation.. I have a perl script for separation in cases like that.

I'm also thinking about what I call "frozen DAGs" (not DOGs).. This is
motivated by experiences I had too often (but which took very long to
materialize). Let's say you must install a package released 16 years
ago and it just won't compile with todays' software. The case with
guix is "just use an older commit". What I want is to be able to
just install the software as-is. Or drop into an environment with
it, because it (hopefully) is only for when I read and work with
old textbook examples that I need such old versions. Being able
to get the DAG of the package at this specific time ("version")
can be useful. It is more work, and it is more work to get to a
specification and practical way to provide this.
This won't mean that the software I want to provide will be
outdated, you'd opt-in the past and otherwise move along with
the rolling present.

My package specification will also differ a tiny bit, but that's
up to tests. codewise the changes can still be manually applied
to guix with some adjustments. Remember: the idea was to be good
neighbors and have this separate namespace (I'm working towards)
for not disrupting project goals.

There's more, but felt like just commenting these extra paragraphs