Re: [DNG] NVidia driver howto?

2015-09-03 Thread Go Linux 
On Thu, 9/3/15, hal  wrote:

 Subject: Re: [DNG] NVidia driver howto?
 To: "Go Linux" , dng@lists.dyne.org
 Date: Thursday, September 3, 2015, 8:41 AM

On September 3, 2015 7:43:01 AM CDT, Go Linux  wrote:

::
:: Doesn't sgfxi automate all that?  Last time I had to install an
:: nVidia driver, it worked like a charm.  Not quite sure of its current
:: status though as it's been a while . . .

::

> Hrm..not sure what sgfxi is. Google seems to suggest it's a debian thing, but 
> I've never used it. The
> way I installed the nvidia driver on Devuan was the old-school method of 
> downloading NVidia's shell > script and running it as root to build the 
> module.  There is a lot of back-end work the script does to > try and make 
> things work correctly but it's always a matter of hope and luck when 
> installing things
> that way.



Sorry . . . should have included a link.  Here it is:

http://smxi.org/


golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] NVidia driver howto?

2015-09-03 Thread hal 
On September 3, 2015 7:43:01 AM CDT, Go Linux  wrote:
:: 
:: Doesn't sgfxi automate all that?  Last time I had to install an
:: nVidia driver, it worked like a charm.  Not quite sure of its current
:: status though as it's been a while . . .
:: 

Hrm..not sure what sgfxi is. Google seems to suggest it's a debian thing, but 
I've never used it. The way I installed the nvidia driver on Devuan was the 
old-school method of downloading NVidia's shell script and running it as root 
to build the module.  There is a lot of back-end work the script does to try 
and make things work correctly but it's always a matter of hope and luck when 
installing things that way.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] NVidia driver howto?

2015-09-03 Thread Hendrik Boom 
On Thu, Sep 03, 2015 at 08:41:17AM -0500, hal wrote:
> On September 3, 2015 7:43:01 AM CDT, Go Linux  wrote:
> :: 
> :: Doesn't sgfxi automate all that?  Last time I had to install an
> :: nVidia driver, it worked like a charm.  Not quite sure of its current
> :: status though as it's been a while . . .
> :: 
> 
> Hrm..not sure what sgfxi is. Google seems to suggest it's a debian thing, but 
> I've never used it. The way I installed the nvidia driver on Devuan was the 
> old-school method of downloading NVidia's shell script and running it as root 
> to build the module.  There is a lot of back-end work the script does to try 
> and make things work correctly but it's always a matter of hope and luck when 
> installing things that way.

I seem to remember that at one time debian had packaged the proprietary 
nvidia driver that, in the postinstall stage, ran a script that just 
followed nvidia's instructions for downloading and installing.

But nvidia didn't keep up with kernel changes consistently, so sometimes 
it worked and sometimes it didn't, exactly as nvidia's drivers did and 
didn't.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread KatolaZ 
On Thu, Sep 03, 2015 at 06:53:46PM +0100, KatolaZ wrote:

[cut]

> 
> OK, I admit it might had been a tad too cryptic, but my intentions
> were good. What I mean is that the parent has to set a handler for
> SIGCHLD, and the handler has to call wait() [or waitpid(-1, )]
> to reap the dead child. The handler must be set *before* any of the
> children is ever spawn, otherwise there is still a concrete chance to
> create zombies.
> 
> If your parent process handles SIGCHLD correctly, you can also force
> reaping by sending it a SIGCHLD with the kill command.
> 

To make things more clear, here is a minimal example:

  http://www.linuxprogrammingblog.com/code-examples/SIGCHLD-handler

Beware that in this case the children do nothing (they just exit
immediately), and the final while(sleep(1)) is not required.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread Steve Litt 
On Thu, 3 Sep 2015 18:24:51 +0100
Edward Bartolo  wrote:

> I found that the created zombies are owned by root and the frontend
> does not run with root privileges. I think, this may be the reason.
> 
> The reason why zombies are created is that we are effectively
> replacing backend by what execl calls. We may be able to solve the
> issue by allowing the backend to continue running when execl is used
> and at the end call wait() if that is possible.

Holy cow! Why does anything require execl()? As this whole escapade
goes to show, execl() has complication that is not without cost. I'm
also not sure why C is needed.

I'm thinking your back end could probably be a simple shellscript that
interacts with wpa_supplicant and its config file. I'll admit the
documentation for wpa_supplicant is ambiguous, contradictory and
pathologically incomplete, but I'm pretty sure nothing about this
problem domain requires execl(). Just have the back end running, and
have the front end communicate with it in a simple and well documented
manner of your design.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread Laurent Bercot 

On 03/09/2015 18:35, Steve Litt wrote:

I'd figure out how to stop those zombies from happening in the first
place. It's pretty hard to create a zombie: I think you have to
doublefork and then terminate.


 Nope, a zombie is actually very easy to create:
 - have a process parent that spawns a child and stays alive
 - have the child die first, and the parent not reap it.
That's it. A dead child is a zombie until the parent acknowledges its
death, and if the parent is failing its duties, the zombie will remain,
an empty soulless shell spawned inconsiderately with no love or
regards for consequences that will haunt the system forever.

 ...not quite forever. If the parent dies, the child process' paternity
will be reassigned to PID1, and PID1 will receive a SIGCHLD. Basically
every PID1 program correctly handles that and reaps every zombie it gets,
even if it's not the one that fathered it.

 But when the parent is a daemon, it's not supposed to die, so counting
on PID1 to do the dirty work is obviously not a solution, and it has to
reap children.

 Edward's problem is that his "backend" process is spawning children and
not reaping them. It has nothing to do with the frontend. To make sure
what process the zombies are children of, use the "f" option to ps, or
the pstree utility.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread KatolaZ 
On Thu, Sep 03, 2015 at 06:36:39PM +0100, KatolaZ wrote:

[cut]

> 
> Sorry guys, I didn't get through the whole thread, but I wanted to say
> just one obvious thing: if your program works correctly, then it is
> *very* difficult (if not impossible) to create and leave zombies
> around. If the program that fork()s does call wait() properly, no
> zombies can remain anywhere. A zombie is just a process which has died
> and is waiting there for its parent to call the damn wait(). 
> 
> If your code leaves zombies, then it is not working properly, and you
> should fix it before moving on.
> 

OK, I admit it might had been a tad too cryptic, but my intentions
were good. What I mean is that the parent has to set a handler for
SIGCHLD, and the handler has to call wait() [or waitpid(-1, )]
to reap the dead child. The handler must be set *before* any of the
children is ever spawn, otherwise there is still a concrete chance to
create zombies.

If your parent process handles SIGCHLD correctly, you can also force
reaping by sending it a SIGCHLD with the kill command.

My2Cents

KatolaZ


-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread Edward Bartolo 
I kept a multithreaded netman version installed on my computer so that
I would be able to connect to wifi with a couple of button clicks. All
I can say is, that it doesn't create zombies and it is well behaved.
What we should do is do away with execl which *replaces* backend
effectively killing it and letting the new child execute. The backend
is already using popen to run executables, so we can use that instead
of the problematic execl. This to make things easier for TThread
instead of expecting it to behave when we call execl which kills the
thread controlled by TThread.

I think, TThread may present a simple solution that allows us to keep
the code effectively as it is without a drastic overhaul.

What I need is to use ps to check for any children owned by netman,
and the whole application will be almost ready.

ps command: ps xao pid,ppid,comm | grep netman
Look for any process parented by netman and adjust the frontend
accordingly and we are almost ready.

Edward.

On 03/09/2015, Steve Litt  wrote:
> On Thu, 3 Sep 2015 18:24:51 +0100
> Edward Bartolo  wrote:
>
>> I found that the created zombies are owned by root and the frontend
>> does not run with root privileges. I think, this may be the reason.
>>
>> The reason why zombies are created is that we are effectively
>> replacing backend by what execl calls. We may be able to solve the
>> issue by allowing the backend to continue running when execl is used
>> and at the end call wait() if that is possible.
>
> Holy cow! Why does anything require execl()? As this whole escapade
> goes to show, execl() has complication that is not without cost. I'm
> also not sure why C is needed.
>
> I'm thinking your back end could probably be a simple shellscript that
> interacts with wpa_supplicant and its config file. I'll admit the
> documentation for wpa_supplicant is ambiguous, contradictory and
> pathologically incomplete, but I'm pretty sure nothing about this
> problem domain requires execl(). Just have the back end running, and
> have the front end communicate with it in a simple and well documented
> manner of your design.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread tilt! 

Hi Edward,

AFAIK Status must be a pointer, because fpwaitpid will write
information into that status.

Also, you should check the return value of fpwaitpid():

 0 : nothing has happened
 -1: an error occurred, check fgGetErrno
 other: the pid of a child where something happened

so like (pseudocode):

cint rv;
pcint Status;

while true
   rv := waitpid(-1, Status, WNOHANG);

   if rv=-1
  {* an error occured, report fpGetErrno *}
  return;
   else if rv<>0
  {* rv is the pid that was reaped,
 you could report rv and Status now *}
  return;
   else
  {* nothing has happened, resume waiting *}
  continue;
end;

If that doesn't help, check that this way of handling
children does not conflict with some option you have
set for the child TProcess.

Best regards,
T.


On 09/03/2015 08:38 AM, Edward Bartolo wrote:

I am trying to reap zombies. The "while(fpwaitpid" pascal code is
freezing my application.

*
procedure handle_sigchld(sig: longint; info: psiginfo; context:
psigcontext); cdecl;
var
   Status: cint;
   a_pid: pid_t;
begin
   Status := 0;
   a_pid := -1;

// This is freezing my application
   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
   begin
 backend_lives := backend_lives + 1;
 showmessage('hi strunz!!!');
   end;
end;


var sa: sigactionrec;

initialization
   sa.sa_handler := @handle_sigchld;
   fpsigemptyset(_mask);

   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
   begin
 // do nothing
   end;
**

Any ideas?


Edward



On 02/09/2015, Steve Litt  wrote:

Personally, I'd go way out of my way never to multithread unless
there were a huge reason to do so. Your app does such a small, quick
job that there's no reason.

You mentioned the front and back end communicating with each other, and
everyone mentioned fifos. I agree. And if there's a reason for one
program to tell the other that info's ready for it, that's what SIGUSR1
and SIGUSR2 are for. Or at least what *I* use them for.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust


On Wed, 2 Sep 2015 19:45:08 +0100
Edward Bartolo  wrote:


What about multithreading? Should I do away with it and let the
frontend monitor for zombies to call waitpid?

Edward

On 02/09/2015, Steve Litt  wrote:

On Wed, 2 Sep 2015 11:47:34 +0100
Edward Bartolo  wrote:


Hi all,

I think, I found an alternative to multithreading in netman. This
is using interprocess communication, although what I have in mind
may not be proper interprocess communication.

The idea is this: the backend would be converted into some sort of
a daemon exporting one function and importing another one. The
frontend would use the exported function from the backend to send
it commands. The backend would do the same thing with the exported
function from the frontend:

Visually, this is as follows:

Frontend -->> Backend
Frontend <<-- Backend

In my humble opinion, this may help getting rid of having to use
multithreading to avoid temporary frontend deadlocks. It also
solves the issue with zombies being created, and would permit me
create a responsive application but using the KISS principle.


I like it. A lot!

IMHO the front end should do nothing but display ESSIDs with
strength and encryption, letting you click on the one you want or
right click and say "turn off" to turn it off.

If you've already dealt with that ESSID, the back end has the
password and uses it to join that ESSID. If the back end hasn't
dealt with it, it sends the front end a message saying "get me the
password", the front end queries the user for the password, and the
front end sends it back to the back end. Assuming one user, this
doesn't even have to be stateful, but if it has to be stateful,
there are a million ways to do it.

I like it!

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread Edward Bartolo 
I am trying to reap zombies. The "while(fpwaitpid" pascal code is
freezing my application.

*
procedure handle_sigchld(sig: longint; info: psiginfo; context:
psigcontext); cdecl;
var
  Status: cint;
  a_pid: pid_t;
begin
  Status := 0;
  a_pid := -1;

// This is freezing my application
  while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
  begin
backend_lives := backend_lives + 1;
showmessage('hi strunz!!!');
  end;
end;


var sa: sigactionrec;

initialization
  sa.sa_handler := @handle_sigchld;
  fpsigemptyset(_mask);

  sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
  if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
  begin
// do nothing
  end;
**

Any ideas?


Edward



On 02/09/2015, Steve Litt  wrote:
> Personally, I'd go way out of my way never to multithread unless
> there were a huge reason to do so. Your app does such a small, quick
> job that there's no reason.
>
> You mentioned the front and back end communicating with each other, and
> everyone mentioned fifos. I agree. And if there's a reason for one
> program to tell the other that info's ready for it, that's what SIGUSR1
> and SIGUSR2 are for. Or at least what *I* use them for.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
>
>
> On Wed, 2 Sep 2015 19:45:08 +0100
> Edward Bartolo  wrote:
>
>> What about multithreading? Should I do away with it and let the
>> frontend monitor for zombies to call waitpid?
>>
>> Edward
>>
>> On 02/09/2015, Steve Litt  wrote:
>> > On Wed, 2 Sep 2015 11:47:34 +0100
>> > Edward Bartolo  wrote:
>> >
>> >> Hi all,
>> >>
>> >> I think, I found an alternative to multithreading in netman. This
>> >> is using interprocess communication, although what I have in mind
>> >> may not be proper interprocess communication.
>> >>
>> >> The idea is this: the backend would be converted into some sort of
>> >> a daemon exporting one function and importing another one. The
>> >> frontend would use the exported function from the backend to send
>> >> it commands. The backend would do the same thing with the exported
>> >> function from the frontend:
>> >>
>> >> Visually, this is as follows:
>> >>
>> >> Frontend -->> Backend
>> >> Frontend <<-- Backend
>> >>
>> >> In my humble opinion, this may help getting rid of having to use
>> >> multithreading to avoid temporary frontend deadlocks. It also
>> >> solves the issue with zombies being created, and would permit me
>> >> create a responsive application but using the KISS principle.
>> >
>> > I like it. A lot!
>> >
>> > IMHO the front end should do nothing but display ESSIDs with
>> > strength and encryption, letting you click on the one you want or
>> > right click and say "turn off" to turn it off.
>> >
>> > If you've already dealt with that ESSID, the back end has the
>> > password and uses it to join that ESSID. If the back end hasn't
>> > dealt with it, it sends the front end a message saying "get me the
>> > password", the front end queries the user for the password, and the
>> > front end sends it back to the back end. Assuming one user, this
>> > doesn't even have to be stateful, but if it has to be stateful,
>> > there are a million ways to do it.
>> >
>> > I like it!
>> >
>> > SteveT
>> >
>> > Steve Litt
>> > August 2015 featured book: Troubleshooting: Just the Facts
>> > http://www.troubleshooters.com/tjust
>> > ___
>> > Dng mailing list
>> > Dng@lists.dyne.org
>> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> >
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

2015-09-03 Thread Rainer Weikusat 
Edward Bartolo  writes:
> I am trying to reap zombies. The "while(fpwaitpid" pascal code is
> freezing my application.
>
> *
> procedure handle_sigchld(sig: longint; info: psiginfo; context:
> psigcontext); cdecl;
> var
>   Status: cint;
>   a_pid: pid_t;
> begin
>   Status := 0;
>   a_pid := -1;
>
> // This is freezing my application
>   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
>   begin
> backend_lives := backend_lives + 1;
> showmessage('hi strunz!!!');
>   end;
> end;
>
>
> var sa: sigactionrec;
>
> initialization
>   sa.sa_handler := @handle_sigchld;
>   fpsigemptyset(_mask);
>
>   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
>   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
>   begin
> // do nothing
>   end;
> **
>
> Any ideas?

As was already mentioned: The second argument to fpwaitpid must be a
pointer. As opposed to what was already mentioned, the loop condition is
generally correct: The loop must terminate if the return value is either
-1 (some kind of error occurred) or 0 (nothing more to do right now).

Caveat: The signal handler is asynchronously invoked by the kernel when
a SIGCHLD is posted and it will interrupt whatever else the application
was doing at the moment. This means it's as if it was running in a
separate thread (except even more complicated).

According to

http://www.freepascal.org/docs-html/rtl/baseunix/fpsigaction.html

Sa_Handler may be SIG_DFL for the default action or SIG_IGN to
ignore the signal.

For as long as you aren't using the exit status, using SIG_IGN instead
of a signal handler is to be preferred as the kernel will then just not
create zombies.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] NVidia driver howto?

2015-09-03 Thread hal 
hal wrote on 08/28/15 06:18:
> I searched for 'devuan nvidia' and did not find any howto/docs so went to 
> wiki.debian.org 

Got this working! Not sure if the modprobe files helped or just removing the 
xorg.conf.
In case someone else is trying to get X working with the NVIDIA download driver,
here's what I did:

1) added this file (from linux mint) to devuan
# cat nvidia-graphics-drivers-ubuntu.conf
# This file was installed by nvidia-340
# Do not edit this file manually

blacklist nouveau
blacklist lbm-nouveau
blacklist nvidia-current
blacklist nvidia-173
blacklist nvidia-96
blacklist nvidia-current-updates
blacklist nvidia-173-updates
blacklist nvidia-96-updates
blacklist nvidia-340-updates
alias nvidia nvidia_340
alias nvidia-uvm nvidia_340-uvm
alias nouveau off
alias lbm-nouveau off


2) added this file as well to modprobe.d.
# cat blacklist-framebuffer-ubuntu.conf
# This file blacklists most old-style PCI framebuffer drivers.

blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist gx1fb
blacklist gxfb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist nvidiafb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist viafb
blacklist vt8623fb

3) moved /etc/X11/xorg.conf to /etc/X11/xorg.conf.myoldconf



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] trollproof spec

2015-09-03 Thread Jaromil 

dear Jonathan,

On Thu, 03 Sep 2015, Jonathan Wilkes wrote:

>I have a spec for "trollproofs" which might help with moderation.  Instead
>of the moderator having a binary choice between "block" or "pass", he/she
>can just choose a difficulty level for a particular topic which the
>community adheres to in order to encourage good faith.

What you sketch exists already even before Bitcoin, is called Hashcash
and I have good reasons to think Satoshi Nakamoto knew it.  We did run
that on dyne/freaknet server back than as an experiment, pity it didn't
took off instead of the lame and centralized DKIM thing nowadays
everyone uses.

However I doubt hashcash can be regarded as something to defend from
trolls. After all, trolling is a art...
http://pix.dyne.org/wp-content/uploads/2011/08/trollingArt.jpeg ... that
has much more to do with humans than with machines and computation
cycles.

Regarding the "dictatorial" problem rest assured that the present
situation is just temporary. Both me and nextime are leading in a more
centralized way the development and community process until the 1.0 is
reached. Meaning we have easy and direct reach to the big-red-button in
case of all sorts of attacks from the systemd-hooligans - and they
aren't lacking, there is a denigration campaign against us that has yet
to be over. But no prob, is not hurting, actually its even motivating at
times and our main focus is to develop our project, not denigrate others

The way we will unlock this situation will be through a social contract
and constitution for Devuan, which takes off from the Debian one but
grows or shrinks in needed directions. Us current "dictators" will be
not directly involved in its drafting (meaning who is in absolute power
now does not have absolute power on the drafting of the social contract)

VUAs believe in expertise as much as in democracy (or perhaps even more)
so we are using some of the funds to hire a renown researcher in
humanities and technology with solid experience of F/OSS and hacker
communities to propose a new draft and review our process here. If
nothing changes in the present schedule, she will come up with something
interesting to read and debate in a couple of months from now.

ciao



signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] trollproof spec

2015-09-03 Thread Didier Kryn 

Le 03/09/2015 13:40, Jaromil a écrit :

  After all, trolling is a art...
http://pix.dyne.org/wp-content/uploads/2011/08/trollingArt.jpeg  ...


If all trolls were as charming as this one...

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng