Re: [Infotropique] intermediate update

Delete this message

Reply to this message
Author: Catonano
Date:  
To: ng0, infotropique
Subject: Re: [Infotropique] intermediate update
2018-01-27 21:29 GMT+01:00 ng0 via Infotropique <infotropique@???>
:
[...]

>
> >> Replying to their maintainer is on my list of things to do,
> >
> >
> > replying about what ?
>
> Woops, sorry. I was sick and assuming a bit too much omniscient
> narrator perspective on your side :)
> Basically I've been in touch with GNUhealth about fixing up the
> Build system and then left (never commited anything) because I
> needed to figure out more details in infotropique OS and knew
> GNUhealth could benefit from this. The conversation included
> mentioning of Live systems etc.
>


[...]


> isn't it a python build system already ? Which build system are hey using
> ?
>
> No, last time I've looked at it it was one of those wild Shell
> script interactive installers that should just go away and spent
> their digital retirement in some remote realm of the internet
> never to be found again.
>



I took a look at their script

it does mainly 2 things:

1) it installs a set of Tryton modules
2) it patches the Trytond server

both these things can be done with the Guix machinery

As for point 1, we could define a so called meta-package that has the
Tryton modules as propagated inputs
As for point 2, we could define a new Trytond package and patch the sources
in a ad hoc phase

Probably we could merge these 2 packages into one package only

One that patches the trytond source AND has the required modules as
propagated inputs

I can't do this immediately, as I am trying to lessen my income burden in
the meantime

But I won't certainly forget about this


> >
> > That frighthens me because it's terribly difficult to support
>
> Technically also impossible, as GuixSD is just too resource
> hungry at this point. I'm playing (better: experimenting) with
> some ideas outside of the scope of GuixSD.
> I know what should definitely be infotropique collective /
> infotropique OS work, and what has an open question mark for
> commercial support or 'needs funding to get realized' etc. This
> reads way more scary than it is. TL;DR is alt libc isn't going to
> happen any time soon and if it will there's many things to
> consider. Similar to my testing with GuixSD on Xen as domU and
> dom0... Experiments have been the starting point for all this,
> doesn't have to mean that we'll be including all kernels, libcs
> etc I play with to get more familiar with abstract parts of Guix.
>


Ok, I'm glad to see that you can be pragmatic too ;-)


>
> But,...
>
> > But it could be an important use case for GNUHealth, because GNUHealth
> aims
> > at Africa, Latin America and Asia, that is not westerrn countries
> >
> > So having thight resources is a concern
>
> ...this is a reason to look into exploring libcs later on.
> The challenge is to keep the code base modular enough not to
> diverge too much from Guix.
>
> And as someone put it, availability of binary substitutes is
> another aspect. Is it affordable to keep the amount of data per
> architecture per build round per world (or reduced subset of it)
> around until we have GNUnet FS?
> If not, can it be affordable for community-shared substitutes
> servers that can be accessed
> locally? I don't know what my personal substitutes server
> consumes in almost 24/7 operation for just one architecture. It's
> definitely not the best hardware for the job.
>


mmm you're righth. My idea is that an embedded image should contain Tryton
ONLY
This should lessen the problem


> > They boost the ability to run it on Raspberry Pis, for example, with
> > OpenSUSE
>
> Yes, Falcón mentioned openSuSe.. didn't know about RPis for
> them. interesting.
>
> > It's important for them
> >
> > Also, in a recent GNUHealth conference one of their speakers envisioned a
> > system to identify health care services receivers with distributely
> > generated uniqe IDs, so when they travel to foreign countries they still
> > could access their medical records.
> >
> > This could make health care assistance easier in target countries AND it
> > could make health care serrvices cheaper even in western couuntries
>
> What are their target countries? So far I assumed they think
> globally, which I assume (knowing almost nothing about Health IT)
> is very difficult with many standards. From your comments I
> assume countries in the Southern Americas use their software?
>


For example, they held this demonstration (in 2011 !)
http://blog.gnusolidario.org/2011/10/gnu-health-at-hospital-italiano-buenos.html

more recently, this one
https://twitter.com/gnulinuxec/status/955222093821554689

Also, Africa
https://twitter.com/gnulims/status/946550180840648704


> At least here in Italy, the software they use has no small part in the
> > corruption, waste, lack of accountability that plague the system
> >
> > I think the GNUHealth community is on an interesting front
>
> Yup. Although it is certainly within the scope of our project
> just a branch which doesn't really fit into the rest of the
> project but has its purpose. I just don't want to think about
> working on it for now.. but having something ready to go once the
> first framework prototype stands should be interesting nevertheless.
>


Alright. I'll stick around too


> >> So we have this new concept of flavors (in Fedora terms it would
> >> be called spins I think although not entirely accurate). I'll
> >> explain this in a separate email or post, but infotropique OS +
> >> GNU Health could be one alternative variant path including new
> >> flavors of it.
> >>
> >
> > yes, I know what spins are, that'd be wonderful
>
> ascii presentation would be easier, I'll give updating the new
> old website a try around the 15th. Meanwhile if I don't manage to
> make it look too terrible I can give emailing a draft via email
> about what Devan, and myself talked about at chaos congress.. and
> either scan the paper notes or type them in.
>
> It's probably better than the state of confusion I create here.
>


:-)



> >> Maybe flavor is not really good to describe it, but it was the
> >> first thing that stuck around for my own descriptions.
> >> infotropique is a word describing plants reaching out for
> >> information, connection etc (if there is any better explanation
> >> than the book I adapted (and changed) it from). So I thought the
> >> best would be to come up with something more plant-connected or
> >> mesh-related for terminology. It's not super important, just
> >> something that should be considered before finalizing everything
> >> in the near future.
> >>
> >
> > marketing has a role too ;-)
>
> yeah.. in terms of plants: branch, root, leaf etc are good
> words. They can be represented visually good. people who don't
> have problems with sight probably almost know what they look like
> and what their function is. I'd like to look further this.
>


thumbs up



> >> > We'll keep in touch anyway
> >> >
> >> > Ciao
> >>
> >> It's not like I'm abandoning this project. It's just taking a bit
> >> longer to share what we have with the public (and therefore
> >> interested people). I've added some bits to the bugtracker, but
> >> personally I'd feel more comfortable with working via email
> >> conversations. Email conversations allow me to handle work
> >> without connecting to one server all the time to check the status
> >> and (most of the time) they can't fail due to database crashing
> >> or eating too many resources.
> >>
> >
> > eh. We need federation and decentralization :-)
> >
> >
> >> But it's not my decision alone, and I'm giving bugtrackers a
> >> try. Devan is trying to set up Gitlab for us on an already
> >> running instance with an additional domain if that's possible
> >> with Gitlab.
> >>
> >
> > ah a Gitlab instance would be nice
> >
> > Thanks for considering GNUHealth !
>
> We're flipping discussion coins right now between Gitlab,
> gitolite, gitea and notabug (mod. Gogs).. so within the next
> week (or weeks, depending on what it will be) something should
> manifest itself.



very good
let me know

Ciao