"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
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
__
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
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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
20 matches
Mail list logo
