Re: [DNG] udev replacement
On Fri, 2017-07-28 at 07:27 +1000, Ralph Ronnquist wrote: > Yes, I don't know why it's built, and I'm not sure what it is, but > it > came with the release building. Presumably some setting could be > changed > to avoid it, but I haven't looked into it. So far I've managed to > just > ignore it :-) > > There is no package named vdev-dbgsym in debian/control: > > > > http://auto.mirror.devuan.org/devuan/pool/main/v/vdev/ FYI: They are built automagically. See e.g. eudev's debian/control file is missing a dbgsym file too :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] udev replacement
Yes, I don't know why it's built, and I'm not sure what it is, but it came with the release building. Presumably some setting could be changed to avoid it, but I haven't looked into it. So far I've managed to just ignore it :-) regards, Ralph. aitor_czr wrote on 28/07/17 02:24: Hi Ralph, On 07/18/2017 05:54 AM, Ralph Ronnquist wrote: debhttp://auto.mirror.devuan.org/devuan/ experimental main deb-srchttp://auto.mirror.devuan.org/devuan/ experimental main There is no package named vdev-dbgsym in debian/control: http://auto.mirror.devuan.org/devuan/pool/main/v/vdev/ ??? Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenVZ 6 ready with Devuan 1
On 27-07-17 22:13, Enrico Weigelt, metux IT consult wrote: On 27.07.2017 17:35, Narcis Garcia wrote: El 27/07/17 a les 09:51, Enrico Weigelt, metux IT consult ha escrit: On 27.07.2017 06:13, Narcis Garcia wrote: vzquota does in OpenVZ does what LXC doesn't. Sure ? Proxmox somehow manages to do it (via lxc). Maybe look at their code to find out how its done. * Proxmox VE distribution is based on Systemd (since 2015) thats why i didnt upgrade yet. maybe we should also repackage proxmox w/o lennartware. Installing Proxmox on Devuan is on my todo list for next two weeks or so. I will report the results on this list. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenVZ 6 ready with Devuan 1
On 27.07.2017 17:35, Narcis Garcia wrote: El 27/07/17 a les 09:51, Enrico Weigelt, metux IT consult ha escrit: On 27.07.2017 06:13, Narcis Garcia wrote: vzquota does in OpenVZ does what LXC doesn't. Sure ? Proxmox somehow manages to do it (via lxc). Maybe look at their code to find out how its done. * Proxmox VE distribution is based on Systemd (since 2015) thats why i didnt upgrade yet. maybe we should also repackage proxmox w/o lennartware. * No "dir" storage for containers; the most thin seems to be LVM Eh ? I have that running here. (on older proxmox) --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenVZ 6 ready with Devuan 1
El 27/07/17 a les 09:51, Enrico Weigelt, metux IT consult ha escrit: > On 27.07.2017 06:13, Narcis Garcia wrote: > >> vzquota does in OpenVZ does what LXC doesn't. > > Sure ? Proxmox somehow manages to do it (via lxc). Maybe look at > their code to find out how its done. > * Proxmox VE distribution is based on Systemd (since 2015) * No Devuan templates to create Devuan containers. * No "dir" storage for containers; the most thin seems to be LVM volumes; then the space transparency comes from a separated partition~volume and not from per-directory quota. --> Very similar situation to OpenVZ 7 * Host system is 64bits only. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] udev replacement
Hi Ralph, On 07/18/2017 05:54 AM, Ralph Ronnquist wrote: debhttp://auto.mirror.devuan.org/devuan/ experimental main deb-srchttp://auto.mirror.devuan.org/devuan/ experimental main There is no package named vdev-dbgsym in debian/control: http://auto.mirror.devuan.org/devuan/pool/main/v/vdev/ ??? Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] High level language primitives [ was Please keep 32-bits alive]
On 27.07.2017 08:22, Didier Kryn wrote: At first glance at least, it means that file offsets are managed in the kernel or VFS Of course they are. That's required for any sane multiprocessing implementation. And some files/devices don't even have the notion of a current position (IOW: not seekable at all). > but they can be bypassed by pwrite(). AFAIR pwrite() doesn't change the "current" file offset; it simply ignores and bypasses it, which isn't exactly what your example does. Yes, that's an separate syscall for direct access. Simple streams (eg. tty's, pipes, stream sockets, etc) usually don't support it. Using unistd's read() and write() in C means you are dealing with low level issues; otherwise why would you bother with the complexity it introduces - not only you need to deal with buffering but also with retries when interrupted by signals. Usually you wanna care about signals - they actually mean something. The ansi stream functions might or might not make it easier - depending on your actual usecase. If you care about performance, you likely don't wanna use them. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] High level language primitives [ was Please keep 32-bits alive]
Le 26/07/2017 à 22:00, Christopher Clements a écrit :
Wouldn't this work? (no error checking of course XD)
off_t lseek(int fd, off_t offset, int whence);
ssize_t write(int fd, const void *buf, size_t count);
ssize_t pwrite(int fd, const void *buf, size_t count, off_t
offset) {
lseek(fd, offset, SEEK_SET);
return write(fd, buf, count);
}
I looked at the source code of Musl libc. Actually both write() and
pwrite() are simple wrappers to... a general-purpose system-call
wrapper. The second simply has one more argument. I didn't dig further.
At first glance at least, it means that file offsets are managed in the
kernel or VFS but they can be bypassed by pwrite(). AFAIR pwrite()
doesn't change the "current" file offset; it simply ignores and bypasses
it, which isn't exactly what your example does.
But the discussion was about low-level vs high-level programming.
Using unistd's read() and write() in C means you are dealing with low
level issues; otherwise why would you bother with the complexity it
introduces - not only you need to deal with buffering but also with
retries when interrupted by signals.
Didier
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenVZ 6 ready with Devuan 1
On 27.07.2017 06:13, Narcis Garcia wrote: vzquota does in OpenVZ does what LXC doesn't. Sure ? Proxmox somehow manages to do it (via lxc). Maybe look at their code to find out how its done. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
