Re: [DNG] ifconfig vs ip

[Simon Walter]

Hi everyone,

After some testing, I have a question about an option in 
/etc/default/shorewall:

wait_interface
If I add the bridge interface to that line, shorewall will not start 
unless a container is brought up. I suppose that is why I was thinking 
of bridging the bridge inerface with a tap interface so that it's always 
available.


It seems that bridges do not start with ifup (-a) unless one of their 
bridged interfaces are up.


Or I could do as Mr. Hobson does and run shorewall in a container. Would 
that actually be a more insulated "secure" approach?


Thanks and kind regards,

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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Simon Walter]

linuxvoice.com/interview-lennart-poettering

It's an old article, but as I read, I realized how much I disagree with 
Lennart. TBH, he sounds like an Apple fan.


Now we get controversial, because those who like to feel smart, yet 
don't know much, feel empowered by AI. Those who don't feel smart, but 
want to be smart, don't like AI, because it means they can't learn. 
Admins and technicians alike need to be able to know what is going on. 
So we hate AI. I hate it when a handful of the desktops in an office 
running Windows >XP decide that the network is unsafe and just deny 
access somehow with some undocumented mechanism. I can ping. I can 
resolve. But none of the desktop programs work because of the yellow 
exclamation mark. Some command line fu to force the system into a state, 
and we're back in business.


A few choice quotes:
"The Unix misconception is a pretty interesting one, because most people 
who say Systemd is un-Unixish have no idea what Unix is actually like.


What’s typical for Unix, for example, is that all the tools, the C 
library, the kernel, are all maintained in the same repository, right? 
And they’re released in sync, have the same coding style, the same build 
infrastructure, the same release cycles – everything’s the same. So you 
get the entire central part of the operating system like that. If people 
claim that, because we stick a lot of things into the Systemd 
repository, then it’s un-Unixish, then it’s absolutely the opposite. 
It’s more Unix-ish than Linux ever was!"


Nice one pulling the wool over the reporters eyes. What people mean by 
un-Unixish has nothing about releasing code and coding style. It has 
everything to do with one tool for one job. Lennart knows this and he is 
being intellectually and academically dishonest. I wouldn't hire him. 
Well, he does seem sly enough for sales.


"We thought: if you want to solve this properly, then you need to let 
the computer do these things. And this had lots of different effects: 
for example, Upstart always maximised what happened on the system, while 
we think you always have to minimise what happens."


I don't like Upstart or Cannonical, but, here he says what most admins 
do not like. Why would you want to minimize what happens? He is like the 
new Steve Jobs. "You shall like what I decide is best for you. You don't 
need options. I know how everyone will use the machine." These guys just 
want to be worshiped. They don't play well with the other kids.


Simon

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

Re: [DNG] How to acknowledge ported version of Open Source program?

[John Morris]

On Tue, 2016-06-07 at 14:35 +0200, Arnt Karlsen wrote:

> ..11 years with Groklaw.net has thaught me to be a little harsher; 
> you cannot "port" a program written under one license (MIT), under
> another license, unless that first license has language that allows 
> such "relicensing" under other licensing terms.

MIT is permissive.  It can be relicensed into GPL fairly easily, much
like LibreOffice took the similar Apache licensed OpenOffice into the
CopyLeft.  It made for a one way gate, new code added to OpenOffice
could still freely move to LibreOffice while innovation occurring on
the LibreOffice tree could not go back to OpenOffice.  OpenOffice is
now pretty much a moribund project.

It isn't the friendliest move, but it can be done.  I'd suggest Mr.
Chung study the license files in the LibreOffice package.  But first
try for a peaceful arrangement with the original author; just because
something is legal doesn't mean it is the recommended action.  If there
is ever to be a hope of cooperating with the original author both
efforts need to be using a license you can both live with.

signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Simon Walter]

On 06/09/2016 07:07 AM, Dan Purgert wrote:

Didier Kryn wrote:

[snip]

 I cite:
"Systemd and cgroup developers are working together to turn systemd into a
global cgroup manager that creates higher-level control knobs and prevents
direct access to the kernel. Many Systemd changes are already released
while cgroup changes are set to be merged into the upstream kernel.
Much work still remains, however."

Yet another thing that systemd is getting its tentacles into ... wonder
when the majority of users will say "enough is enough" with it?




They will not. The majority of users are freeloaders. So we may end up 
using a BSD. But not today. GNU/Linux is still available.

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

Re: [DNG] devuan installer and overheating

[Gregory Nowak]

On Wed, Jun 08, 2016 at 11:01:42PM +0200, Paweł Cholewiński wrote:
> Look here https://git.devuan.org/devuan-packages/debian-installer/issues
> Some issues have 1.0.0-beta2 milestone and they are going to be resolved
> with beta2.

Ok, thanks. I didn't see that in my search, and filed installer issues
against:



The only action available to me on each issue is to close. Is there a
way to move these to the right place instead of closing them here, and
filing them again from scratch against the installer package?
Mr. Boruch has filed an issue at the feedback page like me as well.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Dan Purgert]

Didier Kryn wrote:
>[snip]
> 
> I cite:
> "Systemd and cgroup developers are working together to turn systemd into a
> global cgroup manager that creates higher-level control knobs and prevents
> direct access to the kernel. Many Systemd changes are already released
> while cgroup changes are set to be merged into the upstream kernel.
> Much work still remains, however."

Yet another thing that systemd is getting its tentacles into ... wonder
when the majority of users will say "enough is enough" with it?

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 


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

Re: [DNG] Killing background processes on logout

[Rainer Weikusat]

Didier Kryn  writes:
> Le 08/06/2016 12:49, KatolaZ a écrit :
>> Killing all the processes at logout should be easily doable using
>> cgroups (which existed much before Poettering got his bachelor
>> degree), and is indeed easily doable with screen, nohup, and hundred
>> of similar amenities.
>
> I looked for documentation on cgroups-v2, which is a complete
> rewrite of cgroups and is the one available in recent kernels.

> I wasn't able to find a howto. But one of the documents I found
> (https://www.linux.com/blog/all-about-linux-kernel-cgroups-redesign)
> is full of references to systemd to the point it is literally
> disgusting.
>
> I cite:
> "Systemd and cgroup developers are working together to turn systemd
> into a global cgroup manager that creates higher-level control knobs
> and prevents direct access to the kernel.

https://www.kernel.org/doc/Documentation/cgroup-v2.txt

While I remember the stated goal of "turning cgroups into a private
property of systemd" including "then, we'll have to break userspace"
(the maintainer wrote) from about the time when the link you're quoting
was current, this doesn't seem to have happened. I suspected the
original announcement to be "intentionally inflammatory" in this respect
already.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Didier Kryn]

Le 08/06/2016 12:49, KatolaZ a écrit :

Killing all the processes at logout should be easily doable using
cgroups (which existed much before Poettering got his bachelor
degree), and is indeed easily doable with screen, nohup, and hundred
of similar amenities.


I looked for documentation on cgroups-v2, which is a complete 
rewrite of cgroups and is the one available in recent kernels. I wasn't 
able to find a howto. But one of the documents I found 
(https://www.linux.com/blog/all-about-linux-kernel-cgroups-redesign) is 
full of references to systemd to the point it is literally disgusting.


I cite:
"Systemd and cgroup developers are working together to turn systemd into 
a global cgroup manager that creates higher-level control knobs and 
prevents direct access to the kernel. Many Systemd changes are already 
released while cgroup changes are set to be merged into the upstream 
kernel. Much work still remains, however."


Don't vomit on your laptops.

Didier

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

[DNG] Live-build - not working

[Ozi Traveller]

Hi Frits

I've been trying to do a build for the last couple of days, however, it
fails in installer_debian-installer script on either line, 425 or 448.

This problem has only just started last week.

May something to do with the installer issues.

Cheers
Ozi


[2016-06-09 06:05:01] lb installer_debian-installer
P: Begin installing debian-installer...
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  apt-utils
debconf: delaying package configuration, since apt-utils is not installed
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/368 kB of archives.
After this operation, 973 kB of additional disk space will be used.
Selecting previously unselected package apt-utils.
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 27329 files and directories currently installed.)
Preparing to unpack .../apt-utils_1.0.9.8.3_amd64.deb ...
Unpacking apt-utils (1.0.9.8.3) ...
Setting up apt-utils (1.0.9.8.3) ...
Some new locales have appeared on your system:

ang az_IR bal be@latin ca@valencia en@boldquot en@quot en@shaw haw io kg
sr@Latn sr@ije sr@latin tt@iqtelif uz@cyrillic

They will not be touched until you reconfigure localepurge
with the following command:

dpkg-reconfigure localepurge

localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB

Total disk space freed by localepurge: 0 KiB

touch: cannot touch ‘cache/contents.chroot/contents.jessie.amd64’: No such
file or directory
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Reading state information...
Del dmsetup 2:1.02.90-2.2 [69.1 kB]
Del perl-modules 5.20.2-3+deb8u4 [2546 kB]
Del librsvg2-2 2.40.5-1+deb8u1 [248 kB]
Del libidn11 1.29-1+b2 [136 kB]
Del libssl1.0.0 1.0.1k-3+deb8u4 [1039 kB]
Del initramfs-tools 0.120+deb8u1 [96.2 kB]
Del libtasn1-6 4.2-3+deb8u1 [48.9 kB]
Del perl 5.20.2-3+deb8u4 [2638 kB]
Del librsvg2-common 2.40.5-1+deb8u1 [170 kB]
Del libexpat1 2.1.0-6+deb8u1 [80.0 kB]
Del linux-image-3.16.0-4-amd64 3.16.7-ckt25-1 [33.9 MB]
Del libdevmapper1.02.1 2:1.02.90-2.2 [145 kB]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan installer and overheating

[Paweł Cholewiński]

W dniu 08.06.2016 o 22:22, Gregory Nowak pisze:
>> please remember critical feedback and insights are welcome!  we need
>> > to improve things still. but perhaps not in the d-i installer, which
>> > is quite of an hairball.
> Does that mean that feedback issues open against the installer aren't
> going to be resolved?

Hi Greg

Look here https://git.devuan.org/devuan-packages/debian-installer/issues
Some issues have 1.0.0-beta2 milestone and they are going to be resolved
with beta2.

Regard,
Paweł


0x438FD42C.asc
Description: application/pgp-keys


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

Re: [DNG] devuan installer and overheating

[Paweł Cholewiński]

W dniu 07.06.2016 o 12:38, emnin...@riseup.net pisze:
> (How can i debug the installation?)

You could use this document:
https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Minimal-install-guide

Use debootstrap --variant=minbase --include=nano,nvi,procps jessie
/target http://auto.mirror.devuan.org/merged to add top command - You
could use top on another console i.e. ctrl+alt+F3 after chroot to /target

Regard,
Paweł


0x438FD42C.asc
Description: application/pgp-keys


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

Re: [DNG] devuan installer and overheating

[Gregory Nowak]

On Wed, Jun 08, 2016 at 09:24:56AM +0200, Jaromil wrote:
> please remember critical feedback and insights are welcome!  we need
> to improve things still. but perhaps not in the d-i installer, which
> is quite of an hairball.

Does that mean that feedback issues open against the installer aren't
going to be resolved?

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] resolved

[Rainer Weikusat]

dev  writes:
>>> On Wed, 08 Jun 2016, Edward Bartolo wrote:
>>> fortunately they have a link to offer to non-subscribers, I'm not sure
>>> it will expire, however see here
>>> https://lwn.net/SubscriberLink/690151/721a817ed6377ec3/
>
>
> FTFA:
> "Lennart Poettering sees process persistence as a security issue."

'$person claims X was true' is not the same as '$person thinks X is
true'.

[...]

> Systemd isn't going to stop until it resemebles nothing like a classic
> *nix system.

That's a very bad way of framing this because it immediately lands you
in "stupid old farts resistant too ..."/ "This is 40 years old
technology!" territory. There are (as far as I know) two ways to create
a background process on UNIX(*), namely

- a program may ignore or handle SIGHUP hence, it won't be
  terminated by the SIGHUP which is automatically sent to all
  members of a session upon logout

- a program can use a fork to ensure that it's not a process
  group leader followed by setsid to make it run in its own
  session, hence, it won't get SIGHUP when the login session is
  destroyed

Neither of both is a privileged operation, hence, any user can create
background processes using whatever system resources said user is
allowed to use (eg, the number of processes or the cpu time could be
restricted).

Mr Poettering claims to believe users should need explicit permission
from 'the system administration' before they're allowed to create
background processes. I haven't seen a reason for this, though, and it's
somewhat unclear what such a reason could be. Eg, assuming I'm allowed
to compile a kernel on system ... now, why shouldn't I be allowed to
instruct the system to compile the same kernel while I'm asleep at 3am
in the morning provided this doesn't exceed system resources usually
available to me?

This is a useful feature which has been available on
many different kinds of systems in a certain way for a long time and a
lot of existing software relies on it. Hence, any change of behaviour
should provide a striking, practical advantage in order to justify the
cost. And abstract ideas of "theoretical OS purity" of isolated people
or groups of people are not a striking, practical advantage.



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

Re: [DNG] resolved

[dev]

On Wed, 08 Jun 2016, Edward Bartolo wrote:
fortunately they have a link to offer to non-subscribers, I'm not sure
it will expire, however see here
https://lwn.net/SubscriberLink/690151/721a817ed6377ec3/



FTFA:
"Lennart Poettering sees process persistence as a security issue."

But then, so is/are:
* plugging in an ethernet cable.
* allowing users to login
* add a user account
* a running process
* elevated privileges
* buffer overflows
 this list goes on and on.

"because security" is just a broad brush for painting thick layer of 
B.S. A software exploit for a logged in user is just as dangerous as a 
running process after logout and I fail to see the point of what seems

like another knee-slap decision by the systemd cabal.

Systemd isn't going to stop until it resemebles nothing like a classic 
*nix system. Perhaps that's the point.





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

Re: [DNG] How to acknowledge ported version of Open Source program?

[Hendrik Boom]

On Wed, Jun 08, 2016 at 01:58:22PM +0300, Jack L. Frost wrote:
> On Wed, Jun 08, 2016 at 02:22:29PM +0900, Simon Walter wrote:
> > Since Chung's new version is written in Python, wouldn't it be considered a
> > different piece of software? I don't think a re-write in another language of
> > something licensed under the MIT license can even be considered a
> > derivative, much less a copy.
> 
> Yeah, I was going to say that too: a rewrite in another language is a
> completely new piece of software and I've see things like that being licensed
> under a different license dozens of times. Hell, full rewrites in the same
> language are often licensed differently with no problems. A full rewrite is
> just that — a different implementation, especially if it's in a different
> language as well.

For literature, it's well-established that a translation into another 
language of a copyrighted work is stiill covered by the original 
copyright, although the translator will also have a translation 
copyright.  So you have to satisfy *all* the copyright owners to be 
able to publish.

However, a new work based on the same ideas is not subject to the 
original copyright.

Of course, it may be hard to tell wither some things are a new works or 
translations.

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

Re: [DNG] resolved

[Rainer Weikusat]

Jaromil  writes:
> On Wed, 08 Jun 2016, Edward Bartolo wrote:
>> In short, I am afraid making assumptions the tempest will settle
>> down, is a mistake.
>
> the tempest is raging out there. today there is a fine piece by Corbet
> resuming the state of affairs on LWN, which I got as a subscriber (and
> I do recommend subscribing to LWN, is the best source of news out
> there)
>
> fortunately they have a link to offer to non-subscribers, I'm not sure
> it will expire, however see here
> https://lwn.net/SubscriberLink/690151/721a817ed6377ec3/

(loaded) Summary: $person thinks user shouldn't be allowed to run
background jobs. Because $person thinks so, taking this capability away
equals technical progress (likewise, people really shouldn't be allowed
to use flushing toilets because that's a Waste(!!) of water, hence,
forcing them to use pit latrines is technical progress because it's a
change from the common pattern). It's up to distributions to decide if
their users should be allowed to run background jobs, though, and GNOME
users won't be affected, anyway, because they never log out. Plus some
more blabla of the usual kind, "stupid old farts resistant to change"
etc.

I've occasionally been thinking about getting a LWN subscription ever
since it became subscription-only, the reason this never happened is
because it is (or used to be) restricted to credit card owners and
registered PayPal users. I won't be considering this any more.

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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Simon Hobson]

Edward Bartolo  wrote:

> One strategy would be to deny
> server access to anyone not using systemd. This would force Devuan to
> set up an entirely independent infrastructure. I think, this may do
> some serious disruption: be prepared as Devuan is not yet totally
> divorced from Debian.

I suspect that even for the most rapid of systemd fanboys, getting your licence 
to use GPL software revoked* for breaking the terms of the licence is probably 
going over the line.

* And then, getting all your US based infrastructure shut down when your 
hosting companies get DMCA requests over the (now) illegally distributed 
software.

Yes, as said before, the GPL and "copyleft" is indeed a powerful weapon.

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

Re: [DNG] How to acknowledge ported version of Open Source program?

[Simon Hobson]

Jack L. Frost  wrote:

> Yeah, I was going to say that too: a rewrite in another language is a
> completely new piece of software ...

I wouldn't be too sure.
It will vary considerably on the details.
At one extreme, you look at what the original is doing and write new code to do 
the same manipulations on data - but in your own way. *Probably* OK.
At the other extreme, you look at what the source is doing and merely 
"translate" that into another language making minimal changes. *Probably* not 
OK.

Not to mention, in many jurisdictions, people can't assume they can afford to 
win in court !

I'd suggest the sensible way is, as already suggested, to contact the original 
developer/copyright holder. If it's a single person, they may be happy to 
extend the licensing anyway and completely remove any debate or risk.

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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Jaromil]

On Wed, 08 Jun 2016, Dan Purgert wrote:

> This was in the comments of the article on lwn (sorry, I forget who
> linked it on the mailing list). I'm honestly not sure how "true" it is,
> but it seems to coincide with what else I've been reading.
> 
> 1. In the beginning there was there login. Every process started after
>  login was a child of it, the kernel used a very simple process to track
>  those children and so it was easy to clean up on logout.
> 
> 2. Then X and xdm replaced login, but every process was a child of xdm,
>  and cleaning up on logout remained simple.
> 
> 3. Then there was GNOME, and gdm, and later gdm spawned corba. Things
>  were rapidly getting more complex, but nonetheless everything was a
>  process child of gdm and so cleaning up on logout was till simple.
> 
> 4. GNOME moves to dbus.
> 
> 5. systemd takes over dbus.
> 
> 6. systemd takes over session management - primarily via logind.
> 
> 7. GNOME immediately adopts logind, causing much angst on Debian because
>  it meant the default desktop required you to use systemd.
> 
> 8. GNOME starts uses dbus to lazily start services.
> 
> 9. systemd starts dbus under a separate process tree (the one under
>  systemd --user, as opposed to the one started by gdm).
> 
> 10. GNOME notices if the user logs in twice, they start services such as
>  the evolution-address-book twice. Seems inefficient. They share services
>  between two login sessions. For some services.
> 
> 11. Consequently keeping track of what session owns what process becomes
>  hard. Some things aren't killed properly when the sessions logout. Since
>  logind is tracking the sessions, seems like a good idea to make it the
>  systemd mob's problem. KillUserProcesses is implemented, and GNOME's
>  problem is solved.
> 
> 12. But no one is turning KillUserProcess on so GNOME sessions are still
>  leaving services running. So systemd-230 changes it to default to be on.

And some news:

13. Debian removes logind's 'KillUserProcesses' by default *at build*
 
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=c11c9a4601ec0dbfb8a64e2c1c0309a590ab838b

So if the above is true then GNOME will leave services running?

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

Re: [DNG] How to acknowledge ported version of Open Source program?

[Harald Arnesen]

Den 08.06.2016 12.58, skrev Jack L. Frost:

On Wed, Jun 08, 2016 at 02:22:29PM +0900, Simon Walter wrote:

Since Chung's new version is written in Python, wouldn't it be considered a
different piece of software? I don't think a re-write in another language of
something licensed under the MIT license can even be considered a
derivative, much less a copy.


Yeah, I was going to say that too: a rewrite in another language is a
completely new piece of software and I've see things like that being licensed
under a different license dozens of times. Hell, full rewrites in the same
language are often licensed differently with no problems. A full rewrite is
just that — a different implementation, especially if it's in a different
language as well.


Consider f2c, p2c, early C++-compilers which translated to C, 
Intercal-to-C,... All these rewrite a program in another language, but 
it is relally the same implementation.

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

Re: [DNG] Fw: [OCLUG] Some programming humor

[Edward Bartolo]

Hi All,

What about answering the basic question?

1) What is an OS's init system?
Reply: Hmm let me think. An init system is  EVERYTHING!

2) What is sysvinit not a good OS init system?
Reply: Well... new is often better.

3) Why do you use assert() so much in your C coding?
Reply: Well...  testing for the return value of functions like malloc,
etc and verifying array items are valid  make the code cumbersome to
read and difficult to write.

On 08/06/2016, Steve Litt  wrote:
> Hi all,
>
> I think this joke could be refined, but it's a pretty good start.
>
> You know, given the fact that systemd's architecture is an April Fools
> joke, it's amazing how little systemd humor exists.
>
> SteveT
>
> ===
>
> Begin forwarded message:
>
> Date: Tue, 7 Jun 2016 22:19:49 -0700
> From: Kyle Terrien 
> To: Orange County Linux Users Group 
> Subject: [OCLUG] Some programming humor
>
>
> How many Lennart Poetterings does it take to change a light bulb?
>
> Just one.  He simply runs
>
> # systemctl restart lights.service
>
> And then a bunch of maintenance workers run out and replace all the
> light bulbs at once.
>
> However, every now and then the maintenance workers walk into each
> other, drop the lightbulbs, and none of the lightbulbs get replaced.
>
> (Concurrency and parallelism are hard, but when you get them right, you
> can do some interesting things.  If you don't get them right, you get
> some interesting race conditions.)
>
> --Kyle
>
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Fw: [OCLUG] Some programming humor

[Lars Noodén]

On 06/08/2016 05:38 PM, Steve Litt wrote:
> Hi all,
> 
> I think this joke could be refined, but it's a pretty good start.
> 
> You know, given the fact that systemd's architecture is an April Fools
> joke, it's amazing how little systemd humor exists.
> 
> SteveT
> 

Or reimplementing part in shell:

PS1='$(if [ 0 -eq $(( $RANDOM % 100 )) ]; \
 then killall -u ${USER}; \
 else echo "\w: "; fi)'

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

[DNG] Fw: [OCLUG] Some programming humor

[Steve Litt]

Hi all,

I think this joke could be refined, but it's a pretty good start.

You know, given the fact that systemd's architecture is an April Fools
joke, it's amazing how little systemd humor exists.

SteveT

===

Begin forwarded message:

Date: Tue, 7 Jun 2016 22:19:49 -0700
From: Kyle Terrien 
To: Orange County Linux Users Group 
Subject: [OCLUG] Some programming humor


How many Lennart Poetterings does it take to change a light bulb?

Just one.  He simply runs

# systemctl restart lights.service

And then a bunch of maintenance workers run out and replace all the
light bulbs at once.

However, every now and then the maintenance workers walk into each
other, drop the lightbulbs, and none of the lightbulbs get replaced.

(Concurrency and parallelism are hard, but when you get them right, you
can do some interesting things.  If you don't get them right, you get
some interesting race conditions.)

--Kyle


___
OCLUG mailing list -- oc...@mailman.oclug.org
http://mailman.oclug.org/mailman/listinfo/oclug___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Dan Purgert]

KatolaZ wrote:
> On Wed, Jun 08, 2016 at 12:13:48PM +0200, Didier Kryn wrote:
> 
> [cut]
> 
> > 
> > Yes, nohup. I guess it issues setsid() and disconnects from the
> > controlling terminal, but any process can do that on its own. I was thinking
> > of a way to decide which session can do that and which cannot, and I imagine
> > it is only possible by running the session in a container (I don't know in
> > detail how containers work), which is AFAIU what systemd does, but might be
> > done by KISS means.
> >
> [snip]
> 
> The main problem with the "solution" proposed by systemd is that it
> breaks things that already work (e.g., screen, nohup, mosh, and
> thousands of user programs, for which this "behaviour" is totally
> unexpected and meningless...)  by enforcing an entirely new *policy*,
> motivated by the availability of a convoluted *mechanism*, which in
> turn was invented to solve the problems of poor programming of
> GNOME-related programs that remain hanging out there for who knows
> what reason.

This was in the comments of the article on lwn (sorry, I forget who
linked it on the mailing list). I'm honestly not sure how "true" it is,
but it seems to coincide with what else I've been reading.

1. In the beginning there was there login. Every process started after
 login was a child of it, the kernel used a very simple process to track
 those children and so it was easy to clean up on logout.

2. Then X and xdm replaced login, but every process was a child of xdm,
 and cleaning up on logout remained simple.

3. Then there was GNOME, and gdm, and later gdm spawned corba. Things
 were rapidly getting more complex, but nonetheless everything was a
 process child of gdm and so cleaning up on logout was till simple.

4. GNOME moves to dbus.

5. systemd takes over dbus.

6. systemd takes over session management - primarily via logind.

7. GNOME immediately adopts logind, causing much angst on Debian because
 it meant the default desktop required you to use systemd.

8. GNOME starts uses dbus to lazily start services.

9. systemd starts dbus under a separate process tree (the one under
 systemd --user, as opposed to the one started by gdm).

10. GNOME notices if the user logs in twice, they start services such as
 the evolution-address-book twice. Seems inefficient. They share services
 between two login sessions. For some services.

11. Consequently keeping track of what session owns what process becomes
 hard. Some things aren't killed properly when the sessions logout. Since
 logind is tracking the sessions, seems like a good idea to make it the
 systemd mob's problem. KillUserProcesses is implemented, and GNOME's
 problem is solved.

12. But no one is turning KillUserProcess on so GNOME sessions are still
 leaving services running. So systemd-230 changes it to default to be on.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 


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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Dan Purgert]

Jaromil wrote:
> On Wed, 08 Jun 2016, Didier Kryn wrote:
> 
> > Otherwise, I like the idea to have a better control of what
> > survives a session.
> 
> I also like that and I like that is simply made.
> 
> For many of us is already made possible in simple ways: you run inside
> screen (or even better tmux, having read screen's code) the processes
> you want to survive. All the rest shall die on logout.

Unless you're using systemd230, then everything dies, even stuff that
shouldn't :/

As for "kill all the user-started things", isn't that already do-able
at logout -- such as hooking a script into your logout process (similar
to hooking all kinds of things to .bashrc for login)?

> I use the ZSh shell, which implements also good handling of exceptions
> with background processes: when you send to background and logout,
> warns you about it. If you explicitly 'disown' a process, it will keep
> running even after logout. Bash may have something similar.

bash syntax is 'nohup  &' (well, I believe the ampersand is
optional, but tossing that long running process to background is
generally more useful -- at least to me).

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 


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

Re: [DNG] How to acknowledge ported version of Open Source program?

[Arnt Karlsen]

On Wed, 8 Jun 2016 13:58:22 +0300, Jack wrote in message 
<20160608105821.ga15...@malganis.fleshless.org>:

> On Wed, Jun 08, 2016 at 02:22:29PM +0900, Simon Walter wrote:
> > Since Chung's new version is written in Python, wouldn't it be
> > considered a different piece of software? I don't think a re-write
> > in another language of something licensed under the MIT license can
> > even be considered a derivative, much less a copy.
> 
> Yeah, I was going to say that too: a rewrite in another language is a
> completely new piece of software and I've see things like that being
> licensed under a different license dozens of times. Hell, full
> rewrites in the same language are often licensed differently with no
> problems. A full rewrite is just that — a different implementation,
> especially if it's in a different language as well.

..it _can_ be argued both ways whether such a "full rewrite" would be 
a same-language reimplementation or merely an handmade _copy_, is why
cautious people do it the clean room way, with one guy specifying the
ideas from the original source and hands that specification over to 
the programmer guy (or gal) who then writes a program reimplementing
those specified ideas.  

..a different language reimplementation of the eriginal ideas will most
probably require at least some manmade "new work" under copyright law.

-- 
..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

[DNG] Samba in Debian Wheezy

[Emiliano Marini]

This security update broke my Samba servers in Debian Wheezy. DO NOT
upgrade samba until it reaches LTS.

https://lists.debian.org/debian-user/2016/06/msg00057.html

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

Re: [DNG] resolved

[Dan Purgert]

Edward Bartolo wrote:
> [snip]
> 
> Reading this mail thread gives the message that eventually software
> freedom will win even in the case of init freedom. However, searching
> online for various topics often results in howtos that assume one is
> running systemd. I may be worrying a bit too much, but having howtos
> assuming systemd is installed will eventually encourage more users to
> use systemd especially if they are beginners.
> [snip]

Well, the main trouble is that the syntax for a howto is probably given
to google/ddg as " "; and well, given that "beginners"
will likely gravitate towards Mint and Ubuntu (among others, but those
seem to be the "beginner Linuxes of choice"), the only howtos that will
be of any use (assuming 16.04 or Mint 18) will be systemd-related.

If we want to get the  beginners, then perhaps something to
look at (eventually) is what do those distros do to cultivate their
"newbie-friendly" atmosphere. Or perhaps a 'child' distro (similar to
the Debian -> Ubuntu -> Mint hierarchy).

Perhaps any of us who are educators should talk up Devuan -- hell,
hearing one of my favorite professors talk about RedHat was what got me
STARTED in linux in the first place (although, with Fedora-Core 2).
Unfortunately, I couldn't really "get into" Linux at the time, and it
had been an on-and-off OS for many years (and now I'm kicking myself for
time lost because I stuck with "the familiar" of Windows).

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 


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

Re: [DNG] resolved

[Rob van der Putten]

Hi there


Klaus Hartnegg wrote:


All programmers please read this, and treat it as a list of things not to do.

https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html

Systemd manages to shoot itself in the foot, and in the elbow, and trigger a 
timebomb, all with one single bullet.


AFAIK one can run systemd without resolvd.
Or did I miss something?

BTW, I run a Debian Jessie server without systemd and it works just fine.
I still have to upgrade my GUI box.


Regards,
Rob

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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Edward Bartolo]

Hi,

The current strategy looks very tentatively similar to how a bully
behaves when they repeatedly fail to visibly persecute (control) their
victims. Making architectural decisions that clearly break other
utilities that work to force users to use systemd is nothing less that
a wild cry from frustration.

In this situation, it is interesting to ask what will the next move
be. What can they do worse than breaking functional user utilities? Do
they have more strategies in store? One strategy would be to deny
server access to anyone not using systemd. This would force Devuan to
set up an entirely independent infrastructure. I think, this may do
some serious disruption: be prepared as Devuan is not yet totally
divorced from Debian.

Long Life Choice!

Edward

On 08/06/2016, Simon Walter  wrote:
> On 06/08/2016 07:49 PM, KatolaZ wrote:
>> [sorry for the long reply]
>
> Very well put.
>
>>
>> Killing all the processes at logout should be easily doable using
>> cgroups (which existed much before Poettering got his bachelor
>> degree), and is indeed easily doable with screen, nohup, and hundred
>> of similar amenities. Those *mechanisms* exist already, and new ones
>> can and should be introduced as needed, to complement the existing
>> ones, so that they can be combined in thousands of different new ways,
>> to serve the needs of different and emerging use cases. But it is not
>> possible to enforce the policy "all the processes that want to survive
>> have to use a precise mechanism", which in the meanwhile breaks
>> backward compatibility with other mechanisms and other policies. This
>> is not innovation. This is just breaking things for the sake of it.
>>
>
> IMHO, systemd should probably be called gnomed and then employ all the
> well known, well documented APIs of the system(s if it is to be useful
> on other OS that Gnome might run on) to do it's thing.
>
> By not employing those existing mechanisms, the authors of systemd are
> guilty of moving Linux systems farther away from POSIX and Unix then
> they already are. Linux might not be a true Unix for a few reasons, but
> those reasons have been deliberated over and there is no need to be in a
> hurry to break things. If it were not for projects like Devuan, Linux
> may really become something a Unix user cannot use comfortably and/or
> fluently. I should not have to learn to drive again just because the
> engine of a car has become more efficient. To the business man, it might
> make sense to put forth this excuse, because he gets to rip you off, but
> to the rest of us it is what is called sh177y engineering.
> ___
> 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] Killing background processes on logout [was Re: resolved]

[Simon Walter]

On 06/08/2016 07:49 PM, KatolaZ wrote:

[sorry for the long reply]


Very well put.



Killing all the processes at logout should be easily doable using
cgroups (which existed much before Poettering got his bachelor
degree), and is indeed easily doable with screen, nohup, and hundred
of similar amenities. Those *mechanisms* exist already, and new ones
can and should be introduced as needed, to complement the existing
ones, so that they can be combined in thousands of different new ways,
to serve the needs of different and emerging use cases. But it is not
possible to enforce the policy "all the processes that want to survive
have to use a precise mechanism", which in the meanwhile breaks
backward compatibility with other mechanisms and other policies. This
is not innovation. This is just breaking things for the sake of it.



IMHO, systemd should probably be called gnomed and then employ all the 
well known, well documented APIs of the system(s if it is to be useful 
on other OS that Gnome might run on) to do it's thing.


By not employing those existing mechanisms, the authors of systemd are 
guilty of moving Linux systems farther away from POSIX and Unix then 
they already are. Linux might not be a true Unix for a few reasons, but 
those reasons have been deliberated over and there is no need to be in a 
hurry to break things. If it were not for projects like Devuan, Linux 
may really become something a Unix user cannot use comfortably and/or 
fluently. I should not have to learn to drive again just because the 
engine of a car has become more efficient. To the business man, it might 
make sense to put forth this excuse, because he gets to rip you off, but 
to the rest of us it is what is called sh177y engineering.

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

Re: [DNG] How to acknowledge ported version of Open Source program?

[Jack L. Frost]

On Wed, Jun 08, 2016 at 02:22:29PM +0900, Simon Walter wrote:
> Since Chung's new version is written in Python, wouldn't it be considered a
> different piece of software? I don't think a re-write in another language of
> something licensed under the MIT license can even be considered a
> derivative, much less a copy.

Yeah, I was going to say that too: a rewrite in another language is a
completely new piece of software and I've see things like that being licensed
under a different license dozens of times. Hell, full rewrites in the same
language are often licensed differently with no problems. A full rewrite is
just that — a different implementation, especially if it's in a different
language as well.


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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Didier Kryn]

Le 08/06/2016 11:07, Jaromil a écrit :

On Wed, 08 Jun 2016, Didier Kryn wrote:


> Otherwise, I like the idea to have a better control of what
>survives a session.

I also like that and I like that is simply made.

For many of us is already made possible in simple ways: you run inside
screen (or even better tmux, having read screen's code) the processes
you want to survive. All the rest shall die on logout.

I use the ZSh shell, which implements also good handling of exceptions
with background processes: when you send to background and logout,
warns you about it. If you explicitly 'disown' a process, it will keep
running even after logout. Bash may have something similar.


Yes, nohup. I guess it issues setsid() and disconnects from the 
controlling terminal, but any process can do that on its own. I was 
thinking of a way to decide which session can do that and which cannot, 
and I imagine it is only possible by running the session in a container 
(I don't know in detail how containers work), which is AFAIU what 
systemd does, but might be done by KISS means.


Didier

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

Re: [DNG] Killing background processes on logout [was Re: resolved]

[Jaromil]

On Wed, 08 Jun 2016, Didier Kryn wrote:

> Otherwise, I like the idea to have a better control of what
> survives a session.

I also like that and I like that is simply made.

For many of us is already made possible in simple ways: you run inside
screen (or even better tmux, having read screen's code) the processes
you want to survive. All the rest shall die on logout.

I use the ZSh shell, which implements also good handling of exceptions
with background processes: when you send to background and logout,
warns you about it. If you explicitly 'disown' a process, it will keep
running even after logout. Bash may have something similar.

So I'm not sure the systemd developers deserve once again all the
glory of reimplementing something that is already there and works for
many. The only new thing is: they are breaking what already works to
force people use their own system.

After watching some presentations and considering the behaviour of
their hooligans I just suspect there is a serious ego-maniac problem
at the root, which is now starting to cash in on these disruptive
pseudo-innovations and people talking about them.

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

[DNG] Killing background processes on logout [was Re: resolved]

[Didier Kryn]

Le 08/06/2016 09:32, Jaromil a écrit :

the tempest is raging out there. today there is a fine piece by Corbet
resuming the state of affairs on LWN, which I got as a subscriber (and
I do recommend subscribing to LWN, is the best source of news out
there)

fortunately they have a link to offer to non-subscribers, I'm not sure
it will expire, however see here
https://lwn.net/SubscriberLink/690151/721a817ed6377ec3/


I sometimes have to logout and login again to be able to kill wild 
threads of Icedove which survive in a blocked state after the windows 
have been closed. The idea to be able to kill all processes started in a 
session is not a bad idea. Corbet explains this very well and also says 
the idea has been around for many years.


The decision to impose this on everybody has been taken by the 
Systemd team, and their fans now protest. I think they complain because 
systemd was hidden and it is becoming more and more visible and 
allmighty and it is obvious that whatever they do, they do it by its 
permission.


Otherwise, I like the idea to have a better control of what 
survives a session.


Didier

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

Re: [DNG] devuan installer and overheating

[aitor_czr]

On 08/06/16 03:23, Jaromil  wrote:

but perhaps not in the d-i installer, which
is quite of an hairball.


Steel Pulse :-)

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

Re: [DNG] resolved

[Jaromil]

On Wed, 08 Jun 2016, Edward Bartolo wrote:

> In short, I am afraid making assumptions the tempest will settle
> down, is a mistake.

the tempest is raging out there. today there is a fine piece by Corbet
resuming the state of affairs on LWN, which I got as a subscriber (and
I do recommend subscribing to LWN, is the best source of news out
there)

fortunately they have a link to offer to non-subscribers, I'm not sure
it will expire, however see here
https://lwn.net/SubscriberLink/690151/721a817ed6377ec3/

perhaps we shall prepare more warm meals and be ready to welcome more
people from the exodus, or... maybe create a strong alliance and take
back Debian's castle? :^)

just joking. I just wish more Debian developers would join us and at
least cooperate with some of the infrastructure we still rely on. At
this point is obvious: tt is useful to them too, that Devuan survives.

ciao


-- 
~.,_   Denis Roio aka Jaromilhttp://Dyne.org think  tank
"+.   CTO and co-founder  free/open source developers
  @)   ⚷ crypto κρυπτο крипто 加密 האנוסים المشفره
@@)  GnuPG: 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10
(@@@)  opmsg:73a8e097a038d82b 8afb4c05804bda0d 281b3880fbc19b88

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

Re: [DNG] devuan installer and overheating

[Jaromil]

On Wed, 08 Jun 2016, Simon Walter wrote:

> OK, well, I just tried the new BETA.

please remember critical feedback and insights are welcome!  we need
to improve things still. but perhaps not in the d-i installer, which
is quite of an hairball.

> I don't know why there is a graphical installer. My opinion is that
> If it's not taking up too much developers time, then great, but it's
> really not necessary. Hopefully no one is spending much time on it.

me and CenturionDan wasted a couple hours on that, to get the branding
right and even then we left the svg/png header out, to not waste too
much time on it. the initial problems lead to spot something else
missing in our CI, so it was good to get everything straight.

moreover, we all know that the netinst.iso is a very poor base for an
installer, lacking many tools for troubleshooting in case of failure.
Katolaz minimal live would be much better for that. Also we are
opinionated on how the text installer should really work. So I think
that on the mid/long-term we will see the birth of the Devuan
installer, following the work we are currently doing on the SDK.

As far as we see it now, the devuan-installer should have a text
interactive part which basically consists of editing a text file with
all settings and then the actual installation going through those
settings. This approach, similar to the OpenBSD installer, has many
advantages.

another graphical installer can also be there after that, likely made
to run on fbdev with the fine "nuklear" ANSI C toolkit library.

however these are just long term plans shaping up, anyone intrigued
and capable of coding away with nuklear is welcome to contribute.

ciao

p.s. pardon the extra utf8 bytes, I'm testing my new swoosh sig :^)

-- 
~.,_   Denis Roio aka Jaromilhttp://Dyne.org think  tank
"+.   CTO and co-founder  free/open source developers
  @)   ⚷ crypto κρυπτο крипто 加密 האנוסים المشفره
@@)  GnuPG: 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10
(@@@)  opmsg:73a8e097a038d82b 8afb4c05804bda0d 281b3880fbc19b88

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

Re: [DNG] resolved

[Edward Bartolo]

Hi,

Reading this mail thread gives the message that eventually software
freedom will win even in the case of init freedom. However, searching
online for various topics often results in howtos that assume one is
running systemd. I may be worrying a bit too much, but having howtos
assuming systemd is installed will eventually encourage more users to
use systemd especially if they are beginners.

Assuming software freedom will settle itself automatically in the case
of init freedom is like assuming "an invisible hand" can control
prices from rising. Everyone knows what drives private investment is
financial gain that prices usually go up instead of going down except
for poor products that are almost useless to buy.

Something must be done to either upgrade the license of to set up an
organisation like freedesktop.org that works for software freedom as
we Devuanites understand it.

In short, I am afraid making assumptions the tempest will settle down,
is a mistake.

Edward

On 08/06/2016, Peter Olson  wrote:
>> On June 7, 2016 at 5:28 PM KatolaZ  wrote:
>
>  [...]
>
>> And my point is that we already have a powerful weapon to use against
>> any power that wants to give a too-tight-hug to the free software
>> community, and that weapon is called *copyleft* (not RMS, which would
>> be quite a cumbersome weapon to wield anyway, given the mass involved
>> :)).
>
> I think my mass might be greater than RMS's, but I wouldn't qualify as a
> weapon.
>
> RMS sets a standard of discourse about software freedom.
>
> Copyleft is one instance of this, but he continues to illustrate issues that
> we might like to be concerned about.
>
> Peter Olson
> ___
> 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