[Nix-dev] UI management (Was: Use Haskell for Shell Scripting)

[Michael Raskin]

>> Also, I sometimes tend to use closing unneeded windows as a way of
>> keeping track of short-term TODO list.
>
>I think there doesn't have to be semantic difference between closing a
>window and dropping it into a virtual drawer.  Your short-term to-dos
>would be elsewhere.

Well, I do have layered virtual drawers, but I have a habit of listing
the contents of everything launched from time to time.

Also, I like transparency in computations. Fresh start does have some
benefits from transparency point of view, and I have no idea how many
applications will complain if I decide to reboot while they are in the
sigstopped state.

>>> Unfortunately it entails removing systemd from the top of the process
>>> tree, which is a lot of work for a single person, but I'm highly
>>> motivated.  By the way, this is not my usual systemd hatred.  There
>>> are technical reasons to remove it from the top.
>>
>> Will you share it already? I do have a bootable systemd-less system
>> based on NixPkgs, and would probably contribute some service
>> definitions to the thing you develop.
>
>I'm very close to a bootable system.  Allow me to arrive there first,
>then we can compare and exchange ideas and code.  I will definitely let
>you know, because I'm interested in your way of doing it.
>
>Publishing a working prototype works better for me.

Heh. Mine is in my dotfiles repository linked from wiki.

Actually, my idea of the core boot sequence is contrary to your goals:
for core system I think in terms "I want to easily run recovery after
a USB boot and I want to describe my system in terms of its imperative
recovery procedure started from initramfs". It is likely that my service
management will likely also be like that; but I knew you were doing 
something for staring a NixPkgs-like-structured service repository and
so decided to get by with a minimum set of daemons until I can choose to
just write service definitions for your approach or start my own set
of definitions.

>>> [...] In the same way I always thought that our filesystem concept is
>>> wrong.  There is no inherent reason to have "files in folders".  I
>>> believe that a disk should act more like a giant mutable variable.
>>
>> At some point I saw RelFS and tried to use it for tagging files. Then
>> I hit its limitations and written my own QueryFS. Now I use it for
>> many things, but not for file tagging because hierarchical structure
>> made it simpler for me just to think in terms of hierarchy.
>>
>> So directory structure was a good idea for file storage, in my
>> opinion.
>
>Sure, it is great for some things, but terrible for others.  The point
>is that we don't get a choice.  Everything is designed around the "files
>in directories" notion.  That's why an sqlite database is completely
>opaque from the point of view of the operating system.  You need special
>tools with a special UI to inspect databases.

Hm, want to try out QueryFS? 

Real code from my config:

```
mkdir "fresh-no-deferred" do 
	for msg in "select account || '-' || file_basename, file_path, account, id from emails where fresh"
    		symlink $msg[0] $msg[1] on-remove "update emails set fresh = null where id = ${msg[3]};"
done

mkdir "outbox" do
  grouped-for account in "select distinct account from emails" do
    symlink $account[0] "/home/raskin/queries/commands/backing-store/email/${account[0]}/outbox/"
  done
done

```

One of QueryFS modules represents SQL database as a filesystem tree
specified by queries, then you can use whatever tools you use on files.

It is also typical for me to do things like 
```
ls ~/queries/email/attribs/from-like/%ertesx%/*/*
```

>>> My vision for software in general is what I call "organic software".
>>> [...]
>>> How can we write software that isn't moronware?  Good design and
>>> proper responses to exceptional circumstances can make our programs
>>> faster, more responsive, more flexible and less like untrained
>>> animals.  They make our programs *dependable* and in the end
>>> *trustworthy*, because we can feed tasks to our program and focus on
>>> other things or even just pick up a cup of coffee, because we *know*
>>> that it will do its best to complete as much as possible without our
>>> intervention."
>>
>> Well, this vision is what I consider one of the problems of modern
>> software development. It would be yet another tangent, though; do you
>> want to go in that direction?
>>
>> In short, I want (but don't yet know how to achieve in some cases)
>> predictable transparent tools usable as IA in Engelbart speak, not
>> DWIM helpers with wannabe-AI.
>>
>> I want tools that can be easily transparently wrapped to try to do as
>> much as possible or to stop at the first problem.
>
>I find this topic very interesting.  I believe it needs to be discussed,
>but this mailing list is probably not the right place to do it.  For
>lack of a better place, feel free to write me off-list, if you would
>like to discuss this further.

OK. Well, are you OK with me inviting some other people from the 
beginning? Not sure who of them will join.