Hi Adam,
Good catch! The class of user-initiated runtime program alterations
(ptrace, LD_PRELOAD, LD_LIBRARY_PATH, different ld, etc) had slipped my
mind. This is why I'm having the conversation on vdev's core features
*before* the first alpha release, so design problems like this will get
caugh
On Tue, Dec 30, 2014 at 03:52:39PM +, David Robinson wrote:
> Seriously?
>
> I support the removal of systemd (after wasting hours of my time on both it
> and pulseaudio), but emailing me my password in plain text is a seriously
> bad move. I think this will hurt the project.
>
> Please stop
On Sun, Dec 28, 2014 at 10:52:38PM -0500, Jude Nelson wrote:
> Here's a more practical example that hides /dev/input/* and /dev/dri/* from
> every program except the X server (installed to /usr/bin/X):
>
> [vdev-acl]
> bin=/usr/bin/X
> paths=input/.*|dri/.*
> setmode=0666
This seems broken to me.
Well, pulseaudio is not the best option but, really, 75% is a bug. I'm
using it 0.1% with 3 pids in a 4GB ram system, so... Ubuntu 14 is not the
best example for nothing, in addition, 14.04 is not systemd native, so
report the bug to canonical about systemd and 14.04
nix\
2014-12-26 0:15 GMT-03
For God's sake, why you keep posting the very same massage over and over
again?!
Or, is that a problem with our mail list?
On 27 December 2014 at 12:22, dima wrote:
> You can't just switch to vdev, because many packages depend on libudev.
> Only udev and eudev provide it.
>
> eudev is the only
You can't just switch to vdev, because many packages depend on libudev. Only
udev and eudev provide it.
eudev is the only realistic option right now, because it's a drop-in
replacement. Moreover, it's the only udev alternative with feature-parity.
By the way, I'm not sure whether vdev is ready
Hey Enrico,
Although it looks simple on the surface, your question got at a wonderful,
thought-provoking design decision (at least, it took me several hours to
think of a good answer). The design question is, for a device filesystem
that equivocates about inode information in order to control acc
How many times do we have to suffer from receiving this identical email? dima,
please turn the automation OFF!
On Sat, 12/27/14, dima wrote:
Subject: Re: [Dng] What to do with udev? Some ideas...
To: dng@lists.dyne.org
Date: Saturday, December 27
You can't just switch to vdev, because many packages depend on libudev. Only
udev and eudev provide it.
eudev is the only realistic option right now, because it's a drop-in
replacement. Moreover, it's the only udev alternative with feature-parity.
By the way, I'm not sure whether vdev is ready
On 29.12.2014 04:52, Jude Nelson wrote:
> Hi Enrico,
>
> ACLs act as whitelists that additionally let vdev equivocate about
> device nodes to different processes, based on the user, group, process
> information (PID, inode, binary path, SHA256), and requested device
> file. Let's work through a f
On 30.12.2014 18:18, frank ernest wrote:
> https://www.mail-archive.com/dng%40lists.dyne.org/msg00051.html
>
> And later messages suggested to me that this was the case.
> Perhaps I misunderstood.
I was talking about forking dpkg/apt in case they would
introduce any dependency on systemd (which
From: frank ernest
Sent: Tuesday, December 30, 2014 11:18 AM
To: dng@lists.dyne.org
https://www.mail-archive.com/dng%40lists.dyne.org/msg00051.html
>And later messages suggested to me that this was the case.
>Perhaps I misunderstood.
Maybe there is. I’m hardly a source of
Hi Jude,
One thing that matters most (for me), is that you're here, working on this,
with Devuan team. This is very important!
Also, when talking about eudev, we have this:
q: plans when udev becomes systemd-only ? (after kdbus merge):
https://github.com/gentoo/eudev/issues/95
I can see why
On 29.12.2014 14:13, Richard wrote:
> Yes.
> And use a DE like Xfce for easier takeup.
> Needless complexity is a trap to delay the Devuan project.
IIRC, our primary goal is to bring back the original freedom of chioce,
and therefore support non-systemd (or maybe non-freedesktop.*) setups,
whi
>> I've been reading about how there's a new packaging
>> system planned, might I inquire about the ideas/goals
>> behind it?
>>
>
> Not that I've seen. Although I have certainly made a few discussions on
> the topic. As far as I know, the present plan is to stay with Apt for at
> least the first r
No, wait, you sent the link in a later message, thanks.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
For links to ceni I get only two useful ones:
http://manual.aptosid.com/en/inet-ceni-en.htm
and
http://www.mepis.org/docs/en/index.php?title=Ceni
I can't seem to find source code.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-b
On 30/12/2014 16:52, David Robinson wrote:
> Please stop this happening.
It would be helpful to know which service mailed you back a plain text
password.
AFAICT, GitLab does not mail back passwords upon registration.
If you're talking about the mailing list itself then it's a well-known
mailman
Seriously?
I support the removal of systemd (after wasting hours of my time on both it
and pulseaudio), but emailing me my password in plain text is a seriously
bad move. I think this will hurt the project.
Please stop this happening.
Regards
David
__
"frank ernest" wrote:
> Far from your experience and knowledge essentially i'm lurking.
> But, i'm wondering why no one mentions ceni whcih in my experience
> (as a user!) works fine. And even me, i was able to manage umts
> sticks using ceni.
I can't find the web site myself, maybe that's wh
20 matches
Mail list logo
