Re: [DNG] Linus can no longer trust "init"

[Joachim Fahrner]

Am 2017-07-12 00:00, schrieb Dragan FOSS:

Btw...Linux Is Not UniX ;)


Then replace "unix" in my post with "un*x" ;-)
https://en.wikipedia.org/wiki/Unix-like

Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Brad Campbell]

On 12/07/17 02:35, Dragan FOSS wrote:

On 07/11/2017 05:28 PM, Enrico Weigelt, metux IT consult wrote:

make it crystal clear: fuck off the
upstream.


Do you want to say that devuan users do not need any upstream that
recommends systemd?
For example, Postgresql?
***
With PostgreSQL 9.6 or newer, it is recommended to build with
--with-systemd and use the unit file shown in the documentation...
***
https://wiki.postgresql.org/wiki/Systemd


I read that page but my interpretation is different to yours.

I read it as "If you want to run PG 9.6 or newer with systemd, use this 
option and the unit file we include. If you want to run an older version 
the recommended approach is to write a unit file using Type=forking and 
use pg_ctl for ExecStart and ExecStop."


There is absolutely nothing there that is mandating systemd in any way, 
shape or form. They've just included code to make it behave better with 
systemd if that is how you choose to build it.


Did I miss something or are you fearmongering?

Brad
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[Steve Litt]

On Tue, 11 Jul 2017 21:36:29 +0200
Joachim Fahrner  wrote:

> My understanding is, that Linux is the kernel, and GNU is the
> userland. Is systemd part of GNU/Linux? If not, how do we call a
> systemd Linux?

Merde

SteveT
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Steve Litt]

On Tue, 11 Jul 2017 20:35:45 +0200
Dragan FOSS  wrote:

> On 07/11/2017 05:28 PM, Enrico Weigelt, metux IT consult wrote:
> > make it crystal clear: fuck off the
> > upstream.  
> 
> Do you want to say that devuan users do not need any upstream that 
> recommends systemd?
> For example, Postgresql?
> ***
> With PostgreSQL 9.6 or newer, it is recommended to build with 
> --with-systemd and use the unit file shown in the documentation...
> ***
> https://wiki.postgresql.org/wiki/Systemd

I'm on the Postgres list, and after confirming the contents of your
abovereferred URL, I wrote them asking to not put in init-specific
code, and to take out what's already there.

Thanks for the info.

SteveT

Steve Litt 
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[KatolaZ]

On Tue, Jul 11, 2017 at 11:23:59PM +0200, Adam Borowski wrote:
> On Tue, Jul 11, 2017 at 05:28:39PM +0200, Enrico Weigelt, metux IT consult 
> wrote:
> > To be more practical: I'd suggest spinning off a (distro agnostic)
> > non-systemd maintenance project. We'll collect repos w/ depotterization
> > patches for all packages (and upstream releases) we're interested in.
> > And any distro can easily join in.
> > 
> > Just created a github org for that:
> > https://github.com/depotter
> > 
> > Started w/ a pretty trivial case: samba
> > https://github.com/depotter/samba
> 
> Uhm, but what's the point in _this_?  Samba does the right thing: builds
> systemdD support if and only if its configure script detected the headers
> (which can usually also be forced by --enable-foo or --disable-foo).
> 
> It's Debian/Devuan packaging that needs fixing, the upstream project is
> fine.
> 

and the de-systemd-ised packages for samba are already in Devuan, BTW.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[Rick Moen]

Quoting Joachim Fahrner (j...@fahrner.name):

> My understanding is, that Linux is the kernel, and GNU is the
> userland. Is systemd part of GNU/Linux? If not, how do we call a
> systemd Linux?

'systemd'.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[Dragan FOSS]

On 07/12/2017 12:12 AM, Adam Borowski wrote:

remote ads in etc/motd


rm /etc/update-motd.d/*

:)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[zap]

On 07/11/2017 03:36 PM, Joachim Fahrner wrote:
> My understanding is, that Linux is the kernel, and GNU is the
> userland. Is systemd part of GNU/Linux? If not, how do we call a
> systemd Linux?
>

Nah, Gnu/systemd makes more sense if your going down that road...

but I would much prefer keeping systemd out of my devuan install.


though... I do have to say, systemd pulls off quite a remarkable feat.

systemd is considered libre... yet... it is extremely poorly made for
something that is libre...

Microsoft must be pleased as is apple and google.

Yes I made a thread about this in devuan galaxy forums, but I decided I
should share this observation with the entire devuan mailing list.

;)


> Jochen
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[Adam Borowski]

On Wed, Jul 12, 2017 at 12:03:30AM +0200, Dragan FOSS wrote:
> On 07/11/2017 11:38 PM, Svante Signell wrote:
> 
> > lendows (tm)
> 
> Not alone.. :)
> http://news.softpedia.com/news/canonical-windows-10-loves-ubuntu-516922.shtml

Phoning home with all your searches via Unity Lenses, remote ads in etc/motd

Ubuntu is quite a good fit for Windows 10, yeah.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[Dragan FOSS]

On 07/11/2017 11:38 PM, Svante Signell wrote:


lendows (tm)


Not alone.. :)
http://news.softpedia.com/news/canonical-windows-10-loves-ubuntu-516922.shtml
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Dragan FOSS]

On 07/11/2017 09:11 PM, Joachim Fahrner wrote:


And what recommends Postgresql for BSD systems? "Don't install it"?

Free unix software should run on ANY unix system, not only Poetteringware.


I never tried on BSD, but on UNIX Pg runs fine :)

https://www.postgresql.org/download/solaris/

Btw...Linux Is Not UniX ;)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is GNU/Linux?

[Svante Signell]

On Tue, 2017-07-11 at 21:36 +0200, Joachim Fahrner wrote:
> My understanding is, that Linux is the kernel, and GNU is the
> userland. 
> Is systemd part of GNU/Linux? If not, how do we call a systemd Linux?

lendows (tm)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Rowland Penny]

On Tue, 11 Jul 2017 23:23:59 +0200
Adam Borowski  wrote:

> On Tue, Jul 11, 2017 at 05:28:39PM +0200, Enrico Weigelt, metux IT
> consult wrote:
> > To be more practical: I'd suggest spinning off a (distro agnostic)
> > non-systemd maintenance project. We'll collect repos w/
> > depotterization patches for all packages (and upstream releases)
> > we're interested in. And any distro can easily join in.
> > 
> > Just created a github org for that:
> > https://github.com/depotter
> > 
> > Started w/ a pretty trivial case: samba
> > https://github.com/depotter/samba
> 
> Uhm, but what's the point in _this_?  Samba does the right thing:
> builds systemdD support if and only if its configure script detected
> the headers (which can usually also be forced by --enable-foo or
> --disable-foo).

Yes, there is 'with-systemd' and 'without-systemd', not that either are
really needed, the systemd parts will only be built if the systemd
development libs are installed. I cannot see anybody trying to make it
mandatory to build Samba with systemd, but if anybody tries, I will
just 'NACK' the patches ;-)

Rowland


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Svante Signell]

On Tue, 2017-07-11 at 17:26 +, Miroslav Rovis wrote:
> 
> > Please provide version 2.88dsf-59.9+devuan2 of sysvinit-utils on
> > your
> > web page. Version 2.88dsf-59.9 is not Devuanized!! And update
> > https://dev1galaxy.org/viewtopic.php?id=1128 correspondingly.

> Do I understand correctly that only these two packages it would be
> useful that they remain posted there on my website temporarily:
> 
> -rw-r--r-- 1 210960 2017-07-11 03:30 libfdisk1_2.29.2-
> 1+devuan1_amd64.deb
> -rw-r--r-- 1 979112 2017-07-11 03:30 util-linux_2.29.2-
> 1+devuan1_amd64.deb

Yes, they are useful until the build problems are solved.

> But then, can you, or Daniel Reurich (CC'ing him too), send me then
> also i386 packages, so I can provide those in this interim before
> none of it is needed any more.

Attached in a separate mail to you only. Especially since the mailing
list attachment size is limited (as it should be)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] What is GNU/Linux?

[Joachim Fahrner]

My understanding is, that Linux is the kernel, and GNU is the userland. 
Is systemd part of GNU/Linux? If not, how do we call a systemd Linux?


Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]

[Jamey Fletcher]

> Le 11/07/2017 à 14:30, Enrico Weigelt, metux IT consult a écrit :

>  We have two detectors running. On each of them, a sophisticated
> trigger logic decides when interesting data has been seen and triggers
> 400 channels of waveform digitizers (like 400 synchronous oscilloscope
> channels). 64 bit of trigger-related meta-data are transmitted to the
> read-out subsystem by the trigger system via the waveform digitizers
> digital input. There are a few hundreds triggers per second. The data
> are collected from 5 VME masters (in 5 VME64x crates) through 1gb/s
> ethernet by a Dell Poweredge server, re-arranged, compressed and written
> to disk before further transmission to a big computer center.
> Compression must be done before writing to avoid saturate the disk
> bandwidth.

That sounds suspiciously like you're working on the LHC!  Or perhaps the
VLA...

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Joachim Fahrner]

Am 2017-07-11 20:35, schrieb Dragan FOSS:

Do you want to say that devuan users do not need any upstream that
recommends systemd?
For example, Postgresql?
***
With PostgreSQL 9.6 or newer, it is recommended to build with
--with-systemd and use the unit file shown in the documentation...
***
https://wiki.postgresql.org/wiki/Systemd


And what recommends Postgresql for BSD systems? "Don't install it"?

Free unix software should run on ANY unix system, not only 
Poetteringware.


Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Jamey Fletcher]

> I no longer feel like I can
> trust "init"

> https://lkml.org/lkml/2017/7/6/577

This is getting scary - last time I remember something along these lines,
something called git seemed to be the end result.  And I think git has
taken over the world from emacs!

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Dragan FOSS]

On 07/11/2017 05:28 PM, Enrico Weigelt, metux IT consult wrote:

make it crystal clear: fuck off the
upstream.


Do you want to say that devuan users do not need any upstream that 
recommends systemd?

For example, Postgresql?
***
With PostgreSQL 9.6 or newer, it is recommended to build with 
--with-systemd and use the unit file shown in the documentation...

***
https://wiki.postgresql.org/wiki/Systemd
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Rick Moen]

Quoting Adam Borowski (kilob...@angband.pl):

> On Mon, Jul 10, 2017 at 10:40:43PM -0700, Rick Moen wrote:
> > I do have an ongoing interest in, and gratitude for, the progress
> > towards robust OpenRC support in Devuan.  As it happens, today I 
> > was spending a while polishing up my 2016 page about converting Debian 8
> > 'Jessie' to use either OpenRC or any of the four other packaged init
> > systems other than systemd
> > (http://linuxmafia.com/faq/Debian/openrc-conversion.html) -- fixing a
> > few nits and noting options for getting a _better_ OpenRC than the
> > half-assed Debian package.
> 
> The package in jessie is meh, but do you have any particular criticism about
> the ones in stretch and unstable?  They're not ideal, but anything that I
> noticed is quite cosmetic.

Honestly, I've not yet had a chance to try those out, having been
stretched too thin, lately, by $DAYJOB and other matters.  So, I've been
lately relying on details provided by others.  When I have a chance, I 
will indeed see about a fresh experiment using Stretch and its official
packages (before, no doubt, fooling around with it and transforming it
past recognition ;-> ).

Anyway, if you see any blunders I made in that page, I'd be grateful to
hear about it, as always.

FWIW, I also long past stopped wanting to stick with Official Debian,
anyway.  The systemd / freedestkop.org nuisance is just one more reason
to seek better ways to install / maintain a debianesque system.  Back a
in the early 2000s, I got so tired of hearing people complain about
the Official Debian d-i images (with the implication that it was the
only way to install a Debian-type system) that I compiled a list of
alternative installer images / methods, by way of response:
http://linuxmafia.com/faq/Debian/installers.html
(It's now a decade out of date.)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Miroslav Rovis]

On 170711-18:12+0200, Svante Signell wrote:
> On Tue, 2017-07-11 at 15:35 +, Miroslav Rovis wrote:
> > 
> > > > > 
> > > > > $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \
> > > > 
> > > > This one is not OK, see below. This is the Debian (unpatched
> > > > version)
> 
> > > > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and
> > > > you get
> > > > them by adding to sources.list: (+ apt-get update)
> > > > sysvinit-core
> > > > sysvinit-utils
> > > > initscripts
> > > > bootlogd (optional)
> 
> > are needed to install OpenRC, get them at:
> > https://lists.dyne.org/lurker/message/20170711.035614.33ea6395.en.htm
> > l
> 
> Please provide version 2.88dsf-59.9+devuan2 of sysvinit-utils on your
> web page. Version 2.88dsf-59.9 is not Devuanized!! And update
> https://dev1galaxy.org/viewtopic.php?id=1128 correspondingly.
I understand. And will follow your kind and urgent orders, Sir! :)
( except that I'm slow, been so slow all this time... But also, have a look at 
how thoroughly I work! Just look!
In this file:
/var/lib/apt/lists/packages.devuan.org_devuan_dists_ascii-proposed_main_binary-amd64_Packages
I just found your name. What're you doing in there ;) ... Sorry, no more jokes.
( I wish I were a developer... Maybe some day... )

But details are nice to paste now, from that file, again:

$ cat 
/var/lib/apt/lists/packages.devuan.org_devuan_dists_ascii-proposed_main_binary-amd64_Packages
...

Package: sysvinit-utils
Source: sysvinit
Version: 2.88dsf-59.9+devuan2
Essential: yes
Installed-Size: 137
Maintainer: Daniel Reurich ,
Svante Signell 
Architecture: amd64
Replaces: initscripts (<< 2.88dsf-59.5)
Depends: libc6 (>= 2.14), init-system-helpers (>= 1.25~), util-linux (>> 
2.28-2~)
Breaks: systemd (<< 215)
Description: System-V-like utilities
 This package contains the important System-V-like utilities.
 .
 Specifically, this package includes:
 killall5, pidof
Multi-Arch: foreign
Homepage: http://savannah.nongnu.org/projects/sysvinit
Section: admin
Priority: required
Filename: pool/main/s/sysvinit/sysvinit-utils_2.88dsf-59.9+devuan2_amd64.deb
Size: 67750
MD5sum: ec5f996f4407c0c170c365a116a8c17a
SHA1: a6aa73e620fec56119e0e75168a03b8f429d2513
SHA256: acaf8504b3f54d20611d98107670c26aaa5bb2a9c36f85d528bff54c5fe1f36d

...
$ 

The above paste is featuring:

Filename: pool/main/s/sysvinit/sysvinit-utils_2.88dsf-59.9+devuan2_amd64.deb

(the maybe not necessary to post elsewhere because it is in ascii-proposed
repo, see below, file)

Right, but it then, it then is really not even needed to be replaced on my
website.
But only removed, if I understand correctly. and explained on Dev1Galaxy OpenRC
topic of mine, explained there why it is removed... (which explanation will
consist of just the link to this email, when it is on the web),.

I really set up that temporary dir on my website only because I wanted people
to have those packages that one can only get if they would only be able to get
it from you, or Daniel Reurich or from me (now) by email.

This would be much cleaner, and it is no fuss like sending email attachments, I
thought...

Do I understand correctly that only these two packages it would be useful that
they remain posted there on my website temporarily:

-rw-r--r-- 1 210960 2017-07-11 03:30 libfdisk1_2.29.2-1+devuan1_amd64.deb
-rw-r--r-- 1 979112 2017-07-11 03:30 util-linux_2.29.2-1+devuan1_amd64.deb

But then, can you, or Daniel Reurich (CC'ing him too), send me then also i386
packages, so I can provide those in this interim before none of it is needed
any more.

Pls., guys, do correct me if I'm wrong in any of my understanding above.
 
> All the above packages are available at ascii-proposed:
> deb http://packages.devuan.org/devuan ascii-proposed main
> 
> Depending on your pinning
> apt-get install ... or
> apt-get install -t ascii-proposed ...
> sysvinit-core
> sysvinit-utils
> initscripts
> bootlogd (optional)

I see.

Regards!
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]

[Didier Kryn]

Le 11/07/2017 à 14:30, Enrico Weigelt, metux IT consult a écrit :

On 05.07.2017 23:30, Didier Kryn wrote:

> And there are a whole menagerie of addressing and transfer 
protocols, > including chained dma transfers


Especially things like DMA are naturally kernel domain. I wouldn't ever
allow any direct access to dma controllers from userland.



The system isn't a server open to the public. It's a kind of 
industrial process (though it's for fundamental research). Only a 
limited number of users have an account on the hosts and only members of 
the vme group are given permission to access the devices associated to 
VME. In production, only one user runs a few applications (essentially 
one), some automatically on reboots and some under remote control. A 
whole library written in Ada comes between the applications and the 
driver; it adds a sufficient level of abstraction and a few facilities 
and takes care of safety controls. The applications are all written in 
Ada, of course. We don't fear malevolent actions, and, IMHO, safety is 
better granted by an Ada library than by any driver written in C.


> In our case it is waveform digitizers and the interaction is so > 
complex that it cannot be done in a kernel module


What exactly is so complex about that ? Smells like a typical task
for IIO to me.


The waveform digitizers boards have 8 channels of 8-bit 500MSPS 
flash-ADCs, each with 1024 buffers of 4096 bytes (samples). The 
(external) trigger comes after the data has been recorded; the many 
buffers grant asynchronism between data taking and read-out. The VME 
master can skip buffers (events) or read them, totally or partially. The 
VME master (the single-board computer) monitors the status of buffers 
and must free them before the digitizers can overwrite them. Before data 
transfer, the range of samples from the selected channels are arranged 
into a special buffer of the WFD boards, following detailed instructions 
from the VME master, before they are transferred using the 2eSST320 
protocol (currently the fastest VME64x protocol). The amount of data 
transferred for each buffer depends on external conditions comming from 
a 16-bit binary input present on each board and part of meta-data 
associated to each trigger; the VME master decides what to do based on 
metadata assembled from 4 WFD boards. These metadata are generated by a 
set of very fast measurements associated to the triggering system 
(another subsystem of our set-up).



Some others consider there should be one driver per VME device you

> want to talk to, on top of the raw VME driver.

Exactly.

These people only ever had to deal with simplistic devices. Gabriel 
Paubert has never seen an application transfering more than a few 
bytes, while we are transferring data at 320MB/s.


Those kind of things usually involve proper timing, caring about
caching, etc, etc. Natural kernel domain.


It's a little more complicated, as explained above :-)



Which absurdities, exactly ?
 Bus errors were not reported to the application but instead 
caused a message to syslog! This makes it hard to use; or your 
application should monitor the log files!


Yes, that's hackish, of course.

 This isn't the case here. AFAIU, their BSP contains a VME driver 
and a device tree. I think it's all GPL. Their buzyness is to send 
hardware and they make sure their clients can use it.


Looks like your vendor is an exception.

 These are SBCs with everything soldered: VME, flash memory, 
UARTs, USB hub, Sata controllers, Ethernet ports etc... And you just 
plug it into a VME crate. It makes no sense to develop a board like 
this to use a dozen of them. We made the digitizers and it was 
already a big deal for our small team.


 Could you develop what is IIO for DAQ devices? 


What's the difference between you digitizes and usual DAQ devices ?
What do you actually do with them ?

Some clear requirements on the table, please ;-)


We have two detectors running. On each of them, a sophisticated 
trigger logic decides when interesting data has been seen and triggers 
400 channels of waveform digitizers (like 400 synchronous oscilloscope 
channels). 64 bit of trigger-related meta-data are transmitted to the 
read-out subsystem by the trigger system via the waveform digitizers 
digital input. There are a few hundreds triggers per second. The data 
are collected from 5 VME masters (in 5 VME64x crates) through 1gb/s 
ethernet by a Dell Poweredge server, re-arranged, compressed and written 
to disk before further transmission to a big computer center. 
Compression must be done before writing to avoid saturate the disk 
bandwidth.





Is it something allowing to write drivers in user space?


What kind of drivers do you wanna have in userland ? And why ?



I think what I would do now would be to mmap() the VME bridge from 
userspace right away (I've read it's possible with /dev/mem). This way 
it would work with any kernel release 

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Adam Borowski]

On Mon, Jul 10, 2017 at 10:40:43PM -0700, Rick Moen wrote:
> I do have an ongoing interest in, and gratitude for, the progress
> towards robust OpenRC support in Devuan.  As it happens, today I 
> was spending a while polishing up my 2016 page about converting Debian 8
> 'Jessie' to use either OpenRC or any of the four other packaged init
> systems other than systemd
> (http://linuxmafia.com/faq/Debian/openrc-conversion.html) -- fixing a
> few nits and noting options for getting a _better_ OpenRC than the
> half-assed Debian package.

The package in jessie is meh, but do you have any particular criticism about
the ones in stretch and unstable?  They're not ideal, but anything that I
noticed is quite cosmetic.

I'd be very interested in making it full-assed.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] 404.

[G.W. Haywood]

Hello yet again,

On Tue, 11 Jul 2017, G.W. Haywood wrote:


... back with more dumb questions presently.


laptop3:/opt/ged/git/devuan/pkg_openvpn/openvpn$ >>> d1h link 
g...@git.devuan.org:Ged/openvpn
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
The authenticity of host 'git.devuan.org (188.165.53.255)' can't be established.
ECDSA key fingerprint is a8:8d:25:ac:eb:84:80:a4:52:05:84:27:23:de:8c:ce.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'git.devuan.org,188.165.53.255' (ECDSA) to the list 
of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

?

--

73,
Ged.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] 404.

[G.W. Haywood]

Hello again,

On Tue, 11 Jul 2017, KatolaZ wrote:


Is the step "go to https://git.devuan.org/devuan/devuan-maintainers;
mentioned in the d1h guide? :)


Ah, I see.  Thanks.  Well, it sort of is mentioned, yes. :)  It says:

" * a working account on git.devuan.org"

and I was trying to find out if it was working.  At least that's my
story, and I'm sticking to it. :)

I'll press on - doubtless back with more dumb questions presently.

--

73,
Ged.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Svante Signell]

On Tue, 2017-07-11 at 15:35 +, Miroslav Rovis wrote:
> 
> > > > 
> > > > $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \
> > > 
> > > This one is not OK, see below. This is the Debian (unpatched
> > > version)

> > > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and
> > > you get
> > > them by adding to sources.list: (+ apt-get update)
> > > sysvinit-core
> > > sysvinit-utils
> > > initscripts
> > > bootlogd (optional)

> are needed to install OpenRC, get them at:
> https://lists.dyne.org/lurker/message/20170711.035614.33ea6395.en.htm
> l

Please provide version 2.88dsf-59.9+devuan2 of sysvinit-utils on your
web page. Version 2.88dsf-59.9 is not Devuanized!! And update
https://dev1galaxy.org/viewtopic.php?id=1128 correspondingly.

All the above packages are available at ascii-proposed:
deb http://packages.devuan.org/devuan ascii-proposed main

Depending on your pinning
apt-get install ... or
apt-get install -t ascii-proposed ...
sysvinit-core
sysvinit-utils
initscripts
bootlogd (optional)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Miroslav Rovis]

On 170711-09:13-0400, zap wrote:
> 
> 
> On 07/11/2017 06:01 AM, Svante Signell wrote:
> > On Tue, 2017-07-11 at 03:56 +, Miroslav Rovis wrote:
> >> On 170710-23:39+0200, Svante Signell wrote:
> >>> On Mon, 2017-07-10 at 14:12 +, Miroslav Rovis wrote:
>  Hi Svante and everybody!
> 
>  (and zap, to whom you right as second person in the email I'm
>  replying to. zap
>  might give useful advice, since he --later-- reported he
>  successfully
>  installed
>  OpenRC)
> 
>  Svante, I'm taking your suggestion in the other thread some three
>  days ago now,
>  or so.
> 
>  I want to try OpenRC in my Devuan.
> >>> Ok, let's see if I can help you.
> >> Svante, I got packages from zap. zap, I got your email, it's just the
> >> Lurker
> >> that is limited to 40k (which means you can only send some 30k
> >> (because mail
> >> encodes in base64) in one email
> > As written by later mails on this thread, the email limit should stay
> > as it is. Larger files should be uploaded and hosted somewhere to
> > download.
> >
> >> ...but I got them:
> >>
> >> $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \
> > This one is not OK, see below. This is the Debian (unpatched version)
> >
> > Did you see my mail? I can send you the packages
> > libfdisk1 2.29.2-1+devuan1
> > util-linux2.29.2-1+devuan1
>  I believe/hope all that is necessary is now in these repos that
>  you
>  wrote below (but is it so?):
> > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and you get
> > them by adding to sources.list: (+ apt-get update)
> > sysvinit-core
> > sysvinit-utils
> > initscripts
> > bootlogd (optional)
> My bad, I forgot a few important packages to mention... xD
The bootlogd is only suggested.

Ah, first thing to say is: I've successfully installed and rebooted a couple of
times each: my clone (which I use also for testing, and which is the only that
sees ever any internet), and my master Air-Gap system.

And maybe the second thing to say is. If anyone needs the packages that
(
if those are, and I think they are; they worked for me
)
are needed to install OpenRC, get them at:
https://lists.dyne.org/lurker/message/20170711.035614.33ea6395.en.html
They are also hashed by me in my email in this very thread that we are writing
our discussions about OpenRC --under bad subject, but it's really too late now
to correct that-- I think its previous mail of mine that I sent, or whatever,
my Palemoon still crashes unpredictably, and can't open huge threads, and that
one is a huge thread where this new discussion belongs to...

The instructions how to get the packages are:
OpenRC installation in Devuan Ascii
https://dev1galaxy.org/viewtopic.php?id=1128#p3286

And of course, you can also get them directly:
https://www.croatiafidelis.hr/foss/Devuan-OpenRC/

Pls., guys, I think all went correctly, but I think I should leave the report
there, at:
( same topic as linked a few lines up )
https://dev1galaxy.org/viewtopic.php?id=1128

and not repeat it here...

> 
>  deb http://packages.devuan.org/devuan ascii-proposed main
>  I hope that is fine.
> >>> Yes you need that line for the latest version of sysvinit* and
> >>> initscripts (2.88dsf-59.9+devuan2)
> >> sysvinit-utils_2.88dsf-59.9_amd64.deb is what I got from zap (see
> >> above)
> > You should apt-get download sysvinit-utils and then (as I wrote to zap)
> > (version 2.88dsf-59.9+devuan2, not 2.88dsf-59.9):
> >
> > dpkg -i libfdisk1_2.29.2-1+devuan1_i386.deb 
> > util-linux_2.29.2-1+devuan1_i386.deb 
> > sysvinit-utils_2.88dsf-59.9+devuan2_i386.deb
> >
> > (in one line, the mailer might wrap)
> >
> > Then you can apt-get install -s openrc and only sysvinit-rc will be
> > removed in addition to libeinfo1 librc1 openrc (0.23-1+b1) being
> > installed.
> > ___

Thanks Svante, thanks zap, thanks also Rick Moen (I even mentioned you in that
Dev1Galaxy topic linked above when I saw full shouting at me that ugly message
that you wrote about), and Adam Borowski...

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Enrico Weigelt, metux IT consult]

On 11.07.2017 15:02, Simon Hobson wrote:

But it clear from reading comments on any article mentioning 

> systemd that a great many people really have no idea why
> they should care.

Just pointing out some fundamental problems (especially on bug
or problem reports) and let them learn by own experience.


it's not uncommon to see one comment saying why one person

> doesn't want to run it (perhaps to do with debuggability
when it won't boot), to get a reply along the lines 

> if "I use  and it works just fine -
> what's the problem ?"

It's the same as "windows run fine". Maybe for them it really is,
I couldn't care less. Just ignore these folks - they won't help
us in any way - we don't need them, they're just irrelevant.


So there really is a problem to solve there.


It's their problem, not yours, not mine. So, just don't care,
unless they really ask for help. And if they do, there's a
simple and efficient answer: get rid of systemd. Period.


NAK. 1) is enought.
In the past we fought bigger dragons, eg. getting free from M$.


I don't think that's comparable.


You're right. The MS dragon was magnitudes bigger.


Optional. We patch out the crap for packages we need, and drop those we
don't need.


But it's a lot less ongoing effort to keep that support in upstream. 


Yes, that's why we'd regularily post our patches to upstreams
(more precisely: let some scripts do that - don't waste precious
life time on dumb people)

Yes you can patch it, but the more embedded systemd becomes, the 

> more patching is needed.

Maybe, maybe not, we'll see. Challenge accepted.
And it only affects packages we really need, anyways.

Do we have any real trouble maker on the table right now ?
If so, do we need it or is it just useless toy like gnome3 ?

Keep/get a critical mass so that upstream devs see a case for 

> keeping the non-systemd stuff, and maintaining the non-systemd distro
> is less work.

In worst case, we can become our own upstream. Of course taking folks
from all the other non-systemd distros aboard.


Not, quite. Just rapair and support the original API - drop the
systemd crap entirely.


I think you've missed the point. "Repair and support the original API"

> isn't an option if the upstream dev wants his package to be runable
> on a systemd system

Seems you missed my point, so to make it crystal clear: fuck off the
upstream. Collect the folks from the other distros, fork off and also
make big noise about that. Including using social technics to make those
upstreams feel really bad about their choice (at that point, we're in
the political sphere, so use political tools).

And the team behind systemd have shown that they have no intension of 

> fixing anything when they can better support their aims by deprecating

it and bringing something new (and in their eyes, improved) to the table.


We all know that, had been said a thousand times, no need to repeat it
again and again. We all know that Lennartism is an ugly totalitarian
ideology. But as long as they're not making chaos in the streets and
start actually hurting people, we can easily ignore them (and even if
they did, we'd take care of that). Those psychopaths live from our
attention (because they just don't have anything else in their petty
miserable lifes) - don't give them this energy anymore, and they'll
sooner or later die. Alone.

The (few) Lennartists are not the folks we should care about, just like
w/ Fascists, Socialists, Satanists, and all the other insane ideologies.
Instead we should care about their blind followers. And most of them
only learn by pain.


If the systemd devs showed the sort of attitude to the rest of the world


If we ever invest energy into these folks, then make they look as what
they really are: ridiculous petty psychopaths. We should never engage
them, just laugh about them.


It's the very fact that they appear to be forcing this binary choice

> (systemd or nothing) is why we're having this discussion.

No, it's the fact that they have so many dumb, brainwashed followers.


That's why I suggest it's important to keep the upstream devs onside


Depends on what you exactly mean by "onside". If it's about feeding them
with bugfixes (and systemd dependency *is* a bug, a critical one), then
we aggree. But we should make it crystal clear, that we'll do whatever
it takes to keep our systems free from Lennartware. Especially including
the option of a fork. (and that, of course, also includes eradicating
libsystemd0)

Yet again, we're in the area of politicts. Actually on the geopolitical
scale. So, we gotta act like that. We'll defend our homeland by any
means necessary - no surrender, no retreat.

> Over time that will change - systemd will get deeper and deeper into
packages, and it will get harder and harder to remove it, and to add 

> in the now missing parts.

On any such patch, fire back. And don't miss a chance to put lots of
salt in the wound.

To be more practical: I'd suggest spinning off a (distro 

Re: [DNG] Linus can no longer trust "init"

[Hendrik Boom]

On Tue, Jul 11, 2017 at 02:10:04PM +0200, Enrico Weigelt, metux IT consult 
wrote:
> On 11.07.2017 13:55, Simon Hobson wrote:
> 
> 
> >3) Explain (in rational, technical, non-political) terms why people 
> >should care that there is a choice - and why we think they would be 
> >wise to take it.
> 
> I wouldn't waste time on that. They have to learn by themselves -
> preaching doesn't help.

There are those who feel uneasy, but need the rhetoric to know just what 
it is that make them uneasy.  They are the ones the ratonal, 
technical, nonpolitical terms will reach.

Conclusions about such matters are often obvious only when they have 
been pointed out.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Arnt Karlsen]

On Tue, 11 Jul 2017 14:02:47 +0100, Simon wrote in message 
<98028782-f385-412e-aeab-2edf14663...@thehobsons.co.uk>:

> "Enrico Weigelt, metux IT consult"  wrote:
> 
> >> 3) Explain (in rational, technical, non-political) terms why
> >> people should care that there is a choice - and why we think they
> >> would be wise to take it.
> > 
> > I wouldn't waste time on that. They have to learn by themselves -
> > preaching doesn't help.
> 
> Preaching is probably the wrong word to have used. But it clear from
> reading comments on any article mentioning systemd that a great many
> people really have no idea why they should care. it's not uncommon to
> see one comment saying why one person doesn't want to run it (perhaps
> to do with debuggability when it won't boot), to get a reply along
> the lines of "I use  and it works just
> fine - what's the problem ?" So there really is a problem to solve
> there. People are using it, many don't know, but of those who are,
> they don't see why it's a problem (and in particular, why someone
> should want to/be able to not use it) because "it works" for them.


..we _could_ "preach" by testing for systemd features and throw warning
screens in the faces of the downstream etc users, and offer info links
(and/or buttons) and an "I know WTF I am doing."-button to click thru.


> >> Without 2 and 3, there won't be large scale adoption of the
> >> alternatives
> > 
> > NAK. 1) is enought.
> > In the past we fought bigger dragons, eg. getting free from M$.
> 
> I don't think that's comparable.
> 
> >> - and without that, there is distinctly less incentive for the
> >> upstream devs to keep support for the alternatives.
> > 
> > Optional. We patch out the crap for packages we need, and drop
> > those we don't need.
> 
> But it's a lot less ongoing effort to keep that support in upstream.


..sometimes, with certain people, this is not a viable option, 
that's _when_ we need to fork these packages.


> Yes you can patch it, but the more embedded systemd becomes, the more
> patching is needed. Keep/get a critical mass so that upstream devs
> see a case for keeping the non-systemd stuff, and maintaining the
> non-systemd distro is less work. I cannot see a case for saying that
> (in total) it's less work to patch a package after the fact than it
> would be to maintain that package in a compatible state to start with.
> 
> >> do they keep support for the old API ? To do so means more work - 
> > > effectively they have to maintain two bits of code everywhere
> >> they use that function, and that means more work. 
> > 
> > Not, quite. Just rapair and support the original API - drop the
> > systemd crap entirely.
> 
> I think you've missed the point. "Repair and support the original
> API" isn't an option if the upstream dev wants his package to be
> runable on a systemd system - because systemd dev policy appears to
> be deliberately forcing that binary choice of "systemd APIs or
> nothing" into anything it can.


..that's _why_ these upstream packages needs to be forked, by us.


> And the team behind systemd have shown
> that they have no intension of fixing anything when they can better
> support their aims by deprecating it and bringing something new (and
> in their eyes, improved) to the table. If the systemd devs showed the
> sort of attitude to the rest of the world (devs and users) that
> others espouse, then there'd be no problem. It's the very fact that
> they appear to be forcing this binary choice (systemd or nothing) is
> why we're having this discussion.
> 
> That's why I suggest it's important to keep the upstream devs onside
> - because it's a lot easier to keep support for the traditional APIs
> etc as an integral part of a package than it is to go through
> patching after the fact. And it's easier to keep them onside if we
> can show that there's a large (ie significant) user base for the
> non-systemd version.
> 
> At present it's (I assume) fairly easy to patch out systemd-isms as
> it's not been around long enough to get major tentacles into most
> stuff. Over time that will change - systemd will get deeper and
> deeper into packages, and it will get harder and harder to remove it,
> and to add in the now missing parts.


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Edward Bartolo]

Quote: "gnome 3 is crap"

Nah, Gnome 3 is a The Brand that must be shoved down people's throats.
Systemd, is the 'invisible' 'string puller' that lurks behind the
scenes.

-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
If you cannot make abstructions about details you do not understand
the concepts underlying them.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[zap]

gnome 3 is crap, need I say more?


On 07/11/2017 07:39 AM, Enrico Weigelt, metux IT consult wrote:
> On 10.07.2017 23:10, Steve Litt wrote:
>
>> Remember, we're fighting a huge and well funded opponent, possessing
>> the money to throw at programmers to keep the systemd mess running, as
>> well as money for publicity to counter common sense with neverending
>> bulldroppings. Seen in that context, what we've accomplished is a
>> miracle.
>
> We don't need to fight anything. Just concentrate on the stuff *we*
> need (seriously, does anybobdy here need gnome3 ?) and patch out the
> crap when neccessary.
>
> And just not caring about that lennartware crap at all. Not even wasting
> time w/ debates about that crap, over and over again. (and yes: that's
> really annying me)
>
> Why do you waste your precious lifetime w/ lennartware at all ?
>
>
> --mtx
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[zap]

On 07/11/2017 06:01 AM, Svante Signell wrote:
> On Tue, 2017-07-11 at 03:56 +, Miroslav Rovis wrote:
>> On 170710-23:39+0200, Svante Signell wrote:
>>> On Mon, 2017-07-10 at 14:12 +, Miroslav Rovis wrote:
 Hi Svante and everybody!

 (and zap, to whom you right as second person in the email I'm
 replying to. zap
 might give useful advice, since he --later-- reported he
 successfully
 installed
 OpenRC)

 Svante, I'm taking your suggestion in the other thread some three
 days ago now,
 or so.

 I want to try OpenRC in my Devuan.
>>> Ok, let's see if I can help you.
>> Svante, I got packages from zap. zap, I got your email, it's just the
>> Lurker
>> that is limited to 40k (which means you can only send some 30k
>> (because mail
>> encodes in base64) in one email
> As written by later mails on this thread, the email limit should stay
> as it is. Larger files should be uploaded and hosted somewhere to
> download.
>
>> ...but I got them:
>>
>> $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \
> This one is not OK, see below. This is the Debian (unpatched version)
>
> Did you see my mail? I can send you the packages
> libfdisk1 2.29.2-1+devuan1
> util-linux2.29.2-1+devuan1
 I believe/hope all that is necessary is now in these repos that
 you
 wrote below (but is it so?):
> No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and you get
> them by adding to sources.list: (+ apt-get update)
> sysvinit-core
> sysvinit-utils
> initscripts
> bootlogd (optional)
My bad, I forgot a few important packages to mention... xD


 deb http://packages.devuan.org/devuan ascii-proposed main
 I hope that is fine.
>>> Yes you need that line for the latest version of sysvinit* and
>>> initscripts (2.88dsf-59.9+devuan2)
>> sysvinit-utils_2.88dsf-59.9_amd64.deb is what I got from zap (see
>> above)
> You should apt-get download sysvinit-utils and then (as I wrote to zap)
> (version 2.88dsf-59.9+devuan2, not 2.88dsf-59.9):
>
> dpkg -i libfdisk1_2.29.2-1+devuan1_i386.deb 
> util-linux_2.29.2-1+devuan1_i386.deb 
> sysvinit-utils_2.88dsf-59.9+devuan2_i386.deb
>
> (in one line, the mailer might wrap)
>
> Then you can apt-get install -s openrc and only sysvinit-rc will be
> removed in addition to libeinfo1 librc1 openrc (0.23-1+b1) being
> installed.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Simon Hobson]

"Enrico Weigelt, metux IT consult"  wrote:

>> 3) Explain (in rational, technical, non-political) terms why people should 
>> care that there is a choice - and why we think they would be wise to take it.
> 
> I wouldn't waste time on that. They have to learn by themselves -
> preaching doesn't help.

Preaching is probably the wrong word to have used. But it clear from reading 
comments on any article mentioning systemd that a great many people really have 
no idea why they should care. it's not uncommon to see one comment saying why 
one person doesn't want to run it (perhaps to do with debuggability when it 
won't boot), to get a reply along the lines of "I use  and it works just fine - what's the problem ?"
So there really is a problem to solve there. People are using it, many don't 
know, but of those who are, they don't see why it's a problem (and in 
particular, why someone should want to/be able to not use it) because "it 
works" for them.

>> Without 2 and 3, there won't be large scale adoption of the alternatives
> 
> NAK. 1) is enought.
> In the past we fought bigger dragons, eg. getting free from M$.

I don't think that's comparable.

>> - and without that, there is distinctly less incentive for the upstream devs 
>> to keep support for the alternatives.
> 
> Optional. We patch out the crap for packages we need, and drop those we
> don't need.

But it's a lot less ongoing effort to keep that support in upstream. Yes you 
can patch it, but the more embedded systemd becomes, the more patching is 
needed. Keep/get a critical mass so that upstream devs see a case for keeping 
the non-systemd stuff, and maintaining the non-systemd distro is less work.
I cannot see a case for saying that (in total) it's less work to patch a 
package after the fact than it would be to maintain that package in a 
compatible state to start with.

>> do they keep support for the old API ? To do so means more work - 
> > effectively they have to maintain two bits of code everywhere
>> they use that function, and that means more work. 
> 
> Not, quite. Just rapair and support the original API - drop the
> systemd crap entirely.

I think you've missed the point. "Repair and support the original API" isn't an 
option if the upstream dev wants his package to be runable on a systemd system 
- because systemd dev policy appears to be deliberately forcing that binary 
choice of "systemd APIs or nothing" into anything it can. And the team behind 
systemd have shown that they have no intension of fixing anything when they can 
better support their aims by deprecating it and bringing something new (and in 
their eyes, improved) to the table.
If the systemd devs showed the sort of attitude to the rest of the world (devs 
and users) that others espouse, then there'd be no problem. It's the very fact 
that they appear to be forcing this binary choice (systemd or nothing) is why 
we're having this discussion.

That's why I suggest it's important to keep the upstream devs onside - because 
it's a lot easier to keep support for the traditional APIs etc as an integral 
part of a package than it is to go through patching after the fact. And it's 
easier to keep them onside if we can show that there's a large (ie significant) 
user base for the non-systemd version.

At present it's (I assume) fairly easy to patch out systemd-isms as it's not 
been around long enough to get major tentacles into most stuff. Over time that 
will change - systemd will get deeper and deeper into packages, and it will get 
harder and harder to remove it, and to add in the now missing parts.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Miles Fidelman]

On 7/11/17 7:55 AM, Simon Hobson wrote:

"Enrico Weigelt, metux IT consult"  wrote:


We don't need to fight anything. Just concentrate on the stuff *we*
need (seriously, does anybobdy here need gnome3 ?) and patch out the
crap when neccessary.

And just not caring about that lennartware crap at all. Not even wasting
time w/ debates about that crap, over and over again. (and yes: that's
really annying me)

Why do you waste your precious lifetime w/ lennartware at all ?

There are (IMO) three things needed :

1) Have an alternative - ie Devuan. In that, I salute those who are actually 
doing the hard stuff I wouldn't know where to start with.

2) Make people aware that there is an alternative.

3) Explain (in rational, technical, non-political) terms why people should care 
that there is a choice - and why we think they would be wise to take it.

Without 2 and 3, there won't be large scale adoption of the alternatives - and 
without that, there is distinctly less incentive for the upstream devs to keep 
support for the alternatives.

As has been mentioned before, part of the "battle plan" for systemd seems to be to keep taking more 
and more "standard stuff", deprecate it, and introduce new systemd versions with a new API. Thus, a 
package they needs to run on a systemd infested system has to support the "new improved" API.
This means that the dev now faces a choice - do they keep support for the old API ? To do 
so means more work - effectively they have to maintain two bits of code everywhere they 
use that function, and that means more work. If they perceive that "hardly 
anyone" still needs the old API - then there's a temptation to drop the old code, or 
stop maintaining it. If that happens, then the job of maintaining that package in a 
non-systemd distro becomes harder.

Ideally, projects like Devuan need to get enough users that they can entice 
package maintainers over from Debian. Wouldn't it be wonderful if Devuan were 
able to take the lead, and Debian end up having to port packages from it - yes 
that's pie in the sky thinking at the moment, but if you don't have ambition 
then ...


So yes, I agree that "discussing" it time and time again (especially in a "preaching 
to the converted" forum) isn't helpful - but just ignoring it isn't going to work either.

___

Exactly.  The issue isn't whether we have systemd-free distros - there 
are more than Devuan (gentoo, the BSDs come to mind) - it's how the 
developer community moves forward.  Do we start seeing important 
packages come out as requiring systemd.




--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]

[Enrico Weigelt, metux IT consult]

On 05.07.2017 23:30, Didier Kryn wrote:

> And there are a whole menagerie of addressing and transfer protocols, 
> including chained dma transfers


Especially things like DMA are naturally kernel domain. I wouldn't ever
allow any direct access to dma controllers from userland.

> In our case it is waveform digitizers and the interaction is so > 
complex that it cannot be done in a kernel module


What exactly is so complex about that ? Smells like a typical task
for IIO to me.


Some others consider there should be one driver per VME device you

> want to talk to, on top of the raw VME driver.

Exactly.

These people only ever had to deal with simplistic devices. Gabriel 
Paubert has never seen an application transfering more than a few bytes, 
while we are transferring data at 320MB/s.


Those kind of things usually involve proper timing, caring about
caching, etc, etc. Natural kernel domain.


Which absurdities, exactly ?
 Bus errors were not reported to the application but instead caused 
a message to syslog! This makes it hard to use; or your application 
should monitor the log files!


Yes, that's hackish, of course.

 This isn't the case here. AFAIU, their BSP contains a VME driver 
and a device tree. I think it's all GPL. Their buzyness is to send 
hardware and they make sure their clients can use it.


Looks like your vendor is an exception.

 These are SBCs with everything soldered: VME, flash memory, UARTs, 
USB hub, Sata controllers, Ethernet ports etc... And you just plug it 
into a VME crate. It makes no sense to develop a board like this to use 
a dozen of them. We made the digitizers and it was already a big deal 
for our small team.


 Could you develop what is IIO for DAQ devices? 


What's the difference between you digitizes and usual DAQ devices ?
What do you actually do with them ?

Some clear requirements on the table, please ;-)


Is it something allowing to write drivers in user space?


What kind of drivers do you wanna have in userland ? And why ?


--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Enrico Weigelt, metux IT consult]

On 11.07.2017 13:55, Simon Hobson wrote:


There are (IMO) three things needed : >
1) Have an alternative - ie Devuan. 


And there're other non-systemd-Distros out there. Just collaborate with
them and ignore the others. (we could also set up some tiny patch-
sending bots that penetrate nasty upstreams w/ patches ...)


In that, I salute those who are actually doing the hard stuff I wouldn't know 
where to start with.


ACK.


2) Make people aware that there is an alternative.


A bit media appearance is fine, but I wouldn't waste too much resources
with that. Better be present on various upstream maillists and post
systemd-removing patches there.


3) Explain (in rational, technical, non-political) terms why people should care 
that there is a choice - and why we think they would be wise to take it.


I wouldn't waste time on that. They have to learn by themselves -
preaching doesn't help.


Without 2 and 3, there won't be large scale adoption of the alternatives


NAK. 1) is enought.
In the past we fought bigger dragons, eg. getting free from M$.


- and without that, there is distinctly less incentive for the upstream devs to 
keep support for the alternatives.


Optional. We patch out the crap for packages we need, and drop those we
don't need. Forget about Gnome3 - let it die alone and silent, as it
deserves.


As has been mentioned before, part of the "battle plan" for systemd

> seems to be to keep taking more and more "standard stuff", deprecate
> it, and introduce new systemd versions with a new API. Thus, a package

they needs to run on a systemd infested system has to support the

> "new improved" API.

Just patch out the crap. And ignore the totally broken packages that
aren't worth the effort.

do they keep support for the old API ? To do so means more work - 

> effectively they have to maintain two bits of code everywhere
they use that function, and that means more work. 


Not, quite. Just rapair and support the original API - drop the
systemd crap entirely.


If that happens, then the job of maintaining that package in a

> non-systemd distro becomes harder.

Well, partial / downstream fork is more work, but all we need is to
be consequent. Of course, we should directly cooperate w/ other
systemd-free distros.


--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Simon Hobson]

"Enrico Weigelt, metux IT consult"  wrote:

> We don't need to fight anything. Just concentrate on the stuff *we*
> need (seriously, does anybobdy here need gnome3 ?) and patch out the
> crap when neccessary.
> 
> And just not caring about that lennartware crap at all. Not even wasting
> time w/ debates about that crap, over and over again. (and yes: that's
> really annying me)
> 
> Why do you waste your precious lifetime w/ lennartware at all ?

There are (IMO) three things needed :

1) Have an alternative - ie Devuan. In that, I salute those who are actually 
doing the hard stuff I wouldn't know where to start with.

2) Make people aware that there is an alternative.

3) Explain (in rational, technical, non-political) terms why people should care 
that there is a choice - and why we think they would be wise to take it.

Without 2 and 3, there won't be large scale adoption of the alternatives - and 
without that, there is distinctly less incentive for the upstream devs to keep 
support for the alternatives.

As has been mentioned before, part of the "battle plan" for systemd seems to be 
to keep taking more and more "standard stuff", deprecate it, and introduce new 
systemd versions with a new API. Thus, a package they needs to run on a systemd 
infested system has to support the "new improved" API.
This means that the dev now faces a choice - do they keep support for the old 
API ? To do so means more work - effectively they have to maintain two bits of 
code everywhere they use that function, and that means more work. If they 
perceive that "hardly anyone" still needs the old API - then there's a 
temptation to drop the old code, or stop maintaining it. If that happens, then 
the job of maintaining that package in a non-systemd distro becomes harder.

Ideally, projects like Devuan need to get enough users that they can entice 
package maintainers over from Debian. Wouldn't it be wonderful if Devuan were 
able to take the lead, and Debian end up having to port packages from it - yes 
that's pie in the sky thinking at the moment, but if you don't have ambition 
then ...


So yes, I agree that "discussing" it time and time again (especially in a 
"preaching to the converted" forum) isn't helpful - but just ignoring it isn't 
going to work either.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Enrico Weigelt, metux IT consult]

On 10.07.2017 23:10, Steve Litt wrote:


Remember, we're fighting a huge and well funded opponent, possessing
the money to throw at programmers to keep the systemd mess running, as
well as money for publicity to counter common sense with neverending
bulldroppings. Seen in that context, what we've accomplished is a
miracle.


We don't need to fight anything. Just concentrate on the stuff *we*
need (seriously, does anybobdy here need gnome3 ?) and patch out the
crap when neccessary.

And just not caring about that lennartware crap at all. Not even wasting
time w/ debates about that crap, over and over again. (and yes: that's
really annying me)

Why do you waste your precious lifetime w/ lennartware at all ?


--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus can no longer trust "init"

[Alexander Bochmann]

...on Mon, Jul 10, 2017 at 05:33:26PM -0400, Miles Fidelman wrote:

 > There's a point at which this all becomes unstoppable, unless some equally
 > well-placed & influential folks start pushing back VERY hard.

That would certainly help, but I also think that it's much more 
important that someone has started actually doing something 
in terms of infrastructure and development, instead of spending 
that time on convincing others to do something.

So here we are, and after following this thing for the past two 
years, I have no doubt that moving all my Debian systems to 
Devuan has been the right choice. So, thank you for making that 
possible, everyone.

At the same time I have no illusions where the market is going - 
my employer now happily buys SuSE and Red Hat licenses instead 
of Solaris or HP-UX, and I won't get them to pick up Devuan 
(except maybe for some fringe stuff under my direct control).

Which really doesn't matter though - it's just the same as in the 
early Debian days, with different roles...

Alex.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Svante Signell]

On Tue, 2017-07-11 at 03:56 +, Miroslav Rovis wrote:
> On 170710-23:39+0200, Svante Signell wrote:
> > On Mon, 2017-07-10 at 14:12 +, Miroslav Rovis wrote:
> > > Hi Svante and everybody!
> > > 
> > > (and zap, to whom you right as second person in the email I'm
> > > replying to. zap
> > > might give useful advice, since he --later-- reported he
> > > successfully
> > > installed
> > > OpenRC)
> > > 
> > > Svante, I'm taking your suggestion in the other thread some three
> > > days ago now,
> > > or so.
> > > 
> > > I want to try OpenRC in my Devuan.
> > 
> > Ok, let's see if I can help you.
> 
> Svante, I got packages from zap. zap, I got your email, it's just the
> Lurker
> that is limited to 40k (which means you can only send some 30k
> (because mail
> encodes in base64) in one email

As written by later mails on this thread, the email limit should stay
as it is. Larger files should be uploaded and hosted somewhere to
download.

> ...but I got them:
> 
> $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \

This one is not OK, see below. This is the Debian (unpatched version)

> > > > Did you see my mail? I can send you the packages
> > > > libfdisk1 2.29.2-1+devuan1
> > > > util-linux2.29.2-1+devuan1
> > > 
> > > I believe/hope all that is necessary is now in these repos that
> > > you
> > > wrote below (but is it so?):

No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and you get
them by adding to sources.list: (+ apt-get update)
sysvinit-core
sysvinit-utils
initscripts
bootlogd (optional)

> > > 
> > > deb http://packages.devuan.org/devuan ascii-proposed main
> > > I hope that is fine.
> > 
> > Yes you need that line for the latest version of sysvinit* and
> > initscripts (2.88dsf-59.9+devuan2)
> 
> sysvinit-utils_2.88dsf-59.9_amd64.deb is what I got from zap (see
> above)

You should apt-get download sysvinit-utils and then (as I wrote to zap)
(version 2.88dsf-59.9+devuan2, not 2.88dsf-59.9):

dpkg -i libfdisk1_2.29.2-1+devuan1_i386.deb 
util-linux_2.29.2-1+devuan1_i386.deb 
sysvinit-utils_2.88dsf-59.9+devuan2_i386.deb

(in one line, the mailer might wrap)

Then you can apt-get install -s openrc and only sysvinit-rc will be
removed in addition to libeinfo1 librc1 openrc (0.23-1+b1) being
installed.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UPS Upgrade for Amprolla

[KatolaZ]

On Tue, Jul 11, 2017 at 02:19:50AM -0400, Linux O'Beardly wrote:
> The amprolla UPS upgrade has been completed without issue. Here's to more
> stability.
> 
> Take care,
> 

Great O'Beardly!

Thanks

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UPS Upgrade for Amprolla

[Jaromil]

On Tue, 11 Jul 2017, Linux O'Beardly wrote:

>The amprolla UPS upgrade has been completed without issue. Here's
>to more stability.

man, many thanks! your solid support is very helpful and reassuring.

greets
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UPS Upgrade for Amprolla

[Linux O'Beardly]

The amprolla UPS upgrade has been completed without issue. Here's to more
stability.

Take care,

Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obear...@gmail.com


On Tue, Jul 11, 2017 at 1:08 AM, Linux O'Beardly 
wrote:

> Ladies, Gentlemen, Ewoks, Wookies, and Unicorns,
>
> I'll be taking amprolla.devuan.org offline for a few minutes in about 1
> hour.  That is 02:00 US EDT/06:00 UTC.  Due to the recent severe weather
> outages, I've decided to upgrade all of my battery backups.  These are not
> top of the line, but are new and should run the amprolla infrastructure for
> about 30 mins if the power grid fails again.  This will not only power the
> server, but the network devices as well, keeping amprolla accessible to the
> world even during a power outage. If there are any objections, let me hear
> them now. If I hear nothing in the next hour, I will be moving forward with
> the upgrade.
>
> Thanks,
>
> Linux O'Beardly
> @LinuxOBeardly
> http://o.beard.ly
> linux.obear...@gmail.com
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[KatolaZ]

On Tue, Jul 11, 2017 at 03:56:14AM +, Miroslav Rovis wrote:

[cut]

> DIGRESSION
> I vote for the limit to be raised at least to 100k (and so I'm CC'ing Rick
> Moen, who, IIUC, administers Lurker)
> DIGRESSION END

I think the limit on the ML should stay at 40K, and for very good
reasons. If you need to transfer anything bigger to the whole list,
then please consider putting it on a web server.

We are putting in place a pastebin-like server for Devuan. It would
allow to post code snippets and text files (well, still not megabytes). 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng