On Wed, Dec 31, 2014 at 11:08:32PM -0500, Jude Nelson wrote:
> On Wed, Dec 31, 2014 at 1:55 PM, Isaac Dunham wrote:
> > mesa uses udev to load the correct hardware driver.
> > There is a fallback available if you configure it with --enable-sysfs
> > or a similar flag.
> I haven't read the mesa co
Hi Isaac,
I haven't read the mesa code yet, but it sounds like mesa uses udev to help
it (1) insert the right kernel module, and (2) load the right firmware.
udev gets its information from sysfs and/or its netlink socket, so I'd
imagine mesa uses a similar technique with the --enable-sysfs option
Hi Enrico,
> yeah, sooner or later there'll need to do a full fork.
> we should get in contact with them (I just posted a first mail onto
> their maillist).
I'd be curious to know what they have to say, since Devuan will likely ship
with udev or eudev for now. I hope it doesn't come to that--I h
Hi Enrico,
> Actually, I think we should get rid of suid at all.
As much as I would like to do this, Adam raised the excellent point that
setuid programs can't be traced or LD_PRELOAD'ed by unprivileged users.
This is critical for safe device access, since the whole point of vdev
equivocating abo
Am 2015-01-01 um 00:18 schrieb Hendrik Boom:
> On Fri, Dec 26, 2014 at 09:01:12PM +0100, Enrico Weigelt, metux IT consult
> wrote:
>> On 26.12.2014 18:59, Hendrik Boom wrote:
>>
>>> And, no, the idea isn't to share it with the rest or the world.
>>> The idea is for the so-called vendor branch to b
On Fri, Dec 26, 2014 at 09:01:12PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 26.12.2014 18:59, Hendrik Boom wrote:
>
> > And, no, the idea isn't to share it with the rest or the world.
> > The idea is for the so-called vendor branch to be shared, in this case
> > by devuan.
>
> How to
Hi Enrico,
I agree that vdev should represent as much of its state as possible through
its filesystem. This will include things like:
* the usual POSIX stuff for each device node (user, group, mode)
* OS-specific device parameters for each device node, as extended
attributes (e.g. which subsystem
IMHO, the right thing to do is something like Planet GNOME
(http://planet.gnome.org/), once 1.0 is released and more developers join. I
think it's a great way to see what's going on with a FOSS project and get in
touch with developers.
For now, I think newsletters are great. I really like DWN.
The reasons for a dynamic device manger were simple:
a) Actually makes sure that the device really exists, and is connected rather
than having a static /dev entry that is essentially worthless.
b) A dynamic manager provides a consistent way for naming device nodes, rather
than having administ
On Wed, Dec 31, 2014 at 01:44:39PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 26.12.2014 21:09, Mauro Cicio wrote:
> > I gave up on NM and I am having a great experience with wicd
>
> Just switched my Ubuntu notebook to wicd, some days ago, and it
> seems to work quite well.
>
> One thi
mesa uses udev to load the correct hardware driver.
There is a fallback available if you configure it with --enable-sysfs
or a similar flag.
HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/
On Wed, Dec 31, 2014 at 02:44:49PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 31.12.2014 13:44, Matteo Panella wrote:
> > On 31/12/2014 13:16, Enrico Weigelt, metux IT consult wrote:
> >> hmm, which ones for example ?
> >> maybe we should have a deeper look into them.
> >
> > Accounting
On Wed, Dec 31, 2014 at 11:29:15AM -0500, Walter Dnes wrote:
> On Wed, Dec 31, 2014 at 03:03:50PM +0100, Enrico Weigelt, metux IT consult
> wrote
> > On 31.12.2014 10:59, Jude Nelson wrote:
> >
> > Hi,
> >
> > > However, future entanglements with systemd and kdbus could make this
> > > much hard
Enrico Weigelt, metux IT consult wrote:
On 31.12.2014 15:44, Hendrik Boom wrote:
Never mind the mechanisms for now.
May I ask what all this complexity is supposed to accomplish?
I'd say, it's for letting the machine do the things automatically.
Probably not required for servers, but quite helpf
On Wed, Dec 31, 2014 at 03:03:50PM +0100, Enrico Weigelt, metux IT consult wrote
> On 31.12.2014 10:59, Jude Nelson wrote:
>
> Hi,
>
> > However, future entanglements with systemd and kdbus could make this
> > much harder, to the point that eudev has no choice but to diverge
> > from udev, thereb
On Wed, Dec 31, 2014 at 8:44 AM, Hendrik Boom
wrote:
> May I ask what all this complexity is supposed to accomplish?
>
Legacy support. Or retrocomputing.
More than 10 to 20 years ago we had static /dev but started to get dynamic
devices. This was seen as a HUGE problem because some competing
On 31.12.2014 15:44, Hendrik Boom wrote:
> Never mind the mechanisms for now.
> May I ask what all this complexity is supposed to accomplish?
I'd say, it's for letting the machine do the things automatically.
Probably not required for servers, but quite helpful for end user
machines, where regular
Never mind the mechanisms for now.
May I ask what all this complexity is supposed to accomplish?
-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
On 31.12.2014 10:59, Jude Nelson wrote:
Hi,
> However, future entanglements with systemd and kdbus could make this
> much harder, to the point that eudev has no choice but to diverge
> from udev, thereby increasing the maintenance burden considerably.
yeah, sooner or later there'll need to do a
On 31.12.2014 13:44, Matteo Panella wrote:
> On 31/12/2014 13:16, Enrico Weigelt, metux IT consult wrote:
>> hmm, which ones for example ?
>> maybe we should have a deeper look into them.
>
> Accounting for direct rdeps alone:
>
> (jessie-amd64)morpheus@vingilot:~$ apt-cache rdepends libudev1 lib
On 31/12/2014 13:16, Enrico Weigelt, metux IT consult wrote:
> hmm, which ones for example ?
> maybe we should have a deeper look into them.
Accounting for direct rdeps alone:
(jessie-amd64)morpheus@vingilot:~$ apt-cache rdepends libudev1 libgudev-1.0-0
libudev1
Reverse Depends:
libxwiimote2
On 26.12.2014 21:09, Mauro Cicio wrote:
> I gave up on NM and I am having a great experience with wicd
Just switched my Ubuntu notebook to wicd, some days ago, and it
seems to work quite well.
One thing which is still sucking: it uses the ugly dbus.
Perhaps I'll find some time to rewrite it using
On 27.12.2014 15:22, dima wrote:
> You can't just switch to vdev, because many packages depend on libudev. Only
> udev and eudev provide it.
hmm, which ones for example ?
maybe we should have a deeper look into them.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
___
On 31.12.2014 07:48, Jude Nelson wrote:
Hi,
> I think setuid combined with vdev presents an interesting possibility:
> what if we changed X from setuid-root to setuid-daemon (or
> setuid-nobody, or whatever), and used a variant of the above stanza to
> grant it access to the privileged device no
On 31.12.2014 01:56, Jude Nelson wrote:
Hi,
> A much more elegant solution would be to give each session its own
> /dev like you were originally saying--it would allow users to
> interact with different devices under the same name, while also
> preserving POSIX filesystem semantics.
Yes, I reall
Seems like it's stupid automation. See at time on first "Recieved"
header from bottom, it's different in every message.
Expecting new message in reply to that. Sorry in advance, but want to
check this.
P.S.: Maillist admin should be ready for such situations.
P.P.S.: http://m.memegen.com/dh7sw9.j
Hi Thiago,
I'm glad to be here :) I'm grateful for the community's feedback on vdev!
Regarding the path to take, I think going with (2) for now while keeping
option (1) on the table is probably the best strategy. Unlike vdev, eudev
is ready to go today, and already serves as a drop-in replaceme
27 matches
Mail list logo
