Re: [Dng] OT: separate GUI from commands

[Didier Kryn]

Le 31/05/2015 22:34, Laurent Bercot a écrit :

On 31/05/2015 18:35, Didier Kryn wrote:

AFAIU, this thread has turned to be about interfacing whatever app to
a scripting language. I consider this a very usefull feature for all
but basic applications. In particular, I consider that interfacing
init - The init program which is pid 1 - with a scripting language
would provide ultimate "init freedom".


 init is the pinnacle of a "basic application". It's not even an
application, it's a system program. There is NO reason why you'd want
to interface init to a scripting language - what are you trying to
accomplish that can't be accomplished outside of process 1 ?

"init freedom", whatever that means, is a political goal, and has to be
reached with political tools. Trying to use technical tools to reach a
political goal is not a good idea; it usually produces bad software and
ends up being unsatisfying for everyone.



Laurent,

I know the argument that init should be kept small to be 
rock-solid. Does it mean that it must be written in C and not in Lua or Ash?


Anyway Sysvinit is not so small, invokes a great deal of shell 
scripts to do the job, and leaves service supervision to the admin.


Please take it easy. I'm not saying this would be the fastest or 
the most secure of all init programs. But it would be a base for 
experimentation and hacking and I think it would be pretty educative.


Didier

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

Re: [Dng] OT: separate GUI from commands

[Laurent Bercot]

On 01/06/2015 11:25, Didier Kryn wrote:

I know the argument that init should be kept small to be rock-solid.
Does it mean that it must be written in C and not in Lua or Ash?


 It all depends on what you call "init". This word encompasses at
least three different things. Explanation and details here (first
half of the document) :
 http://skarnet.org/software/s6/s6-svscan-1.html

 That said, everything is possible - and everything also has a cost.
Writing stage 1 or stage 2 in lua means that you need to have the lua
interpreter available in your root filesystem, and that you need to
trust it. Which is probably fine, but still, it's a cost that needs to
be acknowledged. Writing init in shell is perfectly fine for stage 1
and stage 3, but suboptimal for stage 2 - you definitely don't want
to program a supervision system in shell.

 Maybe I misunderstood you: it sounded like you wanted to make init
scriptable, as in including support for plugins written in a scripting
language, or something of the kind. That's what I objected to. But if
it's about writing init itself in a scripting language, depending on
the stage you're talking about, it's definitely reasonable.



Anyway Sysvinit is not so small, invokes a great deal of shell
scripts to do the job, and leaves service supervision to the admin.


 Oh, I never said I liked sysvinit. The best thing I can say in favor
of sysvinit is that it's not systemd. But there are a lot of alternatives,
runit being the simplest one to install - and I'm working on a stage 1
binary for s6 so it becomes just as simple.



Please take it easy. I'm not saying this would be the fastest or the
most secure of all init programs. But it would be a base for
experimentation and hacking and I think it would be pretty
educative.


 Oh, sure - I'm all for learning by experimenting and hacking away.
It's just that this mailing-list is about a distribution that aims
to be Debian-sized, so I thought you were suggesting it for Devuan.
I think you'll agree that on a distribution, stability, not grounds
for experimentation, is the primary concern.

 (PM: I tried to send you an e-mail and the in2p3.fr MX rejected it,
for unknown reasons, and the postmaster isn't answering me. Do you
have another e-mail address I could write you to ?)

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

Re: [Dng] OT: separate GUI from commands

[Steve Litt]

On Mon, 01 Jun 2015 11:25:03 +0200
Didier Kryn  wrote:


>  Laurent,
> 
>  I know the argument that init should be kept small to be 
> rock-solid. Does it mean that it must be written in C and not in Lua
> or Ash?

Yes. In my opinion it does. Init must be tiny, and it must be rock
solid. Lua is written in C, so it adds more "stuff" than a pure C
implementation.


>  Anyway Sysvinit is not so small, invokes a great deal of shell 
> scripts to do the job, and leaves service supervision to the admin.

:-)

A great many evils have been perpetrated based on being "better than
Sysvinit". In a few days, I will attempt to install an 89 line init
(Suckless Init), on Plop C. Now *that's* small, although to compare
apples with apples you must add daemontools-encore to the 89 lines,
because Suckless Init does no process management, so that all must be
done by daemontools-encore. And Laurent would probably point out that
what I'll be attempting has PID1 single-time running its /etc/rc script
instead of respawning it, so it's not appropriate for a real distro.
But anyway, Sysvinit should never be used as a justification for
anything.

> 
>  Please take it easy. I'm not saying this would be the fastest or 
> the most secure of all init programs. But it would be a base for 
> experimentation and hacking and I think it would be pretty educative.

Now that you're talking about experimentation, you're talking *my*
language. If it's just for experimentation, yeah, write it in Lua,
write it in bash, split it into start/reap signals and process
management. Rewriting daemontools in Lua --- that would be interesting.
I personally think daemontools is more a philosophy than an
implementation.

LOL, imagine writing startup scripts in Lua. How cool would that be?

But once again, this is for experimentation only. My official position
on "real work" type computers is to do it with Epoch, runit, s6, or
secondarily with Sysvinit + Daemontools or Sysvinit + OpenRC.

One more thing. Your mileage may differ, but I've found it an order of
magnitude easier to lay down Epoch or runit on a no-systemd distro than
on a poetterized distro. So Devuan is the perfect host for *the
individual user* to decide to jumper in Epoch, runit, or s6.


SteveT

Steve Litt 
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] DistroWatch review of Manjaro-OpenRC

[Steve Litt]

On Mon, 1 Jun 2015 12:11:08 +0800
Robert Storey  wrote:

> Now that Ubuntu and Debian have decided to go over to the Dark Side
> (ie systemd), I've been looking for a replacement at least until
> Devuan is released. I believe it was Steve Litt who made a post
> suggesting that Manjaro-OpenRC was very good, so I checked it out.
> Long story made short, it is indeed very good and has now replaced
> Ubuntu on my desktop and laptop machines.

Manjaro-OpenRC occupies a time-honored role: It gives our developers
the breathing room to bring Devuan to perfection. It's where people can
go until Devuan is ready.

Of course, Manjaro-OpenRC is a wonderful product in and of itself, and
I'm friendly with several of the people there. Truth be told, the
reason I chose Devuan over Manjaro-OpenRC is because I view the Devuan
Community as being astonishingly astounding, and I want to be part of
it.

SteveT

Steve Litt 
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] automounting in a window manager

[Rob Owens]

- Original Message -
> From: "Robert Storey" 
> 
> First, thanks to all who replied.
> 
> To me, the ideal solution would be if this was a user-configurable option.
> Would be great if you could, for example, just stick something into .bashrc
> for any user to allow automounting of USB devices, no matter which DE or
> window manager was being used. But I know it doesn't work that way. Just
> saying, it would make sense.
> 
> pmount - yes, thanks for reminding me. I've used it eons ago. But all it does
> is allow one to mount a device without needing sudo. Still not really
> automounting.
> 
> No one mentioned udevil. I just found it. Also not the same as automounting,
> but check out the interesting git home page:
> 
> https://ignorantguru.github.io/udevil/
> 
That guy also wrote spacefm.  It's a file manager which allows you to either
manually or automatically mount USB devices.  It can be configured to use
udevil, pmount, udisks1, or udisks2 to perform that function.

Spacefm is currently unsupported by the developer.

In the past I've used pcmanfm to perform this function, but on Jessie, it
seems to require systemd stuff in order to handle mounting.

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

Re: [Dng] OT: separate GUI from commands

[Didier Kryn]

Le 01/06/2015 12:59, Laurent Bercot a écrit :


 Oh, sure - I'm all for learning by experimenting and hacking away.
It's just that this mailing-list is about a distribution that aims
to be Debian-sized, so I thought you were suggesting it for Devuan.
I think you'll agree that on a distribution, stability, not grounds
for experimentation, is the primary concern.

Yes, but the whole thread is off-topic :-) And this is not a 
project, only a dream.



 (PM: I tried to send you an e-mail and the in2p3.fr MX rejected it,
for unknown reasons, and the postmaster isn't answering me. Do you
have another e-mail address I could write you to ?)


Strange. I know the server is strict about whatever conformance of 
the mail format and address of the sender to whatever existing standard, 
as a non-intrusive means to reject part of the spam. So maybe there is 
something unexpected from your mail agent.


You can also reach me at  or .

Didier

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

Re: [Dng] automounting in a window manager

[shraptor]

On 2015-06-01 16:22, Rob Owens wrote:

- Original Message -

From: "Robert Storey" 

First, thanks to all who replied.

To me, the ideal solution would be if this was a user-configurable 
option.
Would be great if you could, for example, just stick something into 
.bashrc
for any user to allow automounting of USB devices, no matter which DE 
or
window manager was being used. But I know it doesn't work that way. 
Just

saying, it would make sense.

pmount - yes, thanks for reminding me. I've used it eons ago. But all 
it does

is allow one to mount a device without needing sudo. Still not really
automounting.

No one mentioned udevil. I just found it. Also not the same as 
automounting,

but check out the interesting git home page:

https://ignorantguru.github.io/udevil/

That guy also wrote spacefm.  It's a file manager which allows you to 
either
manually or automatically mount USB devices.  It can be configured to 
use

udevil, pmount, udisks1, or udisks2 to perform that function.

Spacefm is currently unsupported by the developer.




checking github
https://github.com/IgnorantGuru/spacefm/commits/next

it seems spacefm is very much alive




In the past I've used pcmanfm to perform this function, but on Jessie, 
it

seems to require systemd stuff in order to handle mounting.

-Rob
___
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] Lennart reacts to the release of Devuan

[Marlon Nunes]

On 2015-05-31 01:21, Init Freedom wrote:

https://www.youtube.com/watch?v=_cdEFF-ttLw [1]

May the source be with you, gents.

Links:
--
[1] https://www.youtube.com/watch?v=_cdEFF-ttLw

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


Really nice!

--
Stop slacking you lazy bum!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Lennart reacts to the release of Devuan

[Jaromil]

On Sun, 31 May 2015, Yves wrote:
>Damn I find this distasteful!!

agreed, however we must consider that another hitler video was done
against us even before we had the chance to follow up from the
declaration with present facts and even if the "german dictator type" is
obviously not sitting in this side of the barricade.

I recall that following that older video against us one newspaper even
said that Devuan was a neo-nazi distro of sorts, until I contacted them
asking to be reasonable... I hope now this doesn't happens for Debian.

If we need to rejoyce around a video prank, I'd prefer using the Matrix
or something about the exodus from Egyptian slavery.

ciao



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

Re: [Dng] automounting in a window manager

[Rob Owens]

- Original Message -
> From: "shraptor" 
> On 2015-06-01 16:22, Rob Owens wrote:
> > - Original Message -
> >> From: "Robert Storey" 
> >> 
> >> First, thanks to all who replied.
> >> 
> >> To me, the ideal solution would be if this was a user-configurable
> >> option.
> >> Would be great if you could, for example, just stick something into
> >> .bashrc
> >> for any user to allow automounting of USB devices, no matter which DE
> >> or
> >> window manager was being used. But I know it doesn't work that way.
> >> Just
> >> saying, it would make sense.
> >> 
> >> pmount - yes, thanks for reminding me. I've used it eons ago. But all
> >> it does
> >> is allow one to mount a device without needing sudo. Still not really
> >> automounting.
> >> 
> >> No one mentioned udevil. I just found it. Also not the same as
> >> automounting,
> >> but check out the interesting git home page:
> >> 
> >> https://ignorantguru.github.io/udevil/
> >> 
> > That guy also wrote spacefm.  It's a file manager which allows you to
> > either
> > manually or automatically mount USB devices.  It can be configured to
> > use
> > udevil, pmount, udisks1, or udisks2 to perform that function.
> > 
> > Spacefm is currently unsupported by the developer.
> > 
> 
> 
> checking github
> https://github.com/IgnorantGuru/spacefm/commits/next
> 
> it seems spacefm is very much alive
> 

Awesome!  Thanks for the update.  Last I had read, ignorantguru was on 
haitus (announced April 28, 2014).  But it looks like as of this February, 
he's back.

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

Re: [Dng] Is it useful to create a .so file to replace functions imported from libsystemd & Co.?

[T.J. Duchene]

> After more digging, what did the problem turn out to be?
> 
> 
>  policykit-1.  Yup, during my upgrade, I snagged policykit-1 from
> Devuan.  It broke things.
> 
> I apt-get remove'd policykit-1, and lookit that, my Reboot/Shutdown
> buttons are back. I didn't even have to restart XFCE.
> 
> 
> ~jaret

 [T.J. ] Thank you.  That is actually useful information. I've never really 
been a fan of policykit, aka polkit.  The point behind policykit is to have 
nonprivileged processes communicate with privileged ones.  You give polkit 
exactly the same password as you would to extend sudo privileges, and it in 
effect does the same thing.  I'm not saying they are exactly the same.  They 
aren't.  But they ARE used for exactly the same purposes on a day to day basis. 
 Sudo can be fine-grained as well. It does not have to be an all or nothing 
approach.  Why have two different mechanisms installed to do the same job? 

Like most efforts on Linux, the idea is a bit daft.  I say that with affection. 
 People mean well, but Linux is hardly an organized system.  It is a 
hodge-podge of hacks, thrown together in a blender.  Outside of the kernel, 
there is very little rhyme or reason.  Userspace is always a mess.  Then they 
try to consolidate things into systemd, and make an even bigger mess because 
systemd is not ABI stable, nor is everything properly documented.



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

[Dng] New systemd release notes regarding udev.

[James Powell]

https://github.com/systemd/systemd/blob/master/NEWS

It seems udev is getting split up between several projects within systemd and 
GNOME. It seems gudev is being handed off in the future to GNOME and parts of 
udev are being pushed deeper into systemd.

I'm not surprised at this, since kdbus didn't get pushed into the kernel 
mainline, but it does show evidence of the callousness being presented to the 
Linux ecosystem. If they don't get their way one way, they try to get their way 
another.

I am wondering how much longer eudev can remain tied to systemd-udev, unless it 
becomes completely independent. We still are waiting on the progress of vdev, 
patiently. So until then, it seems to be wait and see yet again.

Thoughts?

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

Re: [Dng] New systemd release notes regarding udev.

[Jude Nelson]

Hi Jim,


> It seems udev is getting split up between several projects within systemd
> and GNOME. It seems gudev is being handed off in the future to GNOME and
> parts of udev are being pushed deeper into systemd.
>
>
gudev splitting off isn't a problem; in fact, I applaud the decision.


> I'm not surprised at this, since kdbus didn't get pushed into the kernel
> mainline, but it does show evidence of the callousness being presented to
> the Linux ecosystem. If they don't get their way one way, they try to get
> their way another.
>
> I am wondering how much longer eudev can remain tied to systemd-udev,
> unless it becomes completely independent. We still are waiting on the
> progress of vdev, patiently. So until then, it seems to be wait and see yet
> again.
>

vdev will ship with libudev-compat, which is ABI-compatible with the public
API of libudev 219.  I'm afraid I couldn't manage ABI compatibility with
the private API, but AFAIK only udev and systemd were its clients anyway.
Also, vanilla libudev 219 doesn't overlap that much with systemd, so we can
easily build our own and ship that in place of libudev 220+ in the
near-term.

libudev-compat is still a work in progress, but it's my last major blocker,
and I hope to have something testable by early next week.  The key
challenge has been in removing the need for the udev-controlled netlink
multicast group to deliver events while continuing to provide the same
semantics at comparable performance.  While my approach almost certainly
won't be as fast as netlink-based libudev, it should:
* be fast enough for our purposes (will provide actual performance data
when I have them);
* be easier to troubleshoot (i.e. the admin can read, inject, reorder,
copy, and remove device events without having to instrument the device
manager, the kernel, or the libudev client);
* be agnostic to which device manager (if any) is running;
* let the admin control which root-context events get propagated to
containerized libudev clients (something udev and libudev *cannot* do, due
to their reliance on netlink).

You don't have to wait up for me, though--Devuan's udev and eudev are ready
to use now :)  Developing vdev and libudev-compat is one of several
contingency plans for the scenario where udev and libudev become
intractably dependent on systemd.

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

Re: [Dng] New systemd release notes regarding udev.

[James Powell]

One concern I have is how GNOME will manage gudev. One thing I don't want to 
think about is them creating some dependency upon systemd in some way 
preventing portability to extracted udev or something that is udev compatible 
like vdev requiring gudev to be either heavily patched or redeveloped, such as 
a gvdev project.

It's mind numbing to consider all this, but the rate they are trying to tighten 
their grip, at least we do know the more alternatives seem to supplicant things 
enough to keep pro-choice distributions slipping through their fingers.

-Jim

From: Jude Nelson
Sent: ‎6/‎1/‎2015 6:58 PM
To: James Powell
Cc: dng@lists.dyne.org
Subject: Re: [Dng] New systemd release notes regarding udev.

Hi Jim,


> It seems udev is getting split up between several projects within systemd
> and GNOME. It seems gudev is being handed off in the future to GNOME and
> parts of udev are being pushed deeper into systemd.
>
>
gudev splitting off isn't a problem; in fact, I applaud the decision.


> I'm not surprised at this, since kdbus didn't get pushed into the kernel
> mainline, but it does show evidence of the callousness being presented to
> the Linux ecosystem. If they don't get their way one way, they try to get
> their way another.
>
> I am wondering how much longer eudev can remain tied to systemd-udev,
> unless it becomes completely independent. We still are waiting on the
> progress of vdev, patiently. So until then, it seems to be wait and see yet
> again.
>

vdev will ship with libudev-compat, which is ABI-compatible with the public
API of libudev 219.  I'm afraid I couldn't manage ABI compatibility with
the private API, but AFAIK only udev and systemd were its clients anyway.
Also, vanilla libudev 219 doesn't overlap that much with systemd, so we can
easily build our own and ship that in place of libudev 220+ in the
near-term.

libudev-compat is still a work in progress, but it's my last major blocker,
and I hope to have something testable by early next week.  The key
challenge has been in removing the need for the udev-controlled netlink
multicast group to deliver events while continuing to provide the same
semantics at comparable performance.  While my approach almost certainly
won't be as fast as netlink-based libudev, it should:
* be fast enough for our purposes (will provide actual performance data
when I have them);
* be easier to troubleshoot (i.e. the admin can read, inject, reorder,
copy, and remove device events without having to instrument the device
manager, the kernel, or the libudev client);
* be agnostic to which device manager (if any) is running;
* let the admin control which root-context events get propagated to
containerized libudev clients (something udev and libudev *cannot* do, due
to their reliance on netlink).

You don't have to wait up for me, though--Devuan's udev and eudev are ready
to use now :)  Developing vdev and libudev-compat is one of several
contingency plans for the scenario where udev and libudev become
intractably dependent on systemd.

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