Re: [DNG] udev replacement

2017-07-27 Thread Svante Signell 
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

2017-07-27 Thread Ralph Ronnquist 
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

2017-07-27 Thread info at smallinnovations dot nl 

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

2017-07-27 Thread Enrico Weigelt, metux IT consult 

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

2017-07-27 Thread Narcis Garcia 
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

2017-07-27 Thread aitor_czr 

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]

2017-07-27 Thread Enrico Weigelt, metux IT consult 

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]

2017-07-27 Thread Didier Kryn 

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

2017-07-27 Thread Narcis Garcia 
El 27/07/17 a les 04:03, Enrico Weigelt, metux IT consult ha escrit:
> On 26.07.2017 21:15, Adam Borowski wrote:
> 
>> The future is lxc, which has some new tricks, but offers nowhere close to
>> the level of isolation openvz and vserver had.  Unprivileged containers
>> aren't bad, but still quite lacking.
> 
> Whats missing in lxc?

vzquota does in OpenVZ does what LXC doesn't.
I've tried to apply btrfs per-directory (subvolume) quotas for "dir"
containers, but them are an invisible limitation for guest.

LXC is stable, but incomplete in this area. This is the reason to
qualify OpenVZ as more mature solution.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenVZ 6 ready with Devuan 1

2017-07-27 Thread Narcis Garcia 

El 26/07/17 a les 23:15, Adam Borowski ha escrit:
> On Wed, Jul 26, 2017 at 09:02:14PM +0200, Narcis Garcia wrote:
>> Hello, documentation and containers are written and tested to Devuan 1.0
>> works as host and as guest:
>>
>> https://openvz.org/Installation_on_Debian_8
>> Container templates:
>> https://openvz.org/Download/template/precreated
>>
>> OpenVZ 6 remains as one of the most mature and stable solutions for
>> operating-system-level virtualization.
> 
> I for one had better experiences with vserver than with openvz.
> 
> Sadly both are abandoned; vserver at kernel 3.18, openvz at 3.10.  This
> actually does make a difference:
> * stretch/ascii require kernel 3.2 (assuming no systemd, otherwise 3.13)
> * buster/beowulf are likely to be bumped to 3.16
> 
> The future is lxc, which has some new tricks, but offers nowhere close to
> the level of isolation openvz and vserver had.  Unprivileged containers
> aren't bad, but still quite lacking.
> 
> 
> Meow!
> 
Unlike VServer, OpenVZ 6 stable kernels are still being released (deb
packages too):
https://openvz.org/Download/kernel/rhel6/042stab123.9

Here you have the guide for stretch/ascii:
https://openvz.org/Installation_on_Debian_9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng