Re: [DNG] xfce not shutting down on Devuan

[James Powell]

Xfce requires ConsoleKit or ConsoleKit2 and the startup ran with the flag 
"startxfce --with-ck-launch".

From: iguleder
Sent: ‎8/‎23/‎2015 11:48 PM
To: adamdm
Cc: dng@lists.dyne.org
Subject: Re: [DNG] xfce not shutting down on Devuan

apt-get update;apt-get -y upgrade

I've spent many nights debugging power/session management issues in Xfce on 
Devuan - all confirmed disabled button issues are fixed.




Let me know if the problem persists.


 On Mon, 24 Aug 2015 01:26:16 +0300 adamdm wrote 


I can't shutdown Devuan from xfce, the button is just disabled...
Am I missing something?

Thanks
___
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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linux-related critique

[James Powell]

Jaromil, truth be told, I actually hold back in my critique of systemd and the 
people who blindly support it. I very well can't publicly say, "Anyone who 
favors systemd is about as stupid as a pile of horse vomit, and should go play 
Russian Roulette with a shotgun in the middle of a busy freeway" now can I? I 
actually do hold back as best I try... and then you have some fanboy come 
toddling along...

-Jim

From: Jaromil
Sent: ‎8/‎19/‎2015 1:39 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] Linux-related critique



On 18 August 2015 20:23:36 CEST, Steve Litt  wrote:
>On Tue, 18 Aug 2015 19:06:25 +0100
>Rainer Weikusat  wrote:
>
>> DStoicheff  writes:
>> > I am positive this post will raise the blood pressure
>> > of some, but it is long overdue
>>
>> [...]
>>
>> > I am of a certain age to have a working knowledge of IBM 360,
>> > punched card accounting
>>
>> It's a pity that you haven't been able to come to terms with more
>> modern developments, eg, UNIX(*).
>
>Rainer --- Why respond to that guy. His very first post on our mailing
>list, and it's nothing but word salad.

yes it is a bit trolley, but then even admittedly
and there is no personal insult in it

I must admit having enjoyed the word salad a bit :-)
still somehow acceptable food around this campfire

and I like very much what James responds
windows10 works very well for those in need of systemd
they could just save time and go using it at this point

ciao
___
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] Linux-related critique [Rant]

[James Powell]

> Date: Wed, 19 Aug 2015 00:07:36 +0200
> From: phi...@posteo.de
> To: dng@lists.dyne.org
> Subject: Re: [DNG] Linux-related critique [Rant]
> 
> Rainer, I'm sorry for posting the wrong quote header in my previous 
> message. Of course I was quoting "DStoicheff", not you.
> 
> Best,
> Philip
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Anyone that feels systemd is a forward thinking idea, go read the UNIX 
documentation by Doug Mcllroy and the rest of the guru's who developed and 
founded not just UNIX but the underlying principles of UNIX and UNIX-like 
systems.

Now please do yourself a favor, if you still think systemd is the next best 
thing since sliced bread. Go down to Wal-Mart, Best Buy, or some other humdrum 
name-brand store, buy a copy of Windows 10, and please, for the love of all 
that is sacred, holy, sane, and just in this universe, DO NOT COME BACK.

systemd is not launchd, busybox, or SMF.

systemd is a complete shell-less hypervisor that is more akin to the 
PlayStation 3 operating system (XBM) which was about as GNU friendly as Bill 
Gates or Steve Jobs. It is not an alternative, nor is it a drop-in sysvinit 
replacement. It is a completely new middleware that has about as much usage and 
business in GNU/Linux as svchost would have. Entire systems must be rebuilt 
around it. Services must be rebuild to use it. It is not just "an init system". 
It is a hypervisor. Here's the definition for the stupidly clueless:

"A hypervisor or virtual machine monitor (VMM) is a piece of computer software, 
firmware or hardware that creates and runs virtual machines.
A computer on which a hypervisor is running one or more virtual machines is 
defined as a host machine. Each virtual machine is called a guest machine. The 
hypervisor presents the guest operating systems with a virtual operating 
platform
 and manages the execution of the guest operating systems. Multiple 
instances of a variety of operating systems may share the virtualized 
hardware resources."


Each virtual terminal to the shell is a virtual machine in which everything is 
a guest of the host. Yes, bash is no longer the default access point of the 
system. systemd is the host, it is the access point. It supplies it's own 
networking manager, kernel command line interface, boot manager, session 
manager, device manager, and a host of other things which all run independent 
of the shell system, unlike a traditional UNIX or UNIX-like system. In short, 
your "root" access is not really and truly root. It's a root accessible shell 
session with root permissions.


In traditional GNU/Linux, bash is the base of the system. Everything run as an 
off-shoot of bash as a daemonized forked executable.


systemd is technically thinking exactly like Windows 9x/ME all over again. A 
system running on top of another system. It was a flawed design then, and it's 
a flawed design now.


I hope this has been enlightening for the clueless as to what systemd is and 
how un-progressive and backwards thinking it truly is.


If you want forward thinking stuff, look at s6, OpenRC, Runit, and others. 
Things that are aimed at helping UNIX, not turning GNU/Linux into another 
half-assed, piss-poor, wanna-be copy of Windows 9x.


Good day sir!


-Jim

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

Re: [DNG] Systemd Shims

[James Powell]

While there are packages that can be invisible and unintrusive into the system, 
there are some that cannot.

The problem is responsibility.

Who wants to remain responsible for boot scripts? Upstream or vendor?

Who wants responsibility for providing interoperability between projects? 
Upstream or downstream bazaar?

Who wants responsibility for the userland? Upstream or the downstream bazaar?

To me, this 'lack of' responsibility, and honestly this isn't just aimed at 
systemd, but as modern society as a whole, is the cause of this mess. This lack 
of personal and public responsibility has led to the rise of things like this, 
and it's high time we stand up and say either 'start being responsible' or 
'take responsibility' or else? Or else what? You'll find out when all the 
pushed off responsibility you didn't want comes crashing back down on you.

Didn't want to get political, philosophical, or religious, but sometimes enough 
is enough.

-Jim

From: Franco Lanza
Sent: ‎8/‎16/‎2015 1:46 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Systemd Shims

On Sun, Aug 16, 2015 at 12:13:04PM -0500, T.J. Duchene wrote:
> Well, I suppose the topic has been beat up enough, but I just wanted to clear
> up something before moving on. I want you to understand why I came to the
> Devuan list in the first place. I came here under the assumption that Devuan
> was going to be a "better Debian" without the shove the Technical Committee
> and the failure of the GR  gave to one single point of view.

Well, we are here also to try to build up a "better debian" without
single point of view, yes, and to avoid "single point of view" for the
future, we are trying to move from "TC imposed view" to "VUA imposed
policy".

What's the difference?

With a TC imposed view like in debian, you can't assume any decision
before the decision is made. With a "VUA imposed policy", when the
policy will be complete and public, it isn't yet, you can know how
anything will be managed in future.

Basically, more power to our constitution and less to "people in
charge", where "people in charge" will just act as constitution
custodes.


> As far as I can tell, Devuan is about the same, with one difference.  Devuan 
> is
> willing to package systemd if it can be done cleanly - but nobody wants to.
> Debian will support System 5, again until nobody wants to.

No, it isn't like this.
It's this way:

Debian will support sysv, until nobody wants to.
Devuan will support anything that is feasible to do without ruining all
other options and impose one single way to do that, assuming someone
will accept to do the work.

The Devuan way is a policy, not something against a specific software.
Sadly systemd apply for this limitation as it can't be done without
hijacking whole system and imposing one way, so, it can't be an option
in my opinion. If anyone will get the work done and make it usable
without hijacking whole base system, well, Devuan will embrace it as an
option like anything else. Pratically, to me, this seems to be
impossible.

> Nexttime: "Devuan will not work to support systemd and will not work against
> it. We will not do any effort to support it, if someone want to work to 
> package
> it in a way where it works WITHOUT needs support for any other package
> depending on it, we will consider to add it as an option, but we will NOT
> accept it if it ask us to put it in dependency tree. "
>
> That is all I EVER suggested, with one slight difference.  That if it is
> somehow possible in the future to maintain two versions of the same package
> that the default version would be without systemd, but the other would be
> available at the users' option as a matter of choice.

This is of course feasible, yes. BUT how many packages will need two
versions? For systemd, too many, this is a way we can use for few
packages, but using it for 1 packages is probably a too huge effort,
at least for the moment. In future, who knows.

NOTE: my nickname is "nextime", with 1 single t. Is isn't derived from 
"next-time",
  it comes from the software called "nextime" that was in some wat
  the grandfather of the now called "quicktime" when it was born on
  NextOS.

--

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://c...@casa.nexlab.it
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---

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

Re: [DNG] About shims and systemd in devuan

[James Powell]

Thank you.

If people want Devuan with systemd or anything close to it, use Debian aka 
CoreOS w/ dpkg.

People came to Devuan to have choice, mainly a choice to avoid systemd at all 
costs.

-Jim

From: Nextime
Sent: ‎8/‎16/‎2015 5:59 AM
To: dng@lists.dyne.org
Subject: [DNG] About shims and systemd in devuan

The devuan policy about systemd shims and systemd in devuan as been already 
exaustively discussed many times, and can i reassume it as follow:

Devuan will not work to support systemd and will not work against it. We will 
not do any effort to support it, if someone want to work to package it in a way 
where it works WITHOUT needs support for any other package depending on it, we 
will consider to add it as an option, but we will NOT accept it if it ask us to 
put it in dependency tree.
As for how it work, this policy put effectively it in the "we will not support 
it" list ad systemd without dependecy to it is like vaporware.

For shims, we will not introduce shims, as the work to trace abi from systemd 
components make it just a shit. We will optionally consider to reimplement some 
funcionalities we consider usefull from systemd, but in a unix/kiss way, so, 
probably without dbus, or not compatible with systemd: we want to have the few 
good funcionality that are present in systemd, but we want them better 
implemented.
--
nextime
___
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] Systemd Shims

[James Powell]

Systemd is not an option. Uselessd is an option, Runit is an option, s6 is an 
option, OpenRC is an option. Why, because any of these are init/supervisor sane 
replacements and/or extensions to sysvinit.

When you replace the underlying system core with a completely alien hypervisor, 
you kill the option, and kill choice. Once systemd is in, it is in.

-Jim

From: T.J. Duchene<mailto:t.j.duch...@gmail.com>
Sent: ‎8/‎15/‎2015 12:48 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] Systemd Shims

On Sat, 15 Aug 2015 03:15:50 -0700
James Powell  wrote:

Hi Jim! =)

>
> To me, a shim is not the way. Sanitization is what is needed, and if
> that requires work, then question this, 'Will the work be worth it?'
> and to me the answer is a definable 'yes'.

I suppose there are some people like yourself who will always feel that
way, and that is quite frankly - "totally awesome".

All that I ever try to say that I think there should be room for
both sorts to make Devuan a home.  Yes, I think Devuan should have
systemd as an option, but only as an option - never part of the base
system.



>
> Not to push a button, but I think Funtoo had the right mindset about
> systemd 'No way or chance in Hell'.

I'm sorry Jim, but I see Funtoo as really a bad example of the
situation.

Funtoo is source based, and Devuan is not.  They are both Linux but it
is two very different worlds of users, like apples and oranges. It's a
LOT easier to excise systemd when you are not expected to provide a
binary.  The minute you are expected to provide an official binary and
have major features removed, users start to complain that your version
is less than everyone else.

Usually, the only ones who use source versions are power users and
programmers who understand and accept the trade-offs in compiling your
own OS.

Have a great day!  =)

T.J.

___
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] Systemd Shims

[James Powell]

My $0.02...

Shims are not needed, or, in my viewpoint, wanted. You're still working with 
systemd or pseudo-systemd and either way you see it, it's still systemd. While 
the prospect of systemd-shim does allow to separate the API layer and logind 
out from the core project, as uselessd allowed the systemd-init to be separated 
out, it's still working with systemd, and systemd is still required to build 
it, the shim, from source. The only shim that doesn't require systemd is 
loginkit and that project hasn't really done much, no offensive meant.

To me, a shim is not the way. Sanitization is what is needed, and if that 
requires work, then question this, 'Will the work be worth it?' and to me the 
answer is a definable 'yes'.

If this is going to be System V based GNU/Linux, then why is there talk of 
systemd? System V GNU/Linux is not systemd GNU/Linux.

Not to push a button, but I think Funtoo had the right mindset about systemd 
'No way or chance in Hell'.

-Jim

From: Didier Kryn
Sent: ‎8/‎14/‎2015 11:52 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Systemd Shims

Le 15/08/2015 02:26, Steve Litt a écrit :
> On Fri, 14 Aug 2015 14:49:17 -0700
> Go Linux  wrote:
>
>> On Fri, 8/14/15, T.J. Duchene  wrote:
>>
>>   Subject: Re: [DNG] Systemd Shims
>>   To: dng@lists.dyne.org
>>   Date: Friday, August 14, 2015, 2:47 PM
>>
>>> I know not everyone here agrees with me, especially Steve, and
>>> that's perfectly okay.  I have no problem with that at all. I just
>>> don't see "System 5 pure"  as realistic when planning ahead looking
>>> at a maintenance standpoint when Debuan upstream is more and more
>>> likely to stick with Systemd in designing their packaging.
>>>
>> Maybe we should just put Steve in charge of decontaminating all
>> packages with systemd deps!
> Oh, you wouldn't want to do that. Contrary to what I wrote in another
> thread about "the perfect is the enemy of the good", if *I* were in
> charge of decontamination, I'd throw out whole subsystems. Gnome gone.
> KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all
> systemd on us.
>
> In the massive time I save as not being the bomb squad defusing Red
> Hat's terrorism, I'd write small replacements for a lot of things that
> use only Linux and a very rudimentary and optional GUI interface.
>
> Then I'd write documentation explaining how to use a sharp thinking
> computer, to the proud ignorants of the world, especially those who
> believe their ignorance is a badge of honor proving their age or
> gender.
>
> And the people who prioritize pretty over functional and robust: I'd
> tell them to get a Mac.
>
> You don't want me in that capacity.
>
> And yes, I *am* a hypocrit who takes one position in one thread, and
> then says he'd do the opposite in another. :-)
>
> SteveT
>
>

 Please, Steve, provide us with all you mentionned, as an
alternative to mainstream bloated/infected stuff. Since Devuan is all
about freedom, this is the place where to deliver to the world. As soon
as I can install Devuan on metal, I'll be one of your testers.

 Didier

___
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] Devuan and upstream

[James Powell]

I respectfully disagree.

A single package would require a new build script, but equally it will pay for 
itself in the long run by reducing the overall workload to maintain each 
package.

The short term, yes its work. It will be. But why not have one single 
SDL2-2.0.0-x86_64-1.deb package that is sustainable in the long term?

I don't want to debate long term versus short term, but at the current rate, 
Devuan will be sustainable, but for how long with such a small team?

From: Hendrik Boom<mailto:hend...@topoi.pooq.com>
Sent: ‎8/‎14/‎2015 5:33 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] Devuan and upstream

On Fri, Aug 14, 2015 at 05:19:25PM -0700, James Powell wrote:
> Slackware is maintained by 3 core people with extra help as needed. The rest 
> of the packages are pushed by the community at large contributing. Devuan 
> doesn't have to maintain every package possible. That's ludicrous to think so.
>
> Debian got in over its head by allowing this. Thousands upon thousands of 
> packages that required a committee to oversee.
>
> Honestly, what is needed by a distribution? Look at Slackware or BLFS that's 
> a lot of packages, but it's manageable by a small team. Why can't Devuan 
> follow suit? There doesn't need to be a bagillion packages maintained by the 
> main devs. If the rest need to be passed back to the community at large, then 
> do it. This also hits the point of why do we need 5 different for things 
> like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? 
> One package is easier to maintain than five individual ones. It lightens the 
> load significantly, especially for the poor soul having to make 5 or more 
> different scripts for 5 packages from the same source tarball. Yes, it's nice 
> to have small packages for embedded stuff and small disks, but do you really 
> want to raise the workload of the maintainer that much?

It would also be folly to increase the maintainers load by naing him
reunite those multiple binary packages that are prooduced from one
source package.  We don't have the manpower for that economy!

-- hendrik
___
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] Devuan and upstream

[James Powell]

Slackware is maintained by 3 core people with extra help as needed. The rest of 
the packages are pushed by the community at large contributing. Devuan doesn't 
have to maintain every package possible. That's ludicrous to think so.

Debian got in over its head by allowing this. Thousands upon thousands of 
packages that required a committee to oversee.

Honestly, what is needed by a distribution? Look at Slackware or BLFS that's a 
lot of packages, but it's manageable by a small team. Why can't Devuan follow 
suit? There doesn't need to be a bagillion packages maintained by the main 
devs. If the rest need to be passed back to the community at large, then do it. 
This also hits the point of why do we need 5 different for things like, for 
example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? One package 
is easier to maintain than five individual ones. It lightens the load 
significantly, especially for the poor soul having to make 5 or more different 
scripts for 5 packages from the same source tarball. Yes, it's nice to have 
small packages for embedded stuff and small disks, but do you really want to 
raise the workload of the maintainer that much?

-Jim

From: Stephanie Daugherty
Sent: ‎8/‎14/‎2015 6:21 AM
To: T.J. Duchene; 
dng@lists.dyne.org
Subject: Re: [DNG] Devuan and upstream

On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene  wrote:

>
> 1.  You can't mark a package as "Do not install."  APT simply does not give
> you the option.
>
> Heaven knows, there are a lot of people who dislike things like network-
> manager, and do not them to install for any reason.
>
> Someone might say - wait you can put a hold on packages.  That's true, but
> that does not stop packages from being installed. It only says which
> version
> is preferred.  There is no option for "none".
>
> You can block packages with APT pinning, but using pinning is very
> esoteric.
>
> There's a less obvious, but more reliable solution that holding or
pinning., and that is the dummy package. equivs makes this pretty easy to
create - you simply need a package marked that conflicts with the undesired
software, or if you prefer, one which tells the system that package is
already installed, so that you can ignore the dependency at your own risk
and without any pestering from apt. .



> 2. Whenever an update has bug, you cannot rollback to the previous version
> of
> the package.  It is always assumed that the latest version is correct.  In
> the
> real world, we know that is not always true.
>

Sure you can, just not with apt. dpkg is still the actual package manager,
and will happily install older versions for you, so long as you take care
of the dependencies on your own. In many cases the previous packages are
still sitting around in apt's download directory, but if not, they can
usually still be found in the archives.

Besides, unless you follow unstable, this doesn't happen often enough to be
a serious concern, because of Debian's rigid "no functionality changes in
stable, only fixes" policy.

The situation in both of these cases should be better, but arguably, if
it's a direction Devuan decides to go in, it would be best to do so as
extensions to apt rather than reinventing the wheel, so as to keep as much
compatibility with Debian as possible and continue to use Debian as
upstream whenever possible.

Without Debian as an upstream, the task of maintaining Devuan even at
parity with Debian would be all but impossible for the small team of
maintainers and developers currently part of Devuan. Unless a very large
portion of the Debian community jumps ship, and Devuan becomes the base of
Debian rather than the other way around, I think this will have to continue
for the foreseeable future.
___
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] Devuan and upstream

[James Powell]

As someone who's background is in Slackware, I know where automatic package 
dependency resolution has its good points and bad points.

Pkgtools is very basic. Everything is left to the system administrator to 
resolve, but SlackBuilds.org offered a solution. It allows packages to have 
certain triggers like WITH_JPEG=yes ./.SlackBuild, but sbotools took it 
farther by scripting everything to work off the README, .info files, and the 
build scripts to resolve things at a controllable level without things getting 
complicated. Very akin to CRUX's and BSD's ports.

Devuan should follow the Debian methodology, but equally it should forge it's 
own path away from Debian. It doesn't need to draw from any other distribution 
like Funtoo, CRUX, Slackware, or anything other distributions, other than 
seeing what people are using and in need of. The wants will be many, but what 
users need will matter most of all.

Devuan should be Devuan.

That's all I can say on that for now.

-Jim

From: T.J. Duchene
Sent: ‎8/‎13/‎2015 1:06 PM
To: dng@lists.dyne.org
Subject: [DNG] Devuan and upstream

Everyone of course is welcome to comment but the question is really for the
Devuan team.Is the general plan is just to copy Debian, or are there plans
to make more changes than just systemd?

Debian APT is an example.  It's a good manager, but it falls short in some key
areas that are not unreasonable to ask from a package manager.

1.  You can't mark a package as "Do not install."  APT simply does not give
you the option.

Heaven knows, there are a lot of people who dislike things like network-
manager, and do not them to install for any reason.

Someone might say - wait you can put a hold on packages.  That's true, but
that does not stop packages from being installed. It only says which version
is preferred.  There is no option for "none".

You can block packages with APT pinning, but using pinning is very esoteric.


2. Whenever an update has bug, you cannot rollback to the previous version of
the package.  It is always assumed that the latest version is correct.  In the
real world, we know that is not always true.

The reason I am asking is that Debian clearly has no plans to fix any of these
problems.  They've been around for a decade or more.  I wonder if Devuan does
have any plans to correct Debian's shortcomings, regardless of what upstream
does?

For myself, before I'd consider spending the effort to look at ways of fixing
some things, I'd want to know that those efforts would be received or if they
would go against the overall plan of absolutely remaining compatible with
Devian upstream.

 For example, mentioning the problems above - if Devuan intends to eventually
break away from Debian, then redesigning the packaging process would be the
way to go, because you could handle rollbacks and other concerns.  If Devuan
plans to remain as close to Debian as possible, then perhaps a GUI attached to
synaptic to simplify pinning for the average user might be in order instead.

I'd just like to get some idea of what contributions to Devuan might be made
in the future.

T.J.




___
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] Congratulations to the Devuan team

[James Powell]

I'm just waiting for vdev-0.1 to get published. :D

-Jim

From: shraptor<mailto:shrap...@bahnhof.se>
Sent: ‎8/‎12/‎2015 4:13 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] Congratulations to the Devuan team

Vdev is now in a functional state and I use it on
my desktop everyday.

vdev is now doing everything I used udev for.

I however don't use it in initramfs where I use busybox mdev.

More testers would probably be good for more use-cases so
agreed now packaging would be desired.

But as I said before vdev(libudev-compat) + spacefm auto-detection of
plugged devices is working for me. I don't want automounting but I
believe it would be easy to setup with udevil!?


/Scooby


On 2015-08-12 12:48, James Powell wrote:
> We all know Devuan is going to create a huge ripple in the great big
> pond, and join the ranks of the pro-choicers in regards to software
> usage.
>
>  While I'm following vdev closely, mostly to backport it to another
> distribution, Devuan's success will bring success to other choice
> giving distributions as well.
>
>  It's a win-win situation finally.
>
>  -Jim
>
> -
>  From: tilt!
>  Sent: ‎8/‎12/‎2015 3:39 AM
>  To: dng@lists.dyne.org
>  Subject: [DNG] Congratulations to the Devuan team
>
> Hi,
>
>  I would like to convey my respect and appreciation to all
> participants,
>  acknowledging that Devuan GNU/Linux is in use here now as a
> functional
>  Linux Desktop which I use for tasks of software development and
> system
>  integration as well as for everyday mail, office and web stuff.
>
>  Good work! Keep it coming!
>
>  I definately look forward to vdev. Currently I try to involve myself
>  in testing it out a bit; it appears like a very elegant solution that
>  opens many interesting possibilities. I also heard that there is a
>  packaging effort, and I wonder how that is coming along.
>
>  I admit that in spite of issues I expressed previously on this list,
>  I currently use PolicyKit to enable some "administrative operations"
>  when using the system via XFCE4, simply because it's currently the
>  easiest way for me to do stuff like mounting hot-plugged disks or
>  managing libvirt guests.
>
>  But that clearly demonstrates the paradigm of "freedom of choice"
>  being successfully implemented in Devuan, where I can now freely
>  choose system components that serve my needs best.
>
>  Kind regards,
>  T.
>  ___
>  Dng mailing list
>  Dng@lists.dyne.org
>  https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng [1]
>
>
> Links:
> --
> [1] 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
___
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] Congratulations to the Devuan team

[James Powell]

We all know Devuan is going to create a huge ripple in the great big pond, and 
join the ranks of the pro-choicers in regards to software usage.

While I'm following vdev closely, mostly to backport it to another 
distribution, Devuan's success will bring success to other choice giving 
distributions as well.

It's a win-win situation finally.

-Jim

From: tilt!
Sent: ‎8/‎12/‎2015 3:39 AM
To: dng@lists.dyne.org
Subject: [DNG] Congratulations to the Devuan team

Hi,

I would like to convey my respect and appreciation to all participants,
acknowledging that Devuan GNU/Linux is in use here now as a functional
Linux Desktop which I use for tasks of software development and system
integration as well as for everyday mail, office and web stuff.

Good work! Keep it coming!

I definately look forward to vdev. Currently I try to involve myself
in testing it out a bit; it appears like a very elegant solution that
opens many interesting possibilities. I also heard that there is a
packaging effort, and I wonder how that is coming along.

I admit that in spite of issues I expressed previously on this list,
I currently use PolicyKit to enable some "administrative operations"
when using the system via XFCE4, simply because it's currently the
easiest way for me to do stuff like mounting hot-plugged disks or
managing libvirt guests.

But that clearly demonstrates the paradigm of "freedom of choice"
being successfully implemented in Devuan, where I can now freely
choose system components that serve my needs best.

Kind regards,
T.
___
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] Excessive bouncing

[James Powell]

The attachment is the html formatting my client uses. I think it's just a 
checksum file so just ignore it.

From: Go Linux<mailto:goli...@yahoo.com>
Sent: ‎8/‎11/‎2015 9:32 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>; James 
Powell<mailto:james4...@hotmail.com>
Subject: Re: [DNG] Excessive bouncing

I just got that message again too.  Yes, really annoying . . .

BTW, your inline attachments are not coming through the dng list.

----
On Tue, 8/11/15, James Powell  wrote:

 Subject: [DNG] Excessive bouncing
 To: "dng@lists.dyne.org" 
 Date: Tuesday, August 11, 2015, 11:16 AM

 Not
 to complain, but this bouncing problem is really getting on
 my nerves. What exactly is causing
 this?
 -Inline Attachment Follows-

 ___
 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

[DNG] Excessive bouncing

[James Powell]

Not to complain, but this bouncing problem is really getting on my nerves. What 
exactly is causing this?___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] non-systemd Linux for newbies with good migration tool?

[James Powell]

The best maintained are Slackware, CRUX, Funtoo, and AntiX.

-Jim

From: Isaac Dunham
Sent: ‎8/‎9/‎2015 6:14 PM
To: dng@lists.dyne.org
Subject: [DNG] non-systemd Linux for newbies with good migration tool?

Hello,
I'm looking for a Linux distro that I could recommend to friends who are
rather frustrated with Windows 10.
The friends in question ask me about how to fix problems with their
computers from time to time.

The essentials would be:
-has a *good* Windows migration assistant, which must be able to handle
 Windows 10; I know that Ubuntu used to have this.
-glibc-based, so that Flash and Avast Workstation will work
 (at least one of the friends in question uses avast on Windows)
-has Chromium (and preferably Chrome)
-has Open/LibreOffice (one of the friends in question has used OpenOffice
 on Windows since...7 or 8 years ago, I think)
-DE familiar to Windows users (if Trinity were more active, I'd go with
 that without hesitation; but I suspect properly configured Xfce or Mate
 may be better at this point.)
-can install to hard drive, though support for Live CD is desired.
-binary based

Highly preferred:
-not rolling release, since one of the friends in question is rather
 upset about the new Windows mandatory automatic update policy.
-non-systemd based, so that I can help debug issues; OpenRC or sysv-rc
 preferred
-dpkg/apt based, since that's the package manager I'm most familiar with.
-easy-to-navigate system administration GUI.
-wireless GUI that doesn't require preconfiguring wpa_supplicant.

A lot of these features are not what I use:
I last migrated from Windows about 5 years ago, so I have no idea
what the state of the art is; I use Links, Otter, and Iceweasel;
I haven't used OO/LO much in the last 3 years; I spend most of my time
in the terminal; the only desktop I use is CDE; ...
So I'd like some recommendations for something a little more mainstream.

Thanks,
Isaac Dunham

___
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] Systemd Shims

[James Powell]

G'evening,

On Sat, Aug 08, 2015 at 08:30:58PM +0100, Dave Turner wrote:
 From the look of Mark's website I was a bit disappointed not to find a link
 to www.davidicke.com!

Well... I'm fine with what I saw, I mostly don't care because his beliefs
are his own business. Yeah, even praising Ruby as the best lang is a personal 
belief, so transeamus. Off-topic.

 But, if the quick'n'dirty pragmatic solution is systemd shims then so be it
 as far as I am concerned.

Are we talking about systemd-shim the software by Canonical, or shims for 
systemd
compatibility?
The systemd framework is a byzantine pile
of features, so I can't say for sure whether stub functions added to 
init-neutral-to-be programs are hacks that
should be replaced ASAP with snippets of more unixy, maybe ad hoc components 
or with calls to a uniform API, or not.
logind is very difficult to emulate for example, but sometimes
you mightnt just add stubs, ending with applications full of holes or 
regressions...

--
Teodoro Santoni

Something is wrong. I don't wanna compile 20 KB of Go code to list files.
___
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] Systemd Shims

[James Powell]

 From the look of Mark's website I was a bit disappointed not to find a 
link to www.davidicke.com!
But, if the quick'n'dirty pragmatic solution is systemd shims then so be 
it as far as I am concerned.

DaveT


On 08/08/15 18:14, Go Linux wrote:
 On Sat, 8/8/15, Mark S Bilk m...@cosmicpenguin.com wrote:

   Subject: [DNG] Systemd Shims
   To: dng@lists.dyne.org
   Date: Saturday, August 8, 2015, 11:49 AM
   
   [cut]

   So please drop the fear of contamination, and consider the shims as a 
simple, inexpensive
   and effective wall of defense against systemd.
   
    Mark

 

 Interesting first post.  I don't see how becoming entangled forever with 
systemd is a solution.  Get to know Mark better at the URL implied in his email 
before embracing his 'wisdom'.

 golinux
   
 ___
 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



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

Re: [DNG] Init scripts in packages

[James Powell]

Currently Debian packages contains both systemd units and init scripts. 
However, Debian developers refused to support several init systems. So it's 
only a matter of time when they remove init scripts from packages.What will 
Devuan developers do when it happens? We can use sysvinit and Devuan because 
these init scripts exist.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Unmingling kdbus and the Linux kernel

[James Powell]

Sir,

I would like someone from Devuan to reply how Devuan DDs are going to
rid the Linux kernel when kdbus becomes integrated in it. I am finding
this latest news a heavy blow below the belt, as the kernel is usually
reserved for highly qualified and highly skilled coders.


Thanks for your time.
Edward
___
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] automount, mount, and USB sticks

[James Powell]

Eventually, and I kinda realized this, work may be needed to write a udisks 
replacement for vdev that can work off vdev without loosing functionality to 
udisks using applications and file managers, especially for non-Linux systems.

Nothing fancy, but as long as it works and allows for some level of control for 
admins, I don't have a problem with it.

Thoughts?

From: Hendrik Boom
Sent: ‎7/‎28/‎2015 7:45 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] automount, mount, and USB sticks

On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote:
> On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote:
> > Of course I have to guess whether the device has
> > been plugged in as /dev/sdb, or /dev/sde, or whatever.  In case of
> > (frequent) doubt, I switch to a root console with control-alt-F1 and a
> > login, unplug the device, and plug it in again.  It will the tell me
> > after a while, that a new device has been inserted, and tell me what
> > /dev/sd* name it has dynamically installed.  I end up, as root,
> > mounting the device with root as the owner.  It's usually a USB stick
> > with one of the ubiquitous Microsoft file systems used on USB sticks,
> > and all the files can be read or writen by root only.
>
> There is a much easier way. Instead of switching consoles and
> guessing, just plug the device in, and look at the last screen full of
> the output from dmesg.

Yes, that would have been easier.

> Also, if you're mounting on your own laptop, it
> will usually have one hd, /dev/sda. When you plug in a usb device, it
> will probably have /dev/sdb. If you unplug it, and plug in the same
> device, or plug in another stick, it will probably have /dev/sdb
> still.

For whatever reason, there was a time when it kept picking new letters
if I umounted the stick, took it ouot, and put another in.  Maybe there
was a bug somewhere then?  But I could not rely on it always being
/dev/sdb.

> So, you could just put a line in /etc/fstab which will allow a
> normal user to mount /dev/sdb1 for example to whatever directory you
> want. All you would have to do as a normal user is to type:
> mount /dev/sdb1
> after plugging in the drive, and you should be able to find its'
> contents under whatever directory you specified in fstab.

Truth is, I no longer trust it to be consistent.

-- hendrik

>
> 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
___
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] A better default windows manager

[James Powell]

I seriously doubt Xfce will go fully into systemd since they forked ConsoleKit2 
and have been updating it to perform all the work of logind.

I just wish Xfce would write their own automount utility to replace udisks.

From: Teodoro Santoni
Sent: ‎7/‎26/‎2015 12:17 PM
To: Steve Litt
Cc: dng@lists.dyne.org
Subject: Re: [DNG] A better default windows manager

Good evening,

On Sun, Jul 26, 2015 at 02:49:54PM -0400, Steve Litt wrote:
> I thought we'd decided on Xfce, and I'd thought that we managed to
> de-xxx-ize Xfce. Everyone (except me) likes Xfce, why not use it?
> It's trivial to use, even for somebody who's never seen it before.
> It's the Nano of the Window Manger/Desktop Environment world. You
> might not like it, but you can use it long enough to switch over to
> something else. It's somewhat reasonable about the resources it uses.

Thoughtful words, are these.
I don't mind Xfce, and I used it long enough to configure cwm and lemonbar.
It's the buildingblockest of all the DEs in X11 world imho.

--
Teodoro Santoni

Something is wrong. I don't wanna compile 20 KB of Go code to list files.
___
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] A better default windows manager

[James Powell]

CDE was the defacto desktop for many UNIX branded systems like IRIX, Solaris, 
HP-UX, and others until many replaced it with Gnome2, Xfce, KDE, and others.

Sun/Oracle replaced CDE with Java Desktop Environment back on Solaris 10 I 
believe when OpenSolaris was still being developed. I think Solaris uses a more 
traditional DE now though.

From: Jaromil
Sent: ‎7/‎25/‎2015 3:21 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] A better default windows manager

On Fri, 24 Jul 2015, T.J. Duchene wrote:

> >Not really, it wasn't a 'favorite' because it was not free.
> I'm just saying that actual CDE use was rather a niche.  Most used
> something else "back in the day."

didn't it ship by default with Sun and SGI machines?

I remember using it
as well something else perhaps, but very similar on Irix

but well, I did switch to Afterstep as soon as it came out

and recommend to keep an eye on GNUStep, slow but steady...


___
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] A better default windows manager

[James Powell]

I got it built on Slackware once but it wasn't too stable from when I last had 
tried it years ago with Solaris.

From: Marlon Nunes<mailto:nu...@openmailbox.org>
Sent: ‎7/‎24/‎2015 4:51 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] A better default windows manager

On 2015-07-24 20:48, James Powell wrote:
> CDE is a classic UNIX desktop, but it has long been since viable for
> modern usages.
>
>  Xfce, in truth, was a modern replacement for it using Xforms since
> Motif was, at the time, under a different license. It bears the same
> classic layout minus some differences.
>
>  However, last I had heard CDE was still unstable with some
> operations.

I'm building it on NetBSD-Current to see how it goes

>
> -
>  From: Marlon Nunes
>  Sent: ‎7/‎24/‎2015 4:31 PM
>  To: dng@lists.dyne.org
>  Subject: [DNG] A better default windows manager
>
> Guys what about a true UNIX and complete desktop environment to be the
>
>  'default' desktop for devuan 2.0?
>
>  here's what i'm talking about:
>
>  http://sourceforge.net/p/cdesktopenv/wiki/Home/ [1]
>  http://sourceforge.net/p/cdesktopenv/wiki/What%20is%20CDE%3F/ [2]
>
>  "CDE was designed with end users, software developers, and system
>  administrators in mind. It gives end users a consistent,
> customizable,
>  network-aware graphical user interface across workstations and PCs.
> CDE
>  gives software developers a single set of graphical user interface
> (GUI)
>  and desktop programming interfaces for all platforms that support the
> X
>  Window System,TM simplifying the task of creating and distributing
>  cross-platform applications."
>
>  "CDE includes session management, window and workspace management,
>  graphical file and object management, transparent data interchange
>  across platforms and applications, multi-user collaboration, desktop
>  productivity tools, a context-sensitive help system, an on-line
>  documentation browser, network services, an application builder,
>  industry-standard graphical user interface toolkits, and
> configuration
>  and management utilities."
>
>  The source code to the programs and libraries are released under the
> GNU
>  LGPL 2.0 or later.
>  Motif is under the LGPL as well.
>
>  Complete and Free. Just waiting for us to use and improving it.
>
>  http://www.opengroup.org/openmotif/docs/ [3]
>
>  --
>  Stop slacking you lazy bum!
>  ___
>  Dng mailing list
>  Dng@lists.dyne.org
>  https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng [4]
>
>
> Links:
> --
> [1] http://sourceforge.net/p/cdesktopenv/wiki/Home/
> [2] http://sourceforge.net/p/cdesktopenv/wiki/What%20is%20CDE%3F/
> [3] http://www.opengroup.org/openmotif/docs/
> [4] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

--
Stop slacking you lazy bum!
___
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] A better default windows manager

[James Powell]

CDE is a classic UNIX desktop, but it has long been since viable for modern 
usages.

Xfce, in truth, was a modern replacement for it using Xforms since Motif was, 
at the time, under a different license. It bears the same classic layout minus 
some differences.

However, last I had heard CDE was still unstable with some operations.

From: Marlon Nunes
Sent: ‎7/‎24/‎2015 4:31 PM
To: dng@lists.dyne.org
Subject: [DNG] A better default windows manager

Guys what about a true UNIX and complete desktop environment to be the
'default' desktop for devuan 2.0?

here's what i'm talking about:

http://sourceforge.net/p/cdesktopenv/wiki/Home/
http://sourceforge.net/p/cdesktopenv/wiki/What%20is%20CDE%3F/

"CDE was designed with end users, software developers, and system
administrators in mind. It gives end users a consistent, customizable,
network-aware graphical user interface across workstations and PCs. CDE
gives software developers a single set of graphical user interface (GUI)
and desktop programming interfaces for all platforms that support the X
Window System,TM simplifying the task of creating and distributing
cross-platform applications."

"CDE includes session management, window and workspace management,
graphical file and object management, transparent data interchange
across platforms and applications, multi-user collaboration, desktop
productivity tools, a context-sensitive help system, an on-line
documentation browser, network services, an application builder,
industry-standard graphical user interface toolkits, and configuration
and management utilities."

The source code to the programs and libraries are released under the GNU
LGPL 2.0 or later.
Motif is under the LGPL as well.

Complete and Free. Just waiting for us to use and improving it.

http://www.opengroup.org/openmotif/docs/


--
Stop slacking you lazy bum!
___
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] Will there be a MirDevuan "WTF"?

[James Powell]

So exactly what do we use in place of D-Bus as a replacement Userspace IPC 
handler and protocol that is Generic to POSIX systems and UNIX?

If we rip out D-Bus what do we use in it's place that is drop in compatible? 
You're talking about tearing apart a LOT of packages just to satisfy a 
grievance.

This is outside the scope and mission statement of Devuan, and I'm sorry if you 
dislike D-Bus so much, but it is accepted and POSIX compliant software. It's 
not perfect, but are any protocols that allow interapplication and interprocess 
communication across a system and network going to be not be complex to work?

Again, a witch hunt on software is not necessary, needed, or appropriate for 
Devuan.

From: miro.ro...@croatiafidelis.hr<mailto:miro.ro...@croatiafidelis.hr>
Sent: ‎7/‎23/‎2015 9:19 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] Will there be a MirDevuan "WTF"?

On Thu, Jul 23, 2015 at 11:06:29AM -0400, Hendrik Boom wrote:
> I do not understand this entire thread.
>
> I have not a clue what a MirDevuan "WTF" would be.
> What does the Mir" prefix contribute the the meaning?
> What does "WTF" mean in thei context.  I mean what the fuck?
>

> -- hendrik

(corrected typoes in your input, if that's not what you meant, cry foul!)

Hi, hendrik!

Yes, WTF probably means that (but they may have another excuse-name
along).

They were really outraged at the Debian Developers in charge for not
allowing the name, wait, I got to search for it... (I'll search from the
first message in this thread, the one with a host of links, by me)...
Yes I think it's in the first.

At first, one of the DD, Wookey, made:

systemd-must-die

find it in the:

How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php?f=20&t=116770&start=15#p550700
(second page)

I can remember and tell about it because I wrote to them:

(same topic)
http://forums.debian.net/viewtopic.php?f=20&t=116770&start=30#p552484
(third page)

but it was almost certainly censored out but the then provider of mine,

You can find the link in that same "stealth install" topic to:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, a Zerk Provider
https://forums.gentoo.org/viewtopic-t-999436.html

which if you open, you easily find:

status=bounced (host 127.0.0.1[127.0.0.1] said: 550-"JunkMail rejected -
147-226.dsl.iskon.hr (n4m3.localdomain) 550-[89.164.147.226]:41972 is in
an RBL, see 550

and you can, if you have time and are interested in fighting censorship,
study around there, as well as (not confirmed, only suspected):

https://lists.dyne.org/lurker/message/20150722.180226.3ff750a1.en.html
where find:

550 Unrouteable address (when I send email to Thorsten)

and imagine what happened. Did mirabilos quit Debian? I don't know, but
being that he provides packages for Debian, I don't think it's likely.

So if you are interested about why they call it that, that's probably
it. For more, one can read that resumé topic of mine, which although 12
forum pages, is much, much shorter than the very ample discussion on DD
List.

I wrote those forum pages of resumé for DD List discussions, after I
read pretty much all of the then recent DD mail archive,

So... The systemd-must-die was not allowed in the repository because of
the name. Everything is being killed all the time in Unix, jobs and
processes, but systemd was not allowed to die, by some moralist DD.

To be honest, I'm not sure about the details of the prevent-systemd
packages now. I would be if I were to install it, but I'm waiting for
Devuan to get dbus-free, or allow dbus freedom in some way... Maybe
mirabilos mada a package of his own, probably so, yeah, and didn't build
on wookey's package...

So I haven't (so far) made contact with Thorsten mirabilos Glaser, the
founder of MirBSD, but should Devuan eventually fail to provide a
no-dbus and no-poetterware desktop, I might have to, forced to search
for options, also be learning more about it...  Who knows. I won't be
running a dbus- or a poetterware- nothing.

But I hope you at Devuan will be working to get a distro that can be
installed hardened, no-dbus, no-any-poetterware and associates, and
maybe one of the ways might be forking the MirDebian WTF to MirDevuan
WTF for Devuan needs...

But I am really not a dev, and I really have spoken enough I believe.
Unless someone has questions, or either T.J Duchene or James Powell
decide to reply to my questions to them, or launch some counter
questions, I'll be looking for my exit from contributing to this
developers' list, and follow you silently.

The links to MirBSD are, in the 1st page above mentioned, only, use the
domain only:

MirBSD
https://www.mirbsd.org/

and it is called after his nickname, mirabilos, I believe.

--
Miroslav

Re: [DNG] Will there be a MirDevuan "WTF"?

[James Powell]

First off cool your jets, and trying call me out on knowing the internals of an 
IPC in Userspace I didn't develop is very childish.

I honestly don't care if D-Bus what it does other than be a communication and 
messaging relay between applications and processes, as long as it does what it 
does, and doesn't infringe on anything else.

D-Bus is used and is a requirement for some services and software. You're 
unfortunately not going to have your cake and coffee with getting rid of D-Bus. 
Yes, it's not the greatest design, but it is friendly at least to the whole 
UNIX spectrum.

Devuan's main purpose is getting rid of systemd as a hard dependency and 
allowing user choice in init software, not ripping apart every project to cater 
to ever niche and fundamentalist out there preaching what they feel is FOSS, 
and also to not start a witch hunt on software projects.

From: miro.ro...@croatiafidelis.hr<mailto:miro.ro...@croatiafidelis.hr>
Sent: ‎7/‎22/‎2015 9:43 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Cc: James Powell<mailto:james4...@hotmail.com>
Subject: Re: [DNG] Will there be a MirDevuan "WTF"?

On Wed, Jul 22, 2015 at 03:28:28PM -0700, James Powell wrote:
> D-Bus isn't great, but currently it is still a cross-UNIX IPC in
> userspace. BSD uses it, Illumos uses it, and so does GNU/Linux.
>
Since you would still like it around, in opportunistic or in some other
way that I should call it, I think a question is due.

Can you tell to the public what is the purpose of the
user-not-asked-about, in fact mostly user-never-even-knowing-about-it
encrypted ssh channel that dbus sets up, along with all the
non-GNU-compatible remote procedure calls (which are there for what
purpose?) that dbus implements?

Is that for FOSS stands for?

> D-Bus is way down my list of software to steer clear of any more.
Your choice. Does that mean you won't look favorably that us who don't
want dbus have a way with our Devuan installs? I hope not.
> 
> On Wed, Jul 22, 2015 at 02:51:59PM -0400, Steve Litt wrote:
> > On Wed, 22 Jul 2015 20:03:03 +0200
> > miro.ro...@croatiafidelis.hr wrote:
> >
> > > On Wed, Jul 22, 2015 at 11:50:44AM -0400, Jude Nelson wrote:
> > > > Vdev does not use dbus. [...]
> > > > -Jude
> > > [...] And I'm very glad that I was wrong!
> >
> > I'll say one thing though: Like miro.rovis, if I had my ideal system,
> > it would lack dbus. [...]
> And I have in my Gentoo alsa working perfectly (and surely: without
> pulseaudio), without dbus, really a nice, intrusion unfriendly install,
> and improving.
>
> And on my Debian when I mostly (not completely) succeeded in applying
> lots of stuff from:
>
> MirDebian "WTF" Repository
> https://www.mirbsd.org/~tg/Debs/debidx.htm
> [...]
> without [...]  poetterware. And I made that Tips page about it (see my
> first-in-this-thread mail). It's not as read as my Grsec Install Tips
> page for Debian (see my 1st mail), not only was, but still is (still
> is!), but it did grew to a few thounsad viewsi [...]
>
> Meaning, Debianers were able to follow it and clean their systems from
> systemd and dbus and pulseaudio with more or less success, or at the
> very least were eager too!
>

Regards!

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Multi-seat on Devuan, do we actually need that useless curiosity?

[James Powell]

There is ConsoleKit2...

From: Vlad
Sent: ‎7/‎22/‎2015 5:49 PM
To: dng@lists.dyne.org
Subject: [DNG] Multi-seat on Devuan, do we actually need that useless curiosity?

I think that the pretty useless feature which helped systemd into Debian in the 
first place was discussed some time ago.
As you might know multi seat is supposed  to make possible for multiple users 
to utilize a single desktop or laptop system in full blown GUI mode via special 
USB  hubs, the main selling point of this curiosity was as a way to run schools 
in 3rd world countries.
However these extension hubs actually cost more than a Raspberry Pi, and the Pi 
has the extra selling point that the student can take it home and use it there.
I do not see any real need for silly things like multi seat and with every 
nanometer less and every new cell phone the price and power consumption per Ghz 
falls.
There is also the cloud and BIOD to consider, as well as laptops and tablets.
In my opinion 99+% of users really won't care about this curiosity, which is a 
cool concept with less and less actual relevance or practical purpose behind it 
with every passing day.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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] Ashley Madison hack

[James Powell]

The problem with some of these known attacks are the effectiveness of each.

Example:

Last night I was thinking about how it could have happened, but actually during 
a system evaluation I did in my head, I actually hit a large wall.

Shadow can use cryptographic algorithms of at least 512-bit keys, and if 
combined with cracklib and Linux-PAM, presents a formidable defense if PAM is 
set to warn/deny and cracklib enforces a strong password with at least 14 
alphanumerical characters and symbols.

Even with orphcrack and a Rainbow Table, you're still going to be waiting a 
long time to which an Intrusion Detection System is going to alert someone.

As far as internet protocols, again a wall.

Library and Database injections are effective, but only against a weakened 
system and poor design and controls. Again, PAM and a SQL server would be 
problematic.

By that, we know at least one server was running Red Hat. Red Hat, by default, 
if I'm not mistaken, uses SELinux, PAM, and enforces Shadow with high 
encryption keys and Cracklib. This would make OpenSSH a problem due to it can 
be controlled with PAM.

You'd have to really spoof PAM and fool the IDS to some extent, and you have 
Firewalls to get past.

To do this without getting caught, you would need to have a clear path into the 
system via a Backdoor, and it would have had to exist, and be known, but so far 
this, from my own conclusion is circumstantial at best.

Even from my own thinking, this was a feet nothing short of interesting, and 
honestly, from an analytical point of view, I'd love to know how they did it.

From: Nuno Magalhães
Sent: ‎7/‎22/‎2015 12:09 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Ashley Madison hack

You're forgetting SQL injection and XSS, to name a few. Wireshark in a
cybercafé pops into mind too plus a gazillion of windows
vulnerabilities.

I'm placing no bets on Whether-or-not-it-was-systemd and find that
discussion moot unless there's any solid details on the hack.

Does Devuan keep up to date with known CVEs in its repositories (for
apache and what not) would qualify as devual-related and relevant.

And i try not to project my a/moral views on others so the fact the
site is about adultery is totally irrelevant to me, from a
computer-security perspective.

But that's just me.

Cheers,
Nuno
___
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] Will there be a MirDevuan "WTF"?

[James Powell]

D-Bus isn't great, but currently it is still a cross-UNIX IPC in userspace. BSD 
uses it, Illumos uses it, and so does GNU/Linux.

D-Bus is way down my list of software to steer clear of any more.

From: miro.ro...@croatiafidelis.hr
Sent: ‎7/‎22/‎2015 12:23 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Will there be a MirDevuan "WTF"?

On Wed, Jul 22, 2015 at 02:51:59PM -0400, Steve Litt wrote:
> On Wed, 22 Jul 2015 20:03:03 +0200
> miro.ro...@croatiafidelis.hr wrote:
>
> > On Wed, Jul 22, 2015 at 11:50:44AM -0400, Jude Nelson wrote:
> > > >
> > > >
> > > > If I was able to understand correctly, vdev works with dbus.
> > >
> > >
> > > Vdev does not use dbus.  No idea how or why you came to this
> > > conclusion. Search the code if you don't believe me.
> > >
> > > -Jude
> > I believe you. You never appeared dishonest to me. And I'm very glad
> > that I was wrong!
>
> Am I the only one who doesn't understand one word of this thread?
>
> I'll say one thing though: Like miro.rovis, if I had my ideal system,
> it would lack dbus. I was actually able to accomplish that with one
> alternate-initted Manjaro-OpenRC. No dbus. I used oss instead of alsa,
> and it worked great.
And I have in my Gentoo alsa working perfectly (and surely: without
pulseaudio), without dbus, really a nice, intrusion unfriendly install,
and improving.

And on my Debian when I mostly (not completely) succeeded in applying
lots of stuff from:

MirDebian "WTF" Repository
https://www.mirbsd.org/~tg/Debs/debidx.htm
(from another, the-then location, actually; and, speaking of changes, it
appears MirDebian WTF has even more to offer now then back then, and is
regularly updated)... Thorsten, are you reading this (see the attached
"550 Unrouteable address" in the 2nd mail of mine in this thread if
anybody wonder why I'ask)?

I, then, had my Debian running pure alsa as well (but couldn't get the
audio for TV-card to work...), and without most any of the other
poetterware. And I made that Tips page about it (see my
first-in-this-thread mail). It's not as read as my Grsec Install Tips
page for Debian (see my 1st mail), not only was, but still is (still
is!), but it did grew to a few thounsad views, it did. Ask golinux, xhe
was suprised I looked like talking to muself in that page...

Meaning, Debianers were able to follow it and clean their systems from
systemd and dbus and pulseaudio with more or less success, or at the
very least were eager too!

Regards!
--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
___
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

[DNG] Jeep Cherokee hacked

[James Powell]

http://www.foxbusiness.com/technology/2015/07/21/hackers-discover-way-to-remotely-control-jeeps/?cmpid=cmty_twitter_fb

It appears, from the looks of things, Ashley Madison isn't the only one getting 
hacked.

I'm wondering how this is happening so rampantly recently, but I'm trying hard 
not to point any fingers.

Does anyone know what OS is being used by these vehicles?___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] openRC

[James Powell]

Devuan appears to want to stick to sysvinit for the initial release. Afterwards 
however, is debatable, but regardless, sanity in init is going to be probably 
prevalent.

I too favor OpenRC as well as it is really a sane way to extend sysvinit.

From: Antonio Trkdz.tab
Sent: ‎7/‎21/‎2015 4:03 AM
To: Dng@lists.dyne.org
Subject: [DNG] openRC

Dear List,

I have been following your discussions with a lot of interest for quite a
bit now.
I really admire what you are doing as I really felt let down by Debian's
decision to prevent people to have a choice.

I am not a programmer and I consider myself an average user, I have been
using Debian for years and I was very happy with it.
I am using Wheezy right now and I am waiting for the stable release of
Devuan to make the switch.

I used Gentoo in the past and I remember that openRC was very easy to get
used to and appeared to get the job done fairly well and neatly.
Would it be useful to consider to adopt this system for forthcoming
releases of Devuan, since it is a complement of sysvinit?

This is just an humble thought from a non technical point of view, I hope
you take it for what it is.

Thank you all for your exceptional work.

Antoniotrkdz

P.S.: I am sorry if this question was already made in early conversations
and I missed it.
___
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] Upcoming Kali Linux 2.0 - systemd?

[James Powell]

Oh wow. I've used Kali for testing security on networking routers and firewalls 
myself. I hope they can switch out to Devuan also. Be a real shame to see them 
get plagued by systemd.

Often at times I forget how many specialized distributions for R&D and testing 
are Debian based.

From: Jaromil
Sent: ‎7/‎21/‎2015 2:51 AM
To: dng@lists.dyne.org
Subject: [DNG] Upcoming Kali Linux 2.0 - systemd?


dear list,

I'm sure you heard of Kali, likely most people here still remembers
Backtrack: there was a rename along the way. This is the most popular
distro packed with penetration-testing and networking tools, Debian
based.

since a while they have been forced to switch to systemd as any other
Debian derivative, now they are approaching a 2.0 release and of course
have problems with systemd which will likely lead to some weaknesses in
an otherwise pretty well hardened distro.

See: https://bugs.kali.org/view.php?id=1871 for instance they are
experiencing problems in avoiding daemons to start at boot.

Has anyone here contacts with Kali? At Devuan we would be delighted to
work with them to make it possible to have at least a systemd-free
flavor of Kali so that users don't have to struggle with the avalanche
and attack surface opened by it. Kali users are technical aware and have
solid concerns about security, I think working together to have at least
an alternative would be a win-win situation, as many Devuan developers
are also Kali users and we wouldn't have to do all this work by
ourselves then. It should be as easy as switching the source repository.

ciao


--
Jaromil, Dyne.org Software Foundry (est. 2000)
We are free to share code and we code to share freedom
Web: https://j.dyne.org Contact: https://j.dyne.org/c.vcf
GPG: 6113 D89C A825 C5CE DD02  C872 73B3 5DA5 4ACB 7D10
Confidential communications: https://keybase.io/jaromil

___
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] Newbie's lennard-gnomed

[James Powell]

The PC-BSD system-BS-D was an April Fools joke.

However, launchd is a completely different beast than systemd is. Launchd is 
more akin to SMF on Solaris/Illumos and s6 on GNU/Linux being init and service 
supervisors only, which are forward thinking.

They still require other daemons to manage the system, but cleanly provide 
hooks for existing services to work with without reconstituting everything from 
the ground, up, or just let the daemon work as intended separately.

I wouldn't mind launchd or SMF. They're doing init correctly, not ass backwards.

Sent from my Windows Phone

From: Martin Zatroch
Sent: ‎7/‎20/‎2015 4:48 PM
To: dng@lists.dyne.org
Subject: [DNG]  Newbie's lennard-gnomed 

Just to illustrate how the lennard-gnomed ideas creep 


"U can't be serious":
0.| http://blog.pcbsd.org/2015/04/huge-announcement-for-pc-bsd/

"And now for sth completely different":
1.| '20150629: The TrueOS fork of FreeBSD 10 has launchd running as init
and a JSON-aware launchctl utility, along with notifyd, libdispatch and
ASL integrated. This work has also been forward-ported to FreeBSD
-CURRENT. FreeNAS 10, which is also based on FreeBSD 10.1, will be using
launchd and a host of other tools ported from OS X / iOS. It has used
the original, and latest, Apple sources and ported them along with MACH
IPC.' - via https://wiki.freebsd.org/launchd &&
https://github.com/trueos/trueos/tree/freebsd11_mach

"Who could have though of that":
2.| https://www.haiku-os.org/blog/axeld/2015-07-17_introducing_launch_daemon

"Spy vs. Spy":
3.| 'At this time, there are no commercial requirements for the use of
SIMP outside of the purchase of Red Hat Enterprise Linux licenses as
applicable.' - via
https://github.com/NationalSecurityAgency/SIMP#forked-external-modules
(notice e.g.

"Demystifying systemd - 2015 Red Hat Summit":
4.| https://www.youtube.com/watch?v=S9YmaNuvw5U

"XKEYSCORE runs on":
5.| http://techrights.org/2015/07/08/red-hat-nsa/


Some extras ...


"The Half-Life of the Linux (as in kernel) Community a.k.a. Headcrab":
00| http://sysadmin.tme520.net/systemd-our-songs-of-innocence/

"James Clapper complains":
10|
https://firstlook.org/theintercept/2015/07/19/making-republican-snowdenista/

"Listen to what MinceR from the IRC has to say":
11|
https://lh3.googleusercontent.com/-MHjslFKY6Nk/U-OgTUuiKPI/RC8/6opC4AwL0LU/w1043-h865-no/2014%2B-%2B1


A bonus .. (=


"8-bit Commodore64 sweetness":
01|
http://remix.kwed.org/files/RKOfiles/Pepe%20Pinapple%20-%20Spy%20Vs%20Spy%20%28Data%20Retention%20Remix%29.mp3

_ _ _ _ _ _ _

Footnote: I cannot appreciate enough the veteran Unix admins' wisdom, so
am just quietly lurking. Plan9 FTW && http://git.2f30.org/sinit/ !=
https://gnu.org/software/dmd/ =P



___
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] startup scripts (was dng@lists.dyne.org)

[James Powell]

The boot scripts can be somewhat universal, but not always. Runit and s6 
require some very special and specific service and boot scripts for init, plus 
a lot of custom service scripts. These are what need the most attention. The 
init stage scripts are going to be unique to each init system as well.

Stage 1 in Runit is the one shot primary system startup sequences, while in s6, 
stage 1 is the init system script itself.

These can be translated between each as needed, but each init should be made to 
have it's own stuff. In the long term, the scripts will not need much 
maintenance if they are done correctly.

Sent from my Windows Phone

From: Didier Kryn
Sent: ‎7/‎18/‎2015 6:44 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] startup scripts (was dng@lists.dyne.org)

Le 18/07/2015 12:43, KatolaZ a écrit :
> On Sat, Jul 18, 2015 at 09:52:18AM +0200, Didier Kryn wrote:
>
> [cut]
>
>>   Further more, a method could be agreed on to tell the script if
>> the daemon is going to be supervised or not, and we would then need
>> only one script for all cases.
>>
>>  For example, providing "supervised-start" and
>> "supervised-reload" in addition to the other cases could do the job.
>> For safety, the scripts could check a file which tells them which
>> supervisor is calling them.
>>
>>  What do you think?
>>  Didier
>
> How do you support init scripts for several init systems for all the
> daemons that could be installed in a distro like Devuan? Who should do
> this work? Who should keep things updated and synchronised to allow
> the whole process to be neat and clean? Guys, if one apt-get installs
> --force-yes the default editor, and things go wrong, it's not a big
> issue. If we do the same on init, it's back to dice
> rolling... (cit. moria).
>
> My2Cents
>
> KatolaZ
>

 Dear KatolaZ,

 I probably didn't express things properly. My idea was precisely a
way to workaround the issue you say. The idea was to modify the existing
sysv-init scripts so that, while remaining 100% compatible with
sysv-init, they become also usable by supervisors. If it proved possible
and a standard method was agreed on, then I am convinced the authors of
these daemons would do it upstream.

 Alas, supervision experts don't think it is possible :-(

 Didier


___
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] dng@lists.dyne.org

[James Powell]

I never said it was set in stone.

All I suggested was if you install a package like SDL, then you install all of 
SDL, not just part of it. This reduces overhead of making multiple packages, 
simplifies the distribution, and makes the work of the package maintainer 
easier.

To a new person using Devuan, they see multiple packages that are for various 
purposes.

They ask, what are all these for?

Some might ask, Why not just one simple package?

That's where Devuan can bring packaging sanity in as well.

From: KatolaZ<mailto:kato...@freaknet.org>
Sent: ‎7/‎17/‎2015 3:45 PM
To: James Powell<mailto:james4...@hotmail.com>
Cc: KatolaZ<mailto:kato...@freaknet.org>; T.J. 
Duchene<mailto:t.j.duch...@gmail.com>; 
dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] dng@lists.dyne.org

On Fri, Jul 17, 2015 at 03:19:06PM -0700, James Powell wrote:
> It is diverse bur equally its overbearing to weed through sub-packages to get 
> the right package you need.
>
> Ports are packages from source. Gentoo, Funtoo, and CRUX all use packages 
> built and installed from source, and only meet dependencies for which you the 
> system administrator has choice over. If I want to build vim for xorg I can, 
> if not, so be it. It is still a package in the end, just more fine tuned.
>
> Plus, how is a blind "./configure && make && make install" bad? Yes, FHS 
> often requires files be in various locations, and that's fine, but prior to 
> final packaging, they can be moved and linked as needed. That's why you can 
> insert various arguments into ./configure.



If I wanted to compile every package from source, I would have used
gentoo or FreeBSD with ports, not Debian or Devuan... There is no need
to transform Devuan into Gentoo. There is already Gentoo for that.

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] dng@lists.dyne.org

[James Powell]

It is diverse bur equally its overbearing to weed through sub-packages to get 
the right package you need.

Ports are packages from source. Gentoo, Funtoo, and CRUX all use packages built 
and installed from source, and only meet dependencies for which you the system 
administrator has choice over. If I want to build vim for xorg I can, if not, 
so be it. It is still a package in the end, just more fine tuned.

Plus, how is a blind "./configure && make && make install" bad? Yes, FHS often 
requires files be in various locations, and that's fine, but prior to final 
packaging, they can be moved and linked as needed. That's why you can insert 
various arguments into ./configure.

From: KatolaZ<mailto:kato...@freaknet.org>
Sent: ‎7/‎17/‎2015 1:47 PM
To: James Powell<mailto:james4...@hotmail.com>
Cc: T.J. Duchene<mailto:t.j.duch...@gmail.com>; 
dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] dng@lists.dyne.org

On Fri, Jul 17, 2015 at 12:06:59PM -0700, James Powell wrote:
> It's not just that, but why are there so many broken down packages? -bin, 
> -dev, -meta, -src, -lib, -doc, etc.  my God do we need this many? Many 
> distributions use just one all inclusive package to avoid problems unless its 
> a temporary dependency build time only. Yes, I'd say it broken, far worse 
> though that one can realize, and far confusing to some people as well.
>
> If you run "./configure && make && make install" you get an all inclusive 
> package. That's in every handbook and textbook I've read too.
>
> This structured, repurposed, and tiered package system is utter nonsense. 
> There's packages that install nothing but a symlink for crying out loud!
>
> What .deb packages need is simplification, not more convulsion to muck things 
> up and complicate things worse for new uses.

But do you have in mind any concrete example of how such an
alternative package systems should work (and, please, don't mention
BSD-like ports, because that is not a package system) or yours is just
an undefined theory?

What you consider "so many broken down packages" is actually what has
allowed Debian to provide the largest and most stable software base a
single distribution has ever put together. Just to make an example, I
don't really see the point of installing the header files of every
single library you use in your system, which is what you would obtain
by a blind ./configure && make && make install. I am sure you don't
want that either. I believe that you perhaps are underestimating a bit
the amount of work needed to have packages that "behave nice to each
other", as you normally do in what we call a "distribution".

You know, *in theory* there should not be any difference between
theory and practice, BUT *in practice* usually theory does not have
that much to do with practice...

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] dng@lists.dyne.org

[James Powell]

It's not just that, but why are there so many broken down packages? -bin, -dev, 
-meta, -src, -lib, -doc, etc.  my God do we need this many? Many distributions 
use just one all inclusive package to avoid problems unless its a temporary 
dependency build time only. Yes, I'd say it broken, far worse though that one 
can realize, and far confusing to some people as well.

If you run "./configure && make && make install" you get an all inclusive 
package. That's in every handbook and textbook I've read too.

This structured, repurposed, and tiered package system is utter nonsense. 
There's packages that install nothing but a symlink for crying out loud!

What .deb packages need is simplification, not more convulsion to muck things 
up and complicate things worse for new uses.

From: T.J. Duchene
Sent: ‎7/‎17/‎2015 11:53 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] dng@lists.dyne.org

KatolaZ:

> > > You guys talk about supporting half a dozen init systems like it
> > > was similar to providing half a dozen different editors, which
> > > believe me is not quite the case.

hendrik:

> You're arguing for setting up the framework that makes it possible,
> rather than to do the heavy lifting.  It would also provide those who
> want to make various package-maintainers a path to follow to make
> their packages suitable for multiple inits, in case they whould
> choose to do so.
>

Hi, guys!  Just my two cents!


Just to be clear, before I say anything else, I am not talking about
Devuan 1.  That's set in stone. As far as the future, I personally
think that init freedom/flexibility is something that really needs to
be evaluated, so that Devuan does not fall into the same mono-culture
trap that Debian has.  One of Devuan's key concerns should be the
avoidance of mono-culture thinking.

I actually read somewhere that Ubuntu is already planning on abandoning
the Deb format in favor of something new.  I wasn't too thrilled with
the idea at first, but the more I thought about it, the more I am
convinced that something has to change.  Ian Murdoch who
founded Debian, advocated changing the way things are done (when he
started Progeny, but because he wasn't the head of Debian he was
basically ignored).  Debian packaging practices NEED to change as needs
change, and they haven't. Even RedHat has changed their packaging more
than Debian.

It was packaging that led to Debian's systemd versus S5 fracas
in the first place. Being a programmer and having packaged software for
both Debian and RedHat style Linuxes, I see absolutely no reason why it
is not technically feasible to support multiple init systems.  Even if
you know how to man-handle APT, there are too many longstanding issues
in Debian packaging that never get any attention at all, because the
vast majority of the Debian developers always use Sid. There are no
delta support. There are no (or very few) alternative package chains.
There are no really reliable methods of rollback for a bad package.

One thing that drives me crazy is that you cannot pull updated
source code to use on Debian Stable from the other  Debian branches for
a local apt-build without ridiculously convoluted configuration
(if it works at all). It's actually the lack of any real change in the
packaging that has started me looking at other Linuxes for a
replacement.

Debian packaging has become to rigid and inflexible.

Thanks!  See you all soon =)
T.J.


___
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] Mate

[James Powell]

If they don't use systemd dependencies then yes, otherwise, no.

Sent from my Windows Phone

From: Stanley Webb
Sent: ‎7/‎17/‎2015 11:17 AM
To: Dng@lists.dyne.org
Subject: [DNG] Mate

Will it be possible to install *.deb's in Devuan? I ask because I like
the Mate desktop, and they offer deb installs at their site
mate-desktop.org. also libreoffice offers deb at their site
www.libreoffice.org.

Stan
___
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 am not using systemd and plan to avoid it

[James Powell]

I care that my PID1 isn't going to have an instance where it could crash by 
doing something it shouldn't, and bloat itself in my virtual memory.

Sent from my Windows Phone

From: KatolaZ
Sent: ‎7/‎17/‎2015 1:13 AM
To: Gregory Nowak
Cc: dng@lists.dyne.org
Subject: Re: [DNG] I am not using systemd and plan to avoid it

On Thu, Jul 16, 2015 at 04:36:02PM -0700, Gregory Nowak wrote:
> On Thu, Jul 16, 2015 at 08:33:48AM +0200, Michael Bütow wrote:
> > Happy to say that after I voted it was 633 users "for" and 634 "against"
> > (not planning to use it).
> >
> > Due to the construction of the poll, the "plan to avoid" figure includes
> > those of us who will be forced to use it anyway due to work requirements
> > etc.
> > I feel the poll would be better if it had a more explicit option "I am
> > not using systemd and do not want to, but am forced to use it at work".
> > This would give a clearer indication of the "coercion factor".
>
> I would have liked to see another one which says I am not using
> systemd, but have tried it out beforehand.
>

I would have liked to see a more realistic one which says "What are
systemd and sysvinit used for?". Again, in my little experience the
striking majority of users really don't care about which process they
have as PID 1.

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
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] devuan LTS

[James Powell]

The core of any distribution is very akin to what you could draw from an LFS 
book, with some reasonable extras like those with Gentoo/Funtoo to create not 
just a basic core system, but a working base model. Yes, it could be very easy 
to maintain, and keep tools stable for long periods.

However, when you think about creating possibly universal build scripts that 
can work with FreeBSD, Illumos, and GNU/Linux equally, you can support various 
systems easily, in theory.

Devuan not only could build a great GNU/Linux base, but create a UNIXwide 
framework as well. Now, I don't know how well it would work, truly, but instead 
of creating rifts between UNIX and UNIXlike systems, like systemd wants to do, 
create a unified UNIX cross platform framework to bring BSD, Linux, Illumos, 
and others back together, and do things right.

Sent from my Windows Phone

From: Stephanie Daugherty<mailto:sdaughe...@gmail.com>
Sent: ‎7/‎17/‎2015 2:25 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] devuan LTS

On Fri, Jul 17, 2015 at 1:50 AM James Powell  wrote:

>  There is one thing I would recommend different that the standard Debian
> model. Release only the right amount of packages to create a working
> operating system under a complete installation, and dedicate the rest of
> all packages to Debian friendly build scripts for packages of the
> non-sequitur ranks to keep anything and everything optional, as that,
> optional.
>
> This might help other non-Linux distributions like kfreebsd and killumos
> (Dyson) formulate strategies for packages.
>
> Any thoughts on this?
>
>
>
This is a model that I've had thoughts about for a while, originally
spurred on by the old Fedora Core/Extras division and refined by Ubuntu's
PPA model - although for different reasons entirely.

What'd I'd be interested in seeing is this:

- A "core distribution" consisting of the kernel, base system, openssh(d)
and enough of the development toolchain to build packages - and nothing
else - basically a stable set of core libraries, ABI, and userland
utilities that could go untouched for a long period of time.

- A modular system of self-contained repositories with their own much
faster lifecycles for everything else, with an emphasis on encouraging
upstream vendors to provide their own repositories.

The advantages:
-  a leaner "core distribution" would be maintainable for a longer period
of time
- modular repositories for everything else would keep it from being stale -
a different kind of balance between long term stability and rolling
releases.
- any LTS for each of the modular components could align strictly with the
upstream maintainer's LTS strategy, rather than the distribution's release
schedule, so the distribution would bear much less burden for supporting
these packages and the "blame your distribution" game would be lessened.
___
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] devuan LTS

[James Powell]

It's about sanity really and keeping things as simple as possible, but as sane 
as possible in the long term. Read that right... The long term.

Sent from my Windows Phone

From: Gregory Nowak
Sent: ‎7/‎16/‎2015 10:44 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] devuan LTS

On Fri, Jul 17, 2015 at 07:25:10AM +0200, Adam Borowski wrote:
> The year of updates was general availability.  When that ended, regular
> squeeze archives got moved away, and a new repository, squeeze-lts, was
> created.  And it's still alive and supported, on a set of architectures
> reduced to amd64 and i386.

Something else I wasn't aware of, thanks for pointing it out. So let
me rephrase this as something that debian has, and that I would like
to see continued in devuan if possible. I think James' proposal isn't
a bad one. Maintaining a release three-four releases back with a year
after that for updates comes out to about five years if I understand
what James said correctly. That sounds fine to me.

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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan LTS

[James Powell]

There is one thing I would recommend different that the standard Debian model. 
Release only the right amount of packages to create a working operating system 
under a complete installation, and dedicate the rest of all packages to Debian 
friendly build scripts for packages of the non-sequitur ranks to keep anything 
and everything optional, as that, optional.

This might help other non-Linux distributions like kfreebsd and killumos 
(Dyson) formulate strategies for packages.

Any thoughts on this?

Sent from my Windows Phone

From: Stephanie Daugherty<mailto:sdaughe...@gmail.com>
Sent: ‎7/‎16/‎2015 10:37 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] devuan LTS

ILTS just doesn't make sense with a release cycle that's already set to be
one of the slowest in the Linux world. Debian, and now Devuan releases are
extremely conservative. N+1 cycles are good enough. The manpower that would
be required to maintain 4, 5, or more more supported "released" branches is
manpower that could be better spent elsewhere - improving the release
engineering and working through the backlog of bugs.


IMHO the enterprise mindset does more harm than good, because deferring
change creates a vicious cycle, where the accumulated breakage of half a
decade between each release prompts cries for even more time, and more
breakage, meanwhile more dirty hacks and accumulated cruft build up within
that organization's infrastructure, adding to the fragility and
breakage. Meanwhile, developers demand newer libraries, runtimes, and
components for applications - as the "solution" to any problem from
upstream maintainers is ALWAYS to run the latest stable upstream version
come hell or high water, and the first time that developer tries to use a
feature that's the documentation says is there but's not in the decade-old
version that happens to be available, they demand updates - which then get
compiled from source or installed from packages obtained from god knows
where, along with a slew of dependencies.

A reasonable, conservative release cycle, coupled with the 4 branch
(unstable, testing, stable, oldstable) and a FIRM  n+1 support policy
minimizes the cost of support, sets firm expectations for EOL, and provides
more than enough time to test, qualify, and migrate, while forcing
organizations to address their infrastructure's growing technical debt
while they still have the institutional memory to understand how. If you
can't do this in the 2 years that typically go between releases,  then your
problem is not that the releases are too fast, it's that your organization
is institutionally incompetent.

On Fri, Jul 17, 2015 at 12:57 AM James Powell  wrote:

>  An LTS branch isn't needed if you do version controlled releases and
> sponsor support for versioned releases for at least 3-4 versions back.
>
> To be fair, I've used Slackware long enough to see how maintaining a
> versioned release can go right, and seen enough of Ubuntu to see how it can
> go horribly wrong.
>
> Devuan should have at least 3 branches.
>
> Versioned releases released on annual cycles as packages mature.
>
> Unstable but tested branch similar to Slackware-Current in which Versioned
> releases are established.
>
> Experimental branch for new packages that aren't tested or just slightly
> tested for buildability in a working environment that will determine what
> goes into Unstable. This branch should also NOT be part of the mainline
> availability but accessible through a git/svn/cvs client only for safety
> reasons, namely preventing someone from blowing their system to Hell.
>
> As releases mature, 1.0 would be maintained until the fourth or fifth
> release year following, then pastured, regardless of version number. The
> only time the main number should be changed is IF and ONLY IF glibc is
> updated, otherwise 1.0 would transmigrate to 1.1.
>
> How does that sound?
>
> Sent from my Windows Phone
>  --
> From: Adam Borowski 
> Sent: ‎7/‎16/‎2015 9:44 PM
> To: dng@lists.dyne.org
> Subject: Re: [DNG] devuan LTS
>
>  On Thu, Jul 16, 2015 at 09:39:41PM -0700, Gregory Nowak wrote:
> > the recent discussions here have made me think about what features I
> > would like devuan to have which debian doesn't currently have. One
> > feature that comes to mind is a long term support branch like what
> > ubuntu has.
>
> Since squeeze, every release has amd64+i386-only long term support.
>
> --
> ⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
> ⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
> (https://github.com/kilobyte/braillefont for this hack)
> ___
> Dn

Re: [DNG] devuan LTS

[James Powell]

An LTS branch isn't needed if you do version controlled releases and sponsor 
support for versioned releases for at least 3-4 versions back.

To be fair, I've used Slackware long enough to see how maintaining a versioned 
release can go right, and seen enough of Ubuntu to see how it can go horribly 
wrong.

Devuan should have at least 3 branches.

Versioned releases released on annual cycles as packages mature.

Unstable but tested branch similar to Slackware-Current in which Versioned 
releases are established.

Experimental branch for new packages that aren't tested or just slightly tested 
for buildability in a working environment that will determine what goes into 
Unstable. This branch should also NOT be part of the mainline availability but 
accessible through a git/svn/cvs client only for safety reasons, namely 
preventing someone from blowing their system to Hell.

As releases mature, 1.0 would be maintained until the fourth or fifth release 
year following, then pastured, regardless of version number. The only time the 
main number should be changed is IF and ONLY IF glibc is updated, otherwise 1.0 
would transmigrate to 1.1.

How does that sound?

Sent from my Windows Phone

From: Adam Borowski
Sent: ‎7/‎16/‎2015 9:44 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] devuan LTS

On Thu, Jul 16, 2015 at 09:39:41PM -0700, Gregory Nowak wrote:
> the recent discussions here have made me think about what features I
> would like devuan to have which debian doesn't currently have. One
> feature that comes to mind is a long term support branch like what
> ubuntu has.

Since squeeze, every release has amd64+i386-only long term support.

--
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)
___
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] dng@lists.dyne.org

[James Powell]

Yes, but I mean alts like s6, Runit, etc. In the past these were left to the 
users to make for themselves. For these to be viable, they need full script 
sets ready to go.

Sent from my Windows Phone

From: T.J. Duchene<mailto:t.j.duch...@gmail.com>
Sent: ‎7/‎16/‎2015 7:18 PM
Cc: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] dng@lists.dyne.org

>  Throwing users to the wolves is not an option, and never should have
been one. Either an init script set be complete and maintained, or don't
bother including it.

Actually, I think that is Debian's POV too.  Since they are switching to
Systemd, no one is maintaining the S5 scripts, so in all likelihood they
will be dropped in the future.  I don't blame them for that, but it is
unfortunate.  Systemd still has some annoyances.



On Thu, Jul 16, 2015 at 9:08 PM, James Powell  wrote:

>  And if ANY alternative init system is offered, COMPLETE script sets
> should be offered. No more throwing users to the wolves. There is no excuse
> for this.
>
> This crap caused enough problems leading many people I've known to avoid
> alternatives. Throwing users to the wolves is not an option, and never
> should have been one. Either an init script set be complete and maintained,
> or don't bother including it.
>
> Sent from my Windows Phone
>  --
> From: Steve Litt 
> Sent: ‎7/‎16/‎2015 6:29 PM
> To: dng@lists.dyne.org
> Subject: Re: [DNG] dng@lists.dyne.org
>
>  On Thu, 16 Jul 2015 18:01:43 -0700
> Gregory Nowak  wrote:
>
> > On Thu, Jul 16, 2015 at 06:18:09PM -0500, T.J. Duchene wrote:
> > > If I might say so, I think that Devuan's short-term goal should be
> > > to get a release out as soon as possible, as close to Debian Jesse
> > > as possible.
> >
> > I agree with James and T.J. here. Devuan 1.0 should be debian 8 sans
> > systemd.
>
> Me too.
>
> > As for which init system to use, I vote for sysvinit with
> > sysvinit scripting.
>
> Me too. I know how much effort needs to be put into alt-inits, and I'm
> sure moving to a superior init like Epoch, s6 or runit is something
> better done in a much later version. Sysvinit still has plenty of life
> left in it, and we all have 15 years experience with it.
>
> > This is what folks coming to devuan from debian
> > wheezy will be familiar with, and I know that's what I would expect to
> > find when installing/upgrading to devuan from wheezy.
>
> > Those who want
> > other init systems should know how to install them without having them
> > forced on those of us who prefer what we're used to.
>
> Yes we should. It's not that hard. And we should be ready, willing and
> able to document our trials and tribulations and successes so that
> *some day*, a long time from now, Devuan might choose a different init,
> if so desired. There's no rush.
>
> > > After that, I think that Devuan should focus on what would be
> > > needed to provide user choice for the next release.  This is just
> > > my opinion, but I think that Devuan should pursue the goal that Ian
> > > Jackson left Debian over: making sure that the user can use
> > > whatever init they choose: be it System V, OpenRC or Systemd.
>
> I personally wouldn't jump through any hoops to get it to work with
> Systemd. First of all, if you want Devuan with Systemd, what you really
> want is Debian. Second, just like runit or s6 or Epoch, let users who
> want Systemd compile and install it extra-distro. If doing so is
> anything like runit, s6 and Epoch, that's not hard at all.
>
> But that's all in the future.
>
> SteveT
>
> Steve Litt
> July 2015 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> 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
>
>
___
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] dng@lists.dyne.org

[James Powell]

And if ANY alternative init system is offered, COMPLETE script sets should be 
offered. No more throwing users to the wolves. There is no excuse for this.

This crap caused enough problems leading many people I've known to avoid 
alternatives. Throwing users to the wolves is not an option, and never should 
have been one. Either an init script set be complete and maintained, or don't 
bother including it.

Sent from my Windows Phone

From: Steve Litt
Sent: ‎7/‎16/‎2015 6:29 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] dng@lists.dyne.org

On Thu, 16 Jul 2015 18:01:43 -0700
Gregory Nowak  wrote:

> On Thu, Jul 16, 2015 at 06:18:09PM -0500, T.J. Duchene wrote:
> > If I might say so, I think that Devuan's short-term goal should be
> > to get a release out as soon as possible, as close to Debian Jesse
> > as possible.
>
> I agree with James and T.J. here. Devuan 1.0 should be debian 8 sans
> systemd.

Me too.

> As for which init system to use, I vote for sysvinit with
> sysvinit scripting.

Me too. I know how much effort needs to be put into alt-inits, and I'm
sure moving to a superior init like Epoch, s6 or runit is something
better done in a much later version. Sysvinit still has plenty of life
left in it, and we all have 15 years experience with it.

> This is what folks coming to devuan from debian
> wheezy will be familiar with, and I know that's what I would expect to
> find when installing/upgrading to devuan from wheezy.

> Those who want
> other init systems should know how to install them without having them
> forced on those of us who prefer what we're used to.

Yes we should. It's not that hard. And we should be ready, willing and
able to document our trials and tribulations and successes so that
*some day*, a long time from now, Devuan might choose a different init,
if so desired. There's no rush.

> > After that, I think that Devuan should focus on what would be
> > needed to provide user choice for the next release.  This is just
> > my opinion, but I think that Devuan should pursue the goal that Ian
> > Jackson left Debian over: making sure that the user can use
> > whatever init they choose: be it System V, OpenRC or Systemd.

I personally wouldn't jump through any hoops to get it to work with
Systemd. First of all, if you want Devuan with Systemd, what you really
want is Debian. Second, just like runit or s6 or Epoch, let users who
want Systemd compile and install it extra-distro. If doing so is
anything like runit, s6 and Epoch, that's not hard at all.

But that's all in the future.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
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] dng@lists.dyne.org

[James Powell]

If the goal of Devuan is Debian sans-systemd, then no changes other than 
rebuilding packages to exclude systemd support is needed.

No changes need to be made to anything other than the init couplings.

There is no debating vi or nano. That's just B.S. What we should be concerned 
with is what to do about the sysvinit script set. That and only that should be 
the goal.

Do we do sysvinit with sysvinit scripting?
Do we do sysvinit with bsdinit scripting?
Do we do sysvinit with OpenRC?

My suggestion, keep init as humanly simple as possible. How you do that is up 
to you, but, and in my opinion only, OpenRC is nice, easy, user friendly, etc. 
and Manjaro and Gentoo have great scripts that transfer well between systems.

Sent from my Windows Phone

From: John Jensen
Sent: ‎7/‎16/‎2015 1:28 PM
To: dng@lists.dyne.org
Subject: [DNG] dng@lists.dyne.org

I agree with T.J. that Devuan should stay as close to Debian as possible
and it should include vi. If I have to get my little vi book out to
function in vi I will :)

On an unrelated, I appologize for the length of the email I forwarded about
a potential interview. I should have copied and pasted the relevant portion.

John



Message: 5
Date: Thu, 16 Jul 2015 15:00:35 -0500
From: "T.J. Duchene" 
To: Isaac Dunham 
Cc: dng@lists.dyne.org
Subject: Re: [DNG] Proposed defaults changes
Message-ID: <20150716150035.7864fb61@
Workstation.lan>
Content-Type: text/plain; charset=US-ASCII

Guys, if you don't mind my saying so, I think that change to the sake of
change is really not very useful.

More importantly, Devuan needs to keep vi installed in any case, in
order to conform to the POSIX standard. I'm tired of the Linux
community deciding to ignore UNIX standards.  If Devuan is going to
break even further from away from POSIX then the usual Linux, then to be
perfectly honest, I will not be using it.

At the very least can we agree that if we are going to change things
that a POSIX metapackage is needed so that conformance can be obtained
as close as possible with ease?

Thanks!  Have a great day! =)

T.J.
___
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] systemd in wheezy, was: Re: bummer

[James Powell]

The thing about OpenEC scripts are is that they can be generalized for any 
distribution and work off of configuration files.

Nobody ever said any init script is supposed to be easy. Init is complex, but 
it is supposed to have some complexity due to the fact you are starting and 
stopping critical system services.

For complex services like udev it will be hell. For simpler services like cups 
it might not be. But init will have some level of complexity but once you have 
it right, you can literally baby it along.

Also eudev and udev should be interchangeable with OpenRC. I use a very custom 
Slackware box with OpenRC, eudev, and some other stuff, but it's not a pain.

As far as Funtoo? Funtoo is a nice system. Run either experimental or unstable 
for the newest stuff. Used it and loved it, but hard to figure out the 'use' 
arguments at times.

I just stuck with LFS+ZFS+OpenRC personally.

Sent from my Windows Phone

From: Steve Litt
Sent: ‎7/‎16/‎2015 10:28 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] systemd in wheezy, was: Re:  bummer

On Wed, 15 Jul 2015 15:07:46 -0400 (EDT)
Rob Owens  wrote:

> - Original Message -
> > From: "Steve Litt" 
>

> > I did a lot of work with Gentoo over the weekend, and from my
> > perspective, although Gentoo inits with OpenRC, it seems to default
> > to udev, not eudev, and there's way to much systemd type stuff for
> > my taste. They even have those wonderful "Predictable Network
> > Interface Names"
> > (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/).
> > Silly me, I thought eth0 was predictable.
> >
> > I know I can get back eth0 with a kernel argument, but I'm just
> > illustrating how var Gentoo has gone down the systemd path.
>
> Steve,
>
> If you're interested, give Funtoo a try.  I've been using it lately
> and I like it.  It uses OpenRC and eudev.  The maintainers have a
> fairly anti-systemd stance.

Thanks Rob. Funtoo is next on my list. I failed at my last Funtoo
attempt because I couldn't get a bootloader configured, so I could only
use it by booting with System Rescue CD and chrooting.

So the last couple days I went back and learned more about LILO, and
I'm ready to try Funtoo again. Like Devuan itself, Funtoo has made a
statement that it will never use Systemd.

>
> I am of the belief that sysvinit isn't all that bad, and I'd rather
> use it than learn something new.

:-) Systemctl and Journalctl are old?

But yeah, I know what you mean.

> But I've found OpenRC relatively
> easy to understand and work with.

:-)

Once I get Funtoo working, my first step will be to alt-init using
either Epoch, s6, runit, or Suckless Init + daemontools-encore +
LittKit.

You know, the systemd fanboiz back on Debian-User were right about one
thing: Sysvinit is old, complicated, and a mess. OpenRC *requires*
sysvinit or something very much like it as PID1, and then for process
management substantially reproduces a lot of sysvinit's problems, such
as the init scripts from hell.

Can you imagine a Funtoo box with a really simple init? The ultimate in
repairability.

NOTE: Nothing I said in this email should be construed to be a vote
against Devuan defaulting to sysvinit. Our devs have hundreds of years
of accumulated experience with sysvinit, so sysvinit is the obvious
choice. Those who prefer to alt-init can do so easily, because unlike
systemd distros, the alternate init is a plug replacement, and you
don't need to tear out vast swathes of the former init system.


SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
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 am not using systemd and plan to avoid it

[James Powell]

Calculated up:

I use systemd and like it: 624 (36%)
 I use systemd and dislike it: 214 (12%)
 I am not using systemd and plan to use it: 87 (5%)
 I am not using systemd and plan to avoid it: 600 (35%)
 Other: 203 (12%)
That means roughly only 711 people like and want to use systemd.

That also means 814 people don't like it and don't want to use it.

That leaves 203 people who either use something else and/or don't care 
(probably Runit, s6, and such).

That means one thing... systemd is not liked and people have had it forced on 
them without merit by their distributions and things are about to get downright 
ugly as Hell.

This shouldn't just be good news, it should be a damn wake up call to 
distributions out there that the number of people who are not liking systemd... 
are growing.



From:
Alberto Zuin - liste

Sent:
‎7/‎15/‎2015 2:14 PM

To:
dng@lists.dyne.org

Subject:
Re: [DNG] I am not using systemd and plan to avoid it




Very interesiting data at this moment.







I use systemd and like it:

607 (37%)



I use systemd and dislike it:

208 (13%)



I am not using systemd and plan to use it:

82 (5%)



I am not using systemd and plan to avoid it:

560 (34%)



Other:

200 (12%)





So, now is 37% vs 34% (better than what I expected), but looking "at the 
future" there is a 37+5=42% of users that will have systemd vs 34+(potentially) 
12=46% of non systemd users.

Also a 12% of others that can potentially dislike systemd.

Of course, less than 2K votes are not enough to have consistent results, anyway 
I'm really impressed.

Alberto



On 15/07/15 19:51, Anto wrote:


I just cast my vote on 
http://distrowatch.com/weekly.php?issue=20150713#poll. 

___ 

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
___
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 am not using systemd and plan to avoid it

[James Powell]

Look at the number who use it and dislike it...

Sent from my Windows Phone

From: Alberto Zuin - liste
Sent: ‎7/‎15/‎2015 2:14 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] I am not using systemd and plan to avoid it

Very interesiting data at this moment.

I use systemd and like it:  607 (37%)
I use systemd and dislike it:   208 (13%)
I am not using systemd and plan to use it:  82 (5%)
I am not using systemd and plan to avoid it:560 (34%)
Other:  200 (12%)


So, now is 37% vs 34% (better than what I expected), but looking "at the
future" there is a 37+5=42% of users that will have systemd vs
34+(potentially) 12=46% of non systemd users.
Also a 12% of others that can potentially dislike systemd.
Of course, less than 2K votes are not enough to have consistent results,
anyway I'm really impressed.
Alberto

On 15/07/15 19:51, Anto wrote:
> I just cast my vote on
> http://distrowatch.com/weekly.php?issue=20150713#poll.
> ___
> 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd in wheezy, was: Re: bummer

[James Powell]

I don't care about the context of the formatting, as my mobile can receive any 
type of email and I never use a client on my computer other than a web browser, 
but I do care for the message itself and it's content.

But I'll revamp what my points were:

1. GNU is an operating system, and Linux is a kernel and small collection of 
kernel tools to use the kernel with the GNU OS. Linux is not GNU, and GNU is 
not Linux, or tied to any specific kernel.

2. We don't need svchost be replicated on GNU/Linux. We don't need a GNU/Linux 
OS with ridiculous system requirements.

3. Systemd requires udev to be viable, but udev and GNU/Linux do not need 
systemd to be viable. If we can effectively, and fully, replace udev and break 
the stranglehold it has had over systems for so long, systemd and kdbus become 
completely irrelevant. Udev is like a spine, and if it can be broken, the 
entirety of systemd will be broken as well. Vdev is not just the answer for 
Devuan but all systems that want to remain autonomous from the systemd 
dependency.

From: Steve Litt
Sent: ‎7/‎9/‎2015 10:40 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] systemd in wheezy, was: Re: bummer

On Thu, 9 Jul 2015 12:21:51 +0100
Arnt Gulbrandsen  wrote:

> kato...@freaknet.org writes:
> > And as a caveman, I would also very much appreciate a sensible
> > quoting, even if it seems that this little thing has become too
> > harsh to ask and too hard to obtain in the last few years...
>
> AOL. How about filtering away all mail whose subject already contains
> [DNG] but has no References field?
>
> Arnt

And, wait for it, wait for it, /dev/null any message whose subject
starts with "[DNG] Dng Digest, Vol 10". Seriously, there's a special
place in hell for those guys.

I also agree with The Caveman and would phrase it a little differently:
We're all in this to bestow and gain information. To the extent that our
communications are unambiguous, we will be efficient in bestowing and
gaining information.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
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] systemd in wheezy, was: Re: bummer

[James Powell]

I also do not think recreating SVCHOST is wise. I followed Windows since 2000 
and since then SVCHOST has pulled in more and more growing the system 
requirements exponentially from 266mhz and 32mb RAM to 1 GHz and 1 GB RAM. This 
should NOT be done in GNU/Linux.

Systemd is not the answer to GNU/Linux any more than BusyBox is, and by all 
technicality, systemd is just an unmatured BusyBox.

Given enough time, systemd will come and go once effort is done to replace the 
only thing keeping systemd relevant.

Even if faster init is one of them, uselessd, OpenRC, Runit, and others have 
proven this to be a moot point.

I don't know how things will end, but I can say this, once udev is broken by 
vdev, and it will be, things will change because of kdbus issues. However, if 
kdbus being moved into udev to replace netlink will kill eudev futures, vdev 
will be there without kdbus doing the same work.

Sent from my Windows Phone

From: T.J. Duchene<mailto:t.j.duch...@gmail.com>
Sent: ‎7/‎8/‎2015 11:06 AM
To: 'James Powell'<mailto:james4...@hotmail.com>; 
'dng'<mailto:dng@lists.dyne.org>
Subject: RE: [DNG] systemd in wheezy, was: Re:  bummer





From: James Powell [mailto:james4...@hotmail.com]
Sent: Wednesday, July 8, 2015 12:27 PM
To: T.J. Duchene
Subject: RE: [DNG] systemd in wheezy, was: Re: bummer



I think if Devuan can break the dependency, it can prove more than most people 
realize.



We will certainly see, and it would be nice.





The overreliance on systemd on any form has left things as they are. If vdev 
can effectively replace udev, rather than offer an alternative that doesn't do 
everything and is limited, then we break a huge chain holding down not just 
Devuan but all distributions.



If you don’t mind, I’d like to elucidate a bit further in what I see.


The management of many of the binary distributions has fallen to groups of 
people rather obsessed with driving Linux as a competitor to Windows.  This has 
long been an obsession of theirs, for decades in fact, and they see it as the 
end goal.  Things like systemd are stepping stones down that road because they 
are – whether consciously or not – feel the need to drive the design of Linux 
down the same path that Windows took all those years ago.  Systemd is in many 
ways, a clone of a part of Windows called SVCHOST.  Actually, systemd concerns 
me very little because in the grand scheme of things, it is really just a minor 
annoyance.  As many have said, there are plenty of alternatives to using 
systemd.



What does concern me is that this same attitude has developed a popular mindset 
named FLOS (Free Linux Operating System) rather than FOSS.  FOSS wants open 
standards or contributing to the UNIX community as a whole.  FLOS believes that 
Linux IS the community and that those wonderful things that gave Linux its 
success, such as POSIX, no longer matter.  Everyone should follow Linux’s lead, 
wherever that goes or be damned.   In essence, it is exactly the same attitude 
that Microsoft developed after they became the most popular, and now Linux has 
fallen prey to the same diseased thinking, which makes Linux less compatible 
with everyone else by the day.



I’d ask that you trust me on this.  I’ve seen it firsthand as a programmer for 
the last 25+ years.  I don’t think there are any quick antidotes either.  I 
think that Linux will either realize the error the majority are making or they 
won’t.  We all know what happened to Microsoft.  Usually, it takes getting 
burned before people realize they screwed up.




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

Re: [DNG] systemd in wheezy, was: Re: bummer

[James Powell]

True and all but there is only one problem with FLOS...

Linux is a kernel.
GNU is the operating system.

This is the problem people fail to see. Yes, the Linux kernel isn't just a 
kernel, it's tools used specifically between GNU and the kernel.

The problem with systemd is its trying to merge two systems that have never 
been merged for good reason. To keep GNU a clean room OS and keep the userland 
and kernelspaces separated.

Creating a complete OS is a nice idea, but GNU is not Linux, and Linux is not 
GNU.

Sent from my Windows Phone

From: T.J. Duchene<mailto:t.j.duch...@gmail.com>
Sent: ‎7/‎8/‎2015 11:06 AM
To: 'James Powell'<mailto:james4...@hotmail.com>; 
'dng'<mailto:dng@lists.dyne.org>
Subject: RE: [DNG] systemd in wheezy, was: Re:  bummer





From: James Powell [mailto:james4...@hotmail.com]
Sent: Wednesday, July 8, 2015 12:27 PM
To: T.J. Duchene
Subject: RE: [DNG] systemd in wheezy, was: Re: bummer



I think if Devuan can break the dependency, it can prove more than most people 
realize.



We will certainly see, and it would be nice.





The overreliance on systemd on any form has left things as they are. If vdev 
can effectively replace udev, rather than offer an alternative that doesn't do 
everything and is limited, then we break a huge chain holding down not just 
Devuan but all distributions.



If you don’t mind, I’d like to elucidate a bit further in what I see.


The management of many of the binary distributions has fallen to groups of 
people rather obsessed with driving Linux as a competitor to Windows.  This has 
long been an obsession of theirs, for decades in fact, and they see it as the 
end goal.  Things like systemd are stepping stones down that road because they 
are – whether consciously or not – feel the need to drive the design of Linux 
down the same path that Windows took all those years ago.  Systemd is in many 
ways, a clone of a part of Windows called SVCHOST.  Actually, systemd concerns 
me very little because in the grand scheme of things, it is really just a minor 
annoyance.  As many have said, there are plenty of alternatives to using 
systemd.



What does concern me is that this same attitude has developed a popular mindset 
named FLOS (Free Linux Operating System) rather than FOSS.  FOSS wants open 
standards or contributing to the UNIX community as a whole.  FLOS believes that 
Linux IS the community and that those wonderful things that gave Linux its 
success, such as POSIX, no longer matter.  Everyone should follow Linux’s lead, 
wherever that goes or be damned.   In essence, it is exactly the same attitude 
that Microsoft developed after they became the most popular, and now Linux has 
fallen prey to the same diseased thinking, which makes Linux less compatible 
with everyone else by the day.



I’d ask that you trust me on this.  I’ve seen it firsthand as a programmer for 
the last 25+ years.  I don’t think there are any quick antidotes either.  I 
think that Linux will either realize the error the majority are making or they 
won’t.  We all know what happened to Microsoft.  Usually, it takes getting 
burned before people realize they screwed up.




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

Re: [DNG] vdev status update: performance, bugfixes, and udev events

[James Powell]

Having this news brings us many steps closer to a full udev replacement.

One step closer to shattering the stranglehold of udev forever. I just wish I 
could be at the Linux Conference when vdev goes RTM and completely shatters the 
hopes and dreams of systemd. I'd be, or try to be, the first to give Jude a 
standing ovation, and if Lennart tries his usual interruptions, yell out, 
"Excuse me, Lennart, sir, but you do us one favor? Sit down and shut up! We 
came to hear Jude, not some poop throwing monkey!"

No offense to poop throwing monkeys.

-Jim

From: shraptor
Sent: ‎7/‎7/‎2015 10:41 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] vdev status update: performance, bugfixes, and udev events

On 2015-07-07 17:45, Jude Nelson wrote:
> Hey everyone,
>
> I have the latest news for vdev:
>
> * [EXPERIMENTAL] Vdevd now has actions and helpers that will cause it
> to generate and propagate device events to libudev-compat clients.
> Libudev-compat clients should receive hotplug events as they would
> have with libudev, and they should be able to enumerate devices.
> This means that it should be possible now to run X11 with vdevd and
> libudev-compat, without needing an xorg.conf.  To do so, you'll need
> to symlink vdev's /dev/metadata/udev to /run/udev.

CONFIRMED WORKING - a great milestone Jude, F***ing good work!

Both keyboard and mouse working without Xorg.conf  :-)

When inserting flash memory sticks they get autodetected and device
nodes created :-)

Question This is working without a value for
/proc/sys/kernel/hotplug so it is not used and
only for udev???


>
> * Hardware database access performance has been significantly
> improved, and made more accurate (i.e. it should now match all
> prefixes against the device modalias, not just the longest one).  By
> "significant", I mean by an order of magnitude.
>
> * As an optimization, vdevd can now run specially-crafted helper
> scripts as "daemonlets."  Instead of fork()/exec()'ing a shell for
> each action, vdevd will instead fork() an action's command once and
> feed it a sequence of device requests, encoded as a list of
> environment variables.  When running as a daemonlet, the command will
> be expected to run a loop that will parse the request from vdevd, call
> the command's main body of code, and report back the "exit" status.
> The heavyweight scripts (i.e. the ones that benefit from this) have
> all been turned into daemonlets in this round of commits.  This leads
> to around 25% performance improvement (on average) for each command.
>
> * vdevd now benchmarks its actions, and writes performance information
> to its logfile at the end of coldplug processing.  Just to give a
> reference frame:  vdevd currently takes about 9 seconds to
> cold-process all of my laptop's hardware (i.e. it's slower than udev,
> but not that much slower).
>
> * libvdev is no longer a build target.  Its code will instead be
> statically linked to vdevd and vdevfs. This is to make installation
> and deployment easier.  There's no real loss to doing so--the library
> isn't that big in the first place, and the only programs that will
> ever use it are vdevd and vdevfs (note that libvdev is not at all
> related to libudev).
>
> * Bugfixes:
> -- the pre-seed script that runs before coldplug device processing can
> now create device nodes, and signal to vdevd to run the associated
> helper scripts anyway.
> -- the pre-seed script will select the first free loop device (with
> losetup -f) for the hardware database.
> -- [NEEDS CONFIRMATION] the ifname.sh script should select the correct
> config file now.  I'm still chasing down a "Device or resource busy"
> bug in renaming interface names, so please keep your eye out for it.
> -- [NEEDS CONFIRMATION] the disk.sh helper should now generate
> /dev/disk for USB disks.
>
> Thanks to everyone who helped me test vdevd so far!
> -Jude
> ___
> 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd in wheezy, was: Re: bummer

[James Powell]

I'm still hoping some of our user friendly non-systemd distributions remain 
systemd-free.

My main concern is vdev. If Jude can miraculously break the seemingly 
indestructible spine of systemd, which is technically udev, the whole thing 
will collapse. Without udev, what hold does systemd even have over GNU/Linux? 
Kdbus becomes instantly irrelevant and systemd becomes completely an 
after-though.

Regards,
-Jim

From: Gregory Nowak
Sent: ‎7/‎6/‎2015 6:04 PM
To: dng@lists.dyne.org
Subject: [DNG] systemd in wheezy, was: Re:  bummer

On Mon, Jul 06, 2015 at 05:31:26PM -0400, Hendrik Boom wrote:
> I'm running wheezy on my server.
> The only package I have that contain 'systemd' in their names are:
>
> libystemd-login0
>
> I don't find it sneaking other systemd things onto my system when I do
> the usual security upgrades.  Maybe if I were to install gnome it might
> be different.
>
> I got rid of libsystemd0 (or whatever it is called) a while ago.
>
> I use sysvinit

Same here. I had libsystemd-login0 installed on all my wheezy boxes,
but was able to remove it from all machines except the one with
gnome. Removing that wanted to also remove dbus, and avahi-daemon,
which I didn't have a problem with.

On the other hand, the box with gnome installed has both
libsystem-daemon0, and libsystemd-login0 automatically
installed. Attempting to remove those would gut a large part of gnome,
so I left them alone. They must have been there for a good while,
perhaps from when I upgraded to wheezy. I keep track of what apt-get
dist-upgrade does on wheezy, and don't recall it suggesting to install
new packages with systemd in there names on wheezy at any time since
jessie became stable.

The fact that gnome on wheezy seems to require libsystemd-daemon0, and
libsystemd-login0 brings up an interesting question. What will happen
when I attempt to upgrade this system to devuan stable? My plan was to
do the upgrade, get rid of the desktop task post-upgrade, and install
xfce. Will that still work?

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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Testing - Please ignore and delete this email

[James Powell]

Me either, but I just got the notice also. What are bounces anyway? Dead email 
addresses?

Sent from my Windows Phone

From: Anto
Sent: ‎7/‎5/‎2015 1:50 PM
To: dng@lists.dyne.org
Subject: [DNG] Testing - Please ignore and delete this email

This is just a test message as my membership was disableddue to
excessive bounces. I am not sure why that happened.
___
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

[DNG] ZFS root help needed.

[James Powell]

Hey guys. I know this is out of the norm, and yes I know all about the CDDL, 
Btrfs, and other things, but I'm working with ZFS and need some help.

I'm try to get my root file system which is at mountpoint=legacy with zpool 
ztank/linux/root dataset able to boot with the kernel.

I have spl and zfs built into the kernel with spl and zfs 0.6.4.2 against 
linux-4.1.1, and I'm booting with syslinux.

I don't know what to set on the APPEND line for the kernel options to make my 
zfs zpool readable by the kernel to boot the system. I also am uncertain as to 
what to set my fstab as though currently is it set to the zpool dataset at / 
with file system type ZFS in rw mode.

Does anyone have any experience in this area to help me out?

Many thanks,
Jim

Sent from my Windows Phone___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Linus answers a question about systemd

[James Powell]

True, but at the same time one has to as, where is the kdbus daemon independent 
of systemd that can be used by non-systemd systems to accurately test how well 
it works? DBus currently has no such abilities to my knowledge.

Sent from my Windows Phone

From: KatolaZ
Sent: ‎7/‎1/‎2015 10:31 PM
To: Aldemir Akpinar
Cc: dng@lists.dyne.org
Subject: Re: [DNG] Linus answers a question about systemd

On Wed, Jul 01, 2015 at 09:21:46PM +0300, Aldemir Akpinar wrote:
> It's the second question:
>
> http://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question?utm_source=feedly1.0mainlinkanon&utm_medium=feed
>

I wouldn't expect any different answer from Linus. And who wants to
read anything like "hey, I would not allow kdbus in the kernel for all
the gold in the world" in that answer should well remember that Linus
has never shown any particular philosophical interest in Free Software
or Open Source, since he is basically "motivated by technology" (as he
says himself a few lines down, in another answer to another silly
question).

This means that if he will be sooner or later convinced that kdbus is
a good piece of technology to have in the kernel, for one reason or
another, he will merge it overnight, irrespective of the real or
perceived madness and stubborness of its maintainers.

I am afraid that kdbus/systemd people will lately grasp this simple
bit of knowledge about Linus, and go for the compromise to convince
him that kdbus is good and the people around it are not monsters. At
that point they will have succeeded. And they will.

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
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 answers a question about systemd

[James Powell]

Linus actually makes perfect sense on the question.

"Doing things better" doesn't always mean "doing things right" or "doing things 
correctly".

Systemd does things in a better way than traditional ways, but that doesn't 
necessarily make them the best options, the best choices, or the right ones. 
Just as systemd does init better, so does OpenRC, Runit, s6, etc. but systemd 
is the new kid on the block with all the cool toys. But, if you noticed, Linus 
doesn't fully embrace systemd or it's creators. To him, systemd as init is a 
means to an end, but read that line, "init". That doesn't mean he likes logind, 
networkd, and he certainly doesn't care for journald, and udevd is always an 
apparent child from a parent that needs constant supervision and a belt beating 
every now and then, and kdbus is about as tolerated as using a chainsaw to 
perform open heart surgery.

Sent from my Windows Phone

From: Laurent Bercot
Sent: ‎7/‎1/‎2015 1:01 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Linus answers a question about systemd

On 01/07/2015 21:17, Martin Steigerwald wrote:
> Linus describes personality issues around how to handle bug reports.
>
> And I think that is one of the main issues I have with some systemd upstream
> developers as well. The "we are right, you are wrong", "we wont fix this its
> not our bug", "we created a regression, but its still correct what we do, go
> away" kind of attitudes I have seen in bug reports and mailing list posts.

  Oh, yes, the systemd creators (Poettering and Sievers, essentially) have a
very inexperienced and irresponsible attitude when it comes to maintaining
software. The person to be blamed here is their manager at Red Hat, who
entrusts major software design, and a job, to those people.

--
  Laurent

___
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] We Must be Prepared ....

[James Powell]

Linus isn't stupid.

Sent from my Windows Phone

From: Jude Nelson
Sent: ‎6/‎23/‎2015 6:20 PM
To: KatolaZ
Cc: dng@lists.dyne.org
Subject: Re: [DNG] We Must be Prepared 

Looks like Linus weighed in.  I found the whole conversation thread
interesting.

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html

-Jude

On Sat, Jun 20, 2015 at 5:28 PM, KatolaZ  wrote:

> On Sat, Jun 20, 2015 at 08:15:01PM +0200, Didier Kryn wrote:
>
> [cut]
>
> >
> > I think a new generation of programmers has been comitted to
> > maintain and evolve
> > Linux. They have strong technical skills but haven't been taught
> > well enough - or not at
> > all - the philosohy of UNIX. They have fun with Linux; they love
> > writing daemons and
> > using the IPC toolbox and they happily write daemons to replace the
> > security features
> > provided by good old file-permissions. They just don't realize the
> > damage they are
> > causing. They are professionals and they don't care the DIY guy who
> > isn't as skilled as
> > them.
> >
>
> Or...we are just blind cavemen, trying do keep alive a zombie that
> lives only in our memories and has evolved into something else, while
> we were busy flaming about the last flavours of Ubuntu?
>
> I just think it's not a matter of skill (unix has never ever been just
> a matter of skill), but rather a problem of bad attitude towards other
> peers, their work and their contributions. And good attitude towards
> peers is what has allowed the community around Linux to come along in
> these years. Without good attitude, what was once a community will
> slowly -but inexorably- become just a chit-chatty crowd, in which
> speaking louder than your peers would be far more important than
> having anything interesting to say at all.
>
> Well, I'd better stop here, and avoid the usual boring "auntie's
> rant"...
>
> HND
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> ___
> 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] We Must be Prepared ....

[James Powell]

But kdbus hasn't proven itself in regular usage, except only by systemd. Where 
are the figures for kdbus with other D-Bus using software and services? I don't 
believe there are any, and if kdbus has been touted so much to be the perfect 
successor to D-Bus, why aren't other packages making headway to make their 
packages kdbus compliant to test the viability of kdbus?

The one benefit we could get out of this are distributions waking up and saying 
no to including non-mainstream kernel code, and berating Lennart for wanting or 
requiring non-vanilla code. Most distributions only have traditionally included 
patches to fix known kernel issues, but anything else has been classed as 
forbidden.

If anything Lennart may have put the metaphorical knife to the throat of 
systemd without realizing it.

Sent from my Windows Phone

From: Didier Kryn<mailto:k...@in2p3.fr>
Sent: ‎6/‎20/‎2015 2:49 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] We Must be Prepared 

Le 20/06/2015 11:06, James Powell a écrit :
> Then this without a doubt is clear evidence that kdbus is in fact a
> systemd proprietary IPC. Has anyone heard of any software otherwise
> that will use kdbus at all, even in the least?
>
> Lennart is desperate to get kdbus in, but is making a critical error
> in judgment with this. No distribution has ever added software to the
> kernel that has been 3rd party via patch, or has limited function,
> other than Gentoo that maintains a patch for OpenRC. ZFSOnLinux has
> never been allowed, neither has Reiser4, or any other non-vanilla
> code, nor any code from Linux-next.
>
> No package developer in their right mind would do such a lascivious
> addition to the kernel, nor would dare to.
>

 OK, kdbus is required eagerly by systemd developpers. So what?
Don't you think normal that such an important and critical thread of
software development finds that it misses some service that only the
kernel can provide efficiently? Isn't it normal that the kernel team
examines seriously the request and eventualy provides that service?

 This kdbus feature, if we don't want to use it, we don't use it. It
may even be optional and you can disable it when compiling the kernel if
the mere availability of this system-call irritates you. It may also
happen that other applications than systemd make use of kdbus for their
own needs.

 From a bad thing (systemd) could hapen good things. For example,
systemd-infected distros are now forced to include both sysvinit and
systemd init files if they pretend to continue sysvinit support. They
may consider some day doing what we are discussing in another thread:
providing init packages for every daemon. Or devising a generic
description of daemon dependencies and invocation method, which would
allow to use universal start/stop/reload scripts.

 Didier

___
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] We Must be Prepared ....

[James Powell]

Then this without a doubt is clear evidence that kdbus is in fact a systemd 
proprietary IPC. Has anyone heard of any software otherwise that will use kdbus 
at all, even in the least?

Lennart is desperate to get kdbus in, but is making a critical error in 
judgment with this. No distribution has ever added software to the kernel that 
has been 3rd party via patch, or has limited function, other than Gentoo that 
maintains a patch for OpenRC. ZFSOnLinux has never been allowed, neither has 
Reiser4, or any other non-vanilla code, nor any code from Linux-next.

No package developer in their right mind would do such a lascivious addition to 
the kernel, nor would dare to.

Sent from my Windows Phone

From: Arnt Gulbrandsen
Sent: ‎6/‎19/‎2015 10:23 AM
To: dng@lists.dyne.org; Clarke 
Sideroad
Subject: Re: [DNG] We Must be Prepared 

It does not make the kernel systems, but its presence might make some
poorly written program think systems is present. But poor code assumes
things all the time, so really it will not make a difference.

Arnt
___
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] We Must be Prepared ....

[James Powell]

Forking the kernel will be difficult, but honestly, it's the sane choice. I'm 
often reminded of the story of the pig who tried to eat everything. He popped 
and got turned into bacon after he ate too much.

Sent from my Windows Phone

From: Clarke Sideroad
Sent: ‎6/‎18/‎2015 9:43 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] We Must be Prepared 

I hoping the Kernel Developers as a combined whole would see the bigger
Linux picture well beyond the desktop.
I can't see the Kernel being made to swallow something that would poison
the whole multifaceted structure in the way that the various distros
swallowed the, "just another init, what's all the fuss about?", ever
expanding systemd.

The other day I was watching Monty Python's Mr. Creosote sketch from The
Meaning of Life movie and I came to realization that at some point the
same fate will surely befall the systemd conglomeration. It is rapidly
becoming the only thing an average Linux distro needs other than a
desktop and the kernel and continues to swallow up tempting morsels left
and right. I await the day that somebody gives the project a thin mint.

In the meantime there still exists the parallel no-systemd universe, if
it all goes to hell in a hand basket and it comes down to forking the
Kernel, I think that would be the time to go to another restaurant entirely.

Clarke




___
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] We Must be Prepared ....

[James Powell]

The problem is, kdbus isn't just an IPC, it's proprietary to systemd, and is 
the only software capable of utilizing it.

Greg Hartman as the lead-takeover for Linus? Hell no. He'd give it to Lennart 
and Kay without batting an eye, and then shut out every developer save their 
own.

Dare I say it, but Peter Griffin or Homer Simpson would be better choices...

If Hartman takes over, the kernel will have to be forked. His track record of 
kissing Lennart's ass is too obvious. No no and no.

Sent from my Windows Phone

From: Jude Nelson
Sent: ‎6/‎18/‎2015 9:20 AM
To: Richard
Cc: dng@lists.dyne.org
Subject: Re: [DNG] We Must be Prepared 

I'm not worried.  Linus won't accept kdbus until he thinks it's in a
position where it will be stable and easily supported for the foreseeable
future.  Watching kdbus get refactored a few times over this past year, I'd
wager a guess that they're going to end up keeping as much of dbus in
userspace as possible, and only add the parts that absolutely must run in
kernel space to the kernel (as kdbus).  Thus far, this has been limited to
the memfd API, which is needed for zero-copy memory transfers.  They'll
probably also end up adding a specialized kdbusfs (akin to devpts) that
offers namespaced and permissioned access to dbus endpoints, represented as
a hierarchy of character device files.

Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus.  The
reason they're working on kdbus at all is because they have discovered that
it's costly to pipe a lot of data between dbus endpoints, and it's hard to
control capabilities, visibility, and access to them (since there are
usecases where endpoints may not trust each other).  Arguably, these
problems can be addressed by using a combination of existing IPC
mechanisms, but the argument that Greg KH and company put forth over and
over again is that there's too much legacy code using dbus at this point
(namely, from the IVI community and desktop communities) that we can't just
tell them to refactor everything.  It might be true--I don't know how big
the IVI codebases are, for example.  However, I don't really sympathize
with the desktop communities--they built dbus to their specifications from
their experiences with DCOP and Bonobo, and still managed to get it wrong.

My $0.02.
-Jude
___
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] Hal and Vdev

[James Powell]

DRM is provided by libhal.so. Many people have used a special Hal package 
called halflash over a Slackware. It works with 
Freshplayerplugin(libpepflashplayer) and FlashPlayer-Plugin.

Sent from my Windows Phone

From: Jude Nelson
Sent: ‎6/‎14/‎2015 10:16 PM
To: JeremyBekka C
Cc: dng@lists.dyne.org
Subject: Re: [Dng] Hal and Vdev

Hi Jeremy,

I have a question about the deprecated program hal. We like to stream
> videos from Amazon.com but we need hal installed in order to make it work.
> The Hal Debian wiki says that it is being deprecated and it is being
> replaced by udev (https://wiki.debian.org/hal). Since vdev is being
> written to replace udev, are there any plans to incorperate hal's functions
> into vdev or keep maintaining it seperaratly?
>

Do you know what specific functions of hal you need?  Hal's functionality
got split between udisks/udisks2, upower, and udev some time ago.  Things
like device plug state, device properties, and device capabilities are now
tracked by udev (in /run/udev) and accessed by libudev, for example.  My
goal for vdev is to be compatible with udev, so if you can use udev today,
you should be able to use vdev when it's ready.

Thanks,
Jude
___
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] Puppy Linux, Devuan Puppy & hardware - Re: straw poll, non-free firmware for installers

[James Powell]

>From my limited knowledge on licensing agreements, I think as long as there 
>are no restrictions on redistribution from the original people who provide the 
>firmware, it can be freely redistributed as long as the firmware isn't 
>decompiled or disassembled.

I don't know, off hand, of any manufacturers that have any firmware limitations 
in licenses other than disassembly and decompiling.

Sent from my Windows Phone

From: Apollia
Sent: ‎6/‎5/‎2015 4:07 PM
To: dng@lists.dyne.org
Subject: [Dng] Puppy Linux, Devuan Puppy & hardware - Re:  straw poll, non-free 
firmware for installers

I already posted a little about Puppy Linux in the past - but, it seems
appropriate and particularly on topic to mention it again now, because, at
least from my not-very-technical perspective, one of Puppy Linux's
strengths appears to be compatibility with a wide variety of hardware,
usually without requiring the users to fiddle with settings much or at all.

With Puppy, the most elaborate thing I ever had to do to make some hardware
work was compile and install a driver for a USB wireless internet adapter.

(Oh, and then there were the things I was only able to figure out how to
use with a Windows XP VirtualBox rather than natively in Linux - a scanner
and an HPNA internet adapter.)


Puppy (at least the Puppies I tried) unfortunately doesn't tell you if it's
using anything non-free, nor give you the option to exclude those non-free
things.

But, other than that, it has usually been close to ideal for me.  I haven't
tried it with an incredibly wide variety of hardware, but it has usually
worked fine with most things I tried, even some rather surprising things,
like old Macs. :-)

Maybe Puppy has some hardware-related scripts or something which Devuan
could use or modify?


I don't know many details, but there is apparently already Devuan support
in woof-CE, the community edition of the software used to build Puppy
Linuxes.

This page is from last April:

https://github.com/puppylinux-woof-CE/woof-CE/pull/528

I don't know if anyone has yet released a Devuan-based Puppy ISO.  But, if
I understand correctly, woof-CE is the software anyone can now use to build
such an ISO.

Maybe stuff from that could be used in Devuan itself?


As for how Puppy deals with legal issues related to distributing non-free
firmware - I haven't been able to find many details so far just from
searching the web.

But, on the blog of Barry Kauler (creator of Puppy Linux), there's a post
from May 17, 2008 where he writes:

http://bkhome.org/blog/?viewDetailed=00099

"Anyway, I now have compiled 'slusb.ko' but apparently I can't legally put
it into Puppy for distribution. I have mumbled some appropriate expletives,
won't type them here."

So, judging by that, I assume Puppy probably is mindful of such issues and
probably follows the law, yet still manages to do a good job of being
compatible with a wide variety of hardware.


One of my top suggestions for a specific, existing Puppy distro to look at
and maybe use stuff from would be Wary Puppy, since it's specifically
designed to be compatible with old hardware.

http://distro.ibiblio.org/quirky/wary-5.5/release-Wary-5.5.htm

Wary is the Puppy that worked best for me on an old computer that even some
somewhat recent Puppies didn't work quite right on - a Toughbook CF-28
whose screen blacked out after X started while running Lucid Puppy 5.2.8
and Slacko 5.7.

If I recall correctly, the worst problem I had with the CF-28 and Wary was
that the CF-28's touchscreen wasn't properly calibrated out of the box (and
I never figured out how to calibrate it).


My other top suggestion would be Lighthouse 64 Puppy 6.02 Beta 2, my
favorite of all the 64-bit Puppies I've tried.

http://www.lhpup.org/ - Lighthouse 64 Puppy's home page


I was astonished when I was able to get Puppy to work on some old Macs,
with very little trouble at all (if I recall correctly) - just by booting
from a CD or DVD.

I actually was able to use Lighthouse 64 Puppy 6.02 Beta 2 on a 2008 Mac
Pro desktop!

A model of Mac that some describe as being like a giant cheese grater. :-)

http://www.souledesigns.com/blog/2013/06/mac-pro-kitchen-nightmare


And I got both Lucid Puppy 5.2.8 and I think also a Lighthouse Puppy
(forgot what version) to boot on a MacBook from 2009.

http://www.murga-linux.com/puppy/viewtopic.php?t=70855
Official discussion thread for Lucid Puppy 5.2.8


Another nice thing about Lighthouse 64 Puppy 6.02 Beta 2 is that right out
of the box, it somehow manages to perfectly calibrate the touchscreen of my
Toughbook CF-C1 (a newer and far less rugged Toughbook than the CF-28).

No other Puppy I tried did that, though at least the touchscreen somewhat
worked, even though I couldn't figure out how to calibrate it.  (Actually,
I might only have tried one other Puppy with the CF-C1 - Lucid Puppy 5.2.8.)


Anyway, I hope this helps.  I guess I'l

Re: [Dng] straw poll, non-free firmware for installers

[James Powell]

I think this might be the best option...

Have firmware only for networking devices and scsi/sata/ide controllers on the 
net installation disk. At least let the system support vectors be 100% or as 
close to 100% compatible as possible. If it is needed post-install the have it 
offered.

Why? Devuan needs to be far reaching to as many systems as possible.

Why? Nobody wants to download a distribution only to find their hardware isn't 
supported... PERIOD!

Devuan must reach the masses. Period. Devuan must show it not only is a 
friendly system, but is a system that is able to support it's community.

This isn't about free versus non-free. Those days are long past gone. The less 
a distribution supports, the more it falls away into a niche. Niche 
distributions do not go places or make bold statements. Devuan must be able to 
stand against Debian toe to toe, as well as Arch, Slackware, Gentoo, Ubuntu, 
Fedora, etc.

Firmware that makes a system usable is and should always be welcomed. The more 
you limit, the less users you have.

What the user does to their system after installation shouldn't be a concern. 
What should be a concern, how many users can we win over.

If this was a true war, would you fight to win one battle, or fight to win a 
whole war even if it cost a battle or two?

Just food for thought.

Sent from my Windows Phone

From: Didier Kryn
Sent: ‎6/‎5/‎2015 1:55 AM
To: dng@lists.dyne.org
Subject: Re: [Dng] straw poll, non-free firmware for installers


Le 05/06/2015 07:50, Isaac Dunham a écrit :
>
>> > From a legal point of view, I would also carefully refrain from
>> >redistributing any non-free firmware in Devuan, the main reason being
>> >that usually you*don't*  have the right to redistribute it, and even
>> >if you have got this right from the HW constructor, such right can be
>> >withdrawn any moment at their own will, which might be a quite
>> >unpleasent surprise for Devuan...
> There is a*very*  large set of non-free firmware for which at least your
> first claim is false, and for much of it the second is false as well.
> I've actually read several of the licenses in firmware-linux-nonfree.
>
> b43 is/was a notable exception, getting it the "b43-fwcutter" package...
> which leads me to mention something else:
> The criteria for something getting into debian non-free require your
> claims to be false for that package, if it isn't a downloader or
> installer.
 I think one could always make the following argument: I have paid
for a device which cannot work without the firmware; therefore what I
paid for is a set which includes hardware and firmware. Sorry but when I
buy a car, it is a package which includes the key; otherwise I wouldn't
buy it.

 Didier


___
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] Need some advice to compile consolekit2 for amd64

[James Powell]

Polkit, Eudev, and dbus should be okay to install.

Sent from my Windows Phone

From: Edward Bartolo
Sent: ‎6/‎4/‎2015 11:49 PM
To: dng
Subject: [Dng] Need some advice to compile consolekit2 for amd64

I am trying to compile ConsoleKit2 source for amd64 but I am getting this error:

dpkg-checkbuilddeps: Unmet build dependencies: libdbus-glib-1-dev (>=
0.30) libudev-dev libx11-dev (>= 1.0.0) xmlto libpolkit-gobject-1-dev
(>= 0.92)

Is it safe to install these files on a Devuan system? I want to avoid
all parts of systemd if possible.

If source modification is still necessary to port consolekit2 to
Devuan not to use any of systemd parts, please inform me.

Thanks.
___
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] straw poll, non-free firmware for installers

[James Powell]

I agree that there should be a scan ran to inform the system user that binary 
firmware is needed at boot, but likewise, if the system needs it, it should be 
an offered option at installation time also, just not offered by default as 
enabled. The user must at least select the option to install firmware such as 
this for example:

--

[  ] Install optional kernel binary firmware - Kernel firmware is used by some 
modern devices to supplement EEPROMs and other 
mask roms normally included either with the driver internally, or on the
 device itself.

Package (optional) : linux-kernel-firmware-nonfree--noarch-.deb

Notes:

Selecting this option will not install any traditional non-free software 
packages (I.E. Adobe Flashplayer) on your system. This package is meant to only 
supplement the Linux kernel and it's drivers. Nothing else. Due to the fact 
certain kernel drivers lack this firmware internally and on chip, this package 
may be needed to gain full functionality of hardware such as VGA, Audio, SCSI, 
Networking, and other devices.

If you were presented with a warning at boot that firmware needed to be loaded 
for your device(s), select and install this package, otherwise it is safe to 
continue without it.

--

Just a passing thought. As shown, the option is disabled by default, has 
documentational notes, and is counted as an optional kernel package, not actual 
software.

Good idea? Bad idea? Needs work? The cat ate the mouse? The dish ran away with 
the spoon?

-Jim

Date: Wed, 3 Jun 2015 21:52:20 -0400
From: jud...@gmail.com
To: dan...@centurion.net.nz
CC: dng@lists.dyne.org
Subject: Re: [Dng] straw poll, non-free firmware for installers



On Wed, Jun 3, 2015 at 9:29 PM, Daniel Reurich  wrote:
Ok,



That was interesting



Here's my thinking on the how and the why.



definition of terms:

user = the person using the installer to install Devuan.

module = linux kernel module.

hardware = reference to the particular chipset(s) in scope, be they SoC or plug 
in cards or devices.

firmware = non-free binary blob that is required to be loaded by the standard 
kernel module for the hardware in scope in order for the hardware to operate.

essential: required for proper operation.





How:





I will build a (udeb) package called firmware-reqd that:



1) Will provide an early detection of a select list of common essential 
hardware that:

  a) requires a non-free firmware blob

  b) is essential to make the system use-able enough to complete the 
installation to a bootable state.



2) Upon detection of said hardware, I will provide a prompt informing the user 
about the specific piece(s) of hardware detected that require non-free firmware 
to and give them the option to load that firmware and continue the installation 
or abort it at that point.



3) Only firmware meeting the above criteria will be included in the iso, but 
not used or loaded unless the operator specifically chooses to do so.



4) The choice to use non-free firmware will naturally lead to the question 
about whether the related firmware deb packages should be installed during the 
install.  I could provide an option here, defaulting to yes but allowing 
deselection for those who may want to leverage the non-free firmware only 
during install but not on the running system.



Note: When non-free firmware udebs are installed by debconf my understanding is 
that each of them will present the user a license upon which is also required 
to be accepted before that udeb is installed.







Why this approach:



I agree in principle about using strictly free/libre open source software, and 
where I have the choice I personaly will select hardware that aligns with those 
principles.



However, I would not want my choices to become the tool that would punish those 
less informed, or unable to make the sacrifices required to comply entirely 
with that principle. To do so would be ungracious and unrealistic, and boils 
down to elitism and puritanism.



Nevertheless, to silently let the installation of non-free firmware be done 
without recognition and challenge is not right either.  So I see the most 
gracious approach is to inform the users and grant them the opportunity to 
choose how they would like to proceed.  It gives opportunity for those who for 
conscience sake would refuse non-free firmware to do so, whilst not enforcing 
that choice an all users.



I think that this is a reasonable approach, and once the above proposed package 
is ready, it is my intention to have it included in the official installer 
images we ship.  Anyone that strongly objects can re-build their own installers 
without the non-free firmware packages added.

Re: [Dng] straw poll, non-free firmware for installers

[James Powell]

Firmware is part of the kernel in a sense because it is loaded by the kernel at 
boot. It only interacts with the kernel and the kernel modules to provide any 
missing functionality, like a header file does, except rather than C code, it's 
prebuilt binary language code.

It is not technically software because it doesn't act through an API, shell 
interpreter, user interface, or execution medium.

Big difference.

Sent from my Windows Phone

From: Adam Borowski
Sent: ‎6/‎3/‎2015 5:52 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] straw poll, non-free firmware for installers

On Wed, Jun 03, 2015 at 06:18:37PM -0500, John Morris wrote:
> Non-free software: NO, Firmware: YES.  So ixnay on things like the Nvidia
> drivers but yes on blobs.  The reasoning on where to draw the line is
> pretty clear cut.

How exactly firmware is not software?  Both are strings of bits encoding
commands for a processor living in silicon you own.

Your reasoning doesn't make a shred of sense to me.  Either we disallow all
kinds of non-free software, or allow all kinds; letting one in but another
out just because their code executes on different processors would be a
strange distinction.

--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
___
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] straw poll, non-free firmware for installers

[James Powell]

Firmware and software plugins are individual issues unto themselves.

Firmware that is needed to properly support hardware is in a class by itself, 
and the issue at hand.

As far as binary drivers. No. Even then, another separate issue.

This is solely on the kernel loadable firmware only. Nothing else.

Sent from my Windows Phone

From: KatolaZ<mailto:kato...@freaknet.org>
Sent: ‎6/‎3/‎2015 6:43 AM
To: James Powell<mailto:james4...@hotmail.com>
Cc: KatolaZ<mailto:kato...@freaknet.org>; Daniel 
Reurich<mailto:dan...@centurion.net.nz>; 
dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] straw poll, non-free firmware for installers

On Wed, Jun 03, 2015 at 05:24:30AM -0700, James Powell wrote:

[cut]

>
> Should it be default added, no, but offered for choice? Absolutely.
>

But how far this should/will go? After having offered the possibility
of bringing in non-free firmware during the installation, shall devuan
also offer to install non-free drivers for your video card?  And what
about flash plugins then, or Skype? The "end user" might want to
choose them, so should we offer her/him to install them?

This was indeed the Ubuntu-way of dealing with non-free software, and
I personally don't like it at all. I would rather prefer having a
clear, neat and discernable separation between what is free software
and what is not, as in Debian, and to have by default only free
software available, with non-free stuff in a separate repo which
requires separate and explicit setup to work.

My2Cents

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] straw poll, non-free firmware for installers

[James Powell]

While keeping to the libre creed is nice, at least having the option for 
firmware will help compatibility with hardware that requires it. Sadly, this is 
becoming more commonplace as newer hardware is released. More and more modern 
hardware requires firmware.

The question isn't about including it, but better reworded... "Should Devuan 
have an option for installing non-free firmware to support hardware that 
requires it, at the initial installation to promote more system hardware 
compatibility?"

I think it should offer the option, because at least it can show people 
installing Devuan that Devuan aims to support your hardware out of the box of 
sorts.

Should it be default added, no, but offered for choice? Absolutely.

Sent from my Windows Phone

From: KatolaZ
Sent: ‎6/‎3/‎2015 4:46 AM
To: Daniel Reurich
Cc: dng@lists.dyne.org
Subject: Re: [Dng] straw poll, non-free firmware for installers

On Wed, Jun 03, 2015 at 08:37:22PM +1200, Daniel Reurich wrote:
> Hi,
>
> I'd like a straw poll on whether we should include non-free firmware
> in our installers by default.
>
> It's a deviation from Debians traditional position, but a pragmatic
> one that shows we care about the end users.
>

My two cents on this point: I would really prefer *not* having any
non-free software/firmware in the default Devuan install.

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
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] straw poll, non-free firmware for installers

[James Powell]

If the firmware aids in compatibility and driver support then yes, include it.

Sent from my Windows Phone

From: Arnt Gulbrandsen
Sent: ‎6/‎3/‎2015 1:50 AM
To: dng@lists.dyne.org; Daniel 
Reurich
Subject: Re: [Dng] straw poll, non-free firmware for installers

Yes. And  explicitly say that the decision may be reverted later, if
that fight seems winnable.

It's best to pick one's fights.

Arnt
___
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] automounting in a window manager

[James Powell]

Okay, then that's probably a yes???

Anyways, if udevil works similar to udisks/udisks2 for automounting, I wonder 
if we could devise a script or small utility to wrap udisks/udisks2 calls to 
udevil without needing udisks directly? If so, this script/utility could be 
useful not only for Linux but BSD also. This could be useful to vdev as well 
equally.

Thoughts?

Sent from my Windows Phone

From: Robert Storey<mailto:robert.sto...@gmail.com>
Sent: ‎6/‎2/‎2015 6:28 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] automounting in a window manager

James Powell wrote:
> Doesn't udevil have a port on BSD? Off kilter question but
>if the answer is yes, then I can expand the idea I have.

A Google search turned up this:

http://ftp4.se.freebsd.org/pub/ubuntu/pool/universe/u/udevil/

Not sure if that is what you're looking for. Hope it helps.

cheers,
Robert
___
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] automounting in a window manager

[James Powell]

Doesn't udevil have a port on BSD? Off kilter question but if the answer is 
yes, then I can expand the idea I have.

Sent from my Windows Phone

From: Rob Owens
Sent: ‎6/‎1/‎2015 10:30 AM
To: shraptor
Cc: dng@lists.dyne.org
Subject: Re: [Dng] automounting in a window manager

- Original Message -
> From: "shraptor" 
> On 2015-06-01 16:22, Rob Owens wrote:
> > - Original Message -
> >> From: "Robert Storey" 
> >>
> >> First, thanks to all who replied.
> >>
> >> To me, the ideal solution would be if this was a user-configurable
> >> option.
> >> Would be great if you could, for example, just stick something into
> >> .bashrc
> >> for any user to allow automounting of USB devices, no matter which DE
> >> or
> >> window manager was being used. But I know it doesn't work that way.
> >> Just
> >> saying, it would make sense.
> >>
> >> pmount - yes, thanks for reminding me. I've used it eons ago. But all
> >> it does
> >> is allow one to mount a device without needing sudo. Still not really
> >> automounting.
> >>
> >> No one mentioned udevil. I just found it. Also not the same as
> >> automounting,
> >> but check out the interesting git home page:
> >>
> >> https://ignorantguru.github.io/udevil/
> >>
> > That guy also wrote spacefm.  It's a file manager which allows you to
> > either
> > manually or automatically mount USB devices.  It can be configured to
> > use
> > udevil, pmount, udisks1, or udisks2 to perform that function.
> >
> > Spacefm is currently unsupported by the developer.
> >
>
>
> checking github
> https://github.com/IgnorantGuru/spacefm/commits/next
>
> it seems spacefm is very much alive
>

Awesome!  Thanks for the update.  Last I had read, ignorantguru was on
haitus (announced April 28, 2014).  But it looks like as of this February,
he's back.

https://igurublog.wordpress.com/
___
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] New systemd release notes regarding udev.

[James Powell]

One concern I have is how GNOME will manage gudev. One thing I don't want to 
think about is them creating some dependency upon systemd in some way 
preventing portability to extracted udev or something that is udev compatible 
like vdev requiring gudev to be either heavily patched or redeveloped, such as 
a gvdev project.

It's mind numbing to consider all this, but the rate they are trying to tighten 
their grip, at least we do know the more alternatives seem to supplicant things 
enough to keep pro-choice distributions slipping through their fingers.

-Jim

From: Jude Nelson<mailto:jud...@gmail.com>
Sent: ‎6/‎1/‎2015 6:58 PM
To: James Powell<mailto:james4...@hotmail.com>
Cc: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] New systemd release notes regarding udev.

Hi Jim,


> It seems udev is getting split up between several projects within systemd
> and GNOME. It seems gudev is being handed off in the future to GNOME and
> parts of udev are being pushed deeper into systemd.
>
>
gudev splitting off isn't a problem; in fact, I applaud the decision.


> I'm not surprised at this, since kdbus didn't get pushed into the kernel
> mainline, but it does show evidence of the callousness being presented to
> the Linux ecosystem. If they don't get their way one way, they try to get
> their way another.
>
> I am wondering how much longer eudev can remain tied to systemd-udev,
> unless it becomes completely independent. We still are waiting on the
> progress of vdev, patiently. So until then, it seems to be wait and see yet
> again.
>

vdev will ship with libudev-compat, which is ABI-compatible with the public
API of libudev 219.  I'm afraid I couldn't manage ABI compatibility with
the private API, but AFAIK only udev and systemd were its clients anyway.
Also, vanilla libudev 219 doesn't overlap that much with systemd, so we can
easily build our own and ship that in place of libudev 220+ in the
near-term.

libudev-compat is still a work in progress, but it's my last major blocker,
and I hope to have something testable by early next week.  The key
challenge has been in removing the need for the udev-controlled netlink
multicast group to deliver events while continuing to provide the same
semantics at comparable performance.  While my approach almost certainly
won't be as fast as netlink-based libudev, it should:
* be fast enough for our purposes (will provide actual performance data
when I have them);
* be easier to troubleshoot (i.e. the admin can read, inject, reorder,
copy, and remove device events without having to instrument the device
manager, the kernel, or the libudev client);
* be agnostic to which device manager (if any) is running;
* let the admin control which root-context events get propagated to
containerized libudev clients (something udev and libudev *cannot* do, due
to their reliance on netlink).

You don't have to wait up for me, though--Devuan's udev and eudev are ready
to use now :)  Developing vdev and libudev-compat is one of several
contingency plans for the scenario where udev and libudev become
intractably dependent on systemd.

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

[Dng] New systemd release notes regarding udev.

[James Powell]

https://github.com/systemd/systemd/blob/master/NEWS

It seems udev is getting split up between several projects within systemd and 
GNOME. It seems gudev is being handed off in the future to GNOME and parts of 
udev are being pushed deeper into systemd.

I'm not surprised at this, since kdbus didn't get pushed into the kernel 
mainline, but it does show evidence of the callousness being presented to the 
Linux ecosystem. If they don't get their way one way, they try to get their way 
another.

I am wondering how much longer eudev can remain tied to systemd-udev, unless it 
becomes completely independent. We still are waiting on the progress of vdev, 
patiently. So until then, it seems to be wait and see yet again.

Thoughts?

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

Re: [Dng] Lennart reacts to the release of Devuan

[James Powell]

Though I do have to admit, someone should edit in that Jude Nelson was 
developing vdev and Slackware was still against the adoption and just recently 
got a full import of OpenRC on the SBo for further hilarity.

All in good fun guys.

-Jim

From: james4...@hotmail.com
To: phi...@posteo.de; dng@lists.dyne.org
Date: Mon, 1 Jun 2015 03:35:53 +
Subject: Re: [Dng] Lennart reacts to the release of Devuan




OMG!!! LMAO @ video. Spot on, spot on. Of course this was one of many parodies 
of that scene, but still it's hilarious.

To whoever edited that *standing ovation*

-Jim

> Date: Sun, 31 May 2015 21:47:48 +0200
> From: phi...@posteo.de
> To: dng@lists.dyne.org
> Subject: Re: [Dng] Lennart reacts to the release of Devuan
> 
> Now Mr Poettering will have another pretext (if not a reason) for 
> whining and complaining that everybody "hates" him. This might also make 
> him feel way more important than he actually is (Ok, it seems that he 
> already does). That said, I admit that the video made me ROFL. 
> Inappropriate? Perhaps, given previous situations. I suggest that this 
> thread is left to its quick and peaceful death.
> 
> Btw. Bruno Ganz was great in that movie.
> 
> Just my few thoughts.
> 
> Best,
> Philip
> 
> 
> Am 31.05.2015 06:21 schrieb Init Freedom:
> > https://www.youtube.com/watch?v=_cdEFF-ttLw
> > 
> > May the source be with you, gents.
> > 
> > ___
> > 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
  

___
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] Lennart reacts to the release of Devuan

[James Powell]

OMG!!! LMAO @ video. Spot on, spot on. Of course this was one of many parodies 
of that scene, but still it's hilarious.

To whoever edited that *standing ovation*

-Jim

> Date: Sun, 31 May 2015 21:47:48 +0200
> From: phi...@posteo.de
> To: dng@lists.dyne.org
> Subject: Re: [Dng] Lennart reacts to the release of Devuan
> 
> Now Mr Poettering will have another pretext (if not a reason) for 
> whining and complaining that everybody "hates" him. This might also make 
> him feel way more important than he actually is (Ok, it seems that he 
> already does). That said, I admit that the video made me ROFL. 
> Inappropriate? Perhaps, given previous situations. I suggest that this 
> thread is left to its quick and peaceful death.
> 
> Btw. Bruno Ganz was great in that movie.
> 
> Just my few thoughts.
> 
> Best,
> Philip
> 
> 
> Am 31.05.2015 06:21 schrieb Init Freedom:
> > https://www.youtube.com/watch?v=_cdEFF-ttLw
> > 
> > May the source be with you, gents.
> > 
> > ___
> > 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
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] automounting in a window manager

[James Powell]

Automounting is strictly done via udisks and udisks2 which work with udev 
(udev-classic, eudev, or systemd-udev) with modern DEs. There are scripts than 
can automount devices using the classic method that can be inserted into the 
startup routine of a WM though, or you can assign them to be mounted at boot 
with fstab.

-Jim

Date: Sun, 31 May 2015 07:57:47 +0800
From: robert.sto...@gmail.com
To: dng@lists.dyne.org
Subject: [Dng] automounting in a window manager

With all the recent discussion about DEs (Cinnamon, Gnome, Mate, etc), I just 
thought I'd throw this in here...

For the longest time, I simply used a window manager. In the beginning, it was 
FVWM, but later I took a liking to IceWM. As opposed to a full-blown Desktop 
Environment, I liked the speed and simplicity of a window manager.

The only drawback is that window manager doesn't seem to do automounting of 
plugged-in devices. I went looking for a solution, and found this page:

https://awesome.naquadah.org/wiki/Automounting

It says, among other things, that udev can be configured to handle 
automounting. That's nice, but since systemd has polluted udev beyond repair, 
I'm wondering if Devuan can be set up to handle it better, perhaps with vdev. 
Or is there a better way?

I believe that people who are opposed to systemd are similar to me - we prefer 
simplicity over complex solutions, and are not impressed by bells and whistles. 
Thus, I think people who are attracted to Devuan would be a good market for a 
simple desktop based on IceWM.

Just something to think about.

Hope you are all having a nice weekend.

 - Robert



___
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] Everyone's favorite DE: GNOME3

[James Powell]

I wonder if gnome-logs could be patched to work with loginkit and 
rsyslog/syslog-ng/sysklogd rather than just systemd-journald? If it's just a 
log parser/viewer, it must be possible.

Sent from my Windows Phone

From: Jaret Cantu
Sent: ‎5/‎25/‎2015 9:13 AM
To: dng@lists.dyne.org
Subject: Re: [Dng] Everyone's favorite DE: GNOME3

On 05/25/2015 11:47 AM, Renaud (Ron) OLGIATI wrote:
> On Mon, 25 May 2015 11:31:36 -0400
> Jaret Cantu  wrote:
>
>> I am happy to report that (most of) the GNOME3 Desktop Environment has
>> been made to work systemd-free, in all its spiffy, OpenGL-y goodness!
> Which would tend to show that the Gnome devloppers had no good reason to 
> infect their product with systemd dependencies...
>
> Cheers,
>
> Ron.
Hey, it works on BSD.

The more I deal with packages that "require" systemd, it is rapidly
apparent that the package can simply be configured with systemd support
for _reasons?_ It is a (pre-)build-time configuration, and distros are
just going thataway instead of the "Oh yeah, other init systems exist" way.

In fact, no gnome package I dealt with had a hard systemd requirement
except one: gnome-logs.  That is a gnome systemd binary log viewer. So,
yeah, that one required systemd (journald?).

mutter had a weird dependency that Debian patched in, so I had to patch
it out, but even it worked fine before I did that.

Everything else was just Debian making the systemd requirement -- not
gnome.  For the most part, I'm just changing the configuration to be the
same as the non-Linux configuration (BSD/Hurd), which is already and
inherently systemd-free.

(Granted, I didn't check the patchlists to see if the systemd-freedom
was actually provided by the Debian maintainers in order to get kfreebsd
to work.)


~jaret
___
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] Slackware systemd creepin in maybe?

[James Powell]

Remember Lennart's remarks about BSD?

"BSD isn't relevant anymore. It's a toy OS."

Sent from my Windows Phone

From: Hendrik Boom
Sent: ‎5/‎23/‎2015 7:02 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] Slackware systemd creepin in maybe?

On Sat, May 23, 2015 at 06:09:11PM -0400, Jaret Cantu wrote:
> On 05/23/2015 05:54 PM, Nuno Magalhães wrote:
> >There's a UNIX ecosystem? The Linux ecosystem may become strictly
> >commercial and be used to hunt baby seals, but the BSD and Solaris
> >ecosystems are still systemd-free, are they not?
>
> That is one of the arguments against systemd and its seepage (a more
> appropriate word than creeping!); systemd is geared entirely to the
> Linux kernel with its hard requirements for features like cgroups.
> (Also, specifically geared towards Linux DE.)
> Thus, systemd cannot even be used on non-Linux systems (or, if it
> can, only in a stripped down, impotent form).

So is systemd also a weapon against Unix systems? So that as software
gets infected it becomes unavaioable to Unix users?

-- hendrik
___
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] Slackware systemd creepin in maybe?

[James Powell]

SMF is a very advanced init and service management and supervision system, but 
it does things correctly and doesn't come bloated with a horde of so-called 
"building blocks". SMF still relies of various other daemons to work... Hint 
hint.

Sent from my Windows Phone

From: Dragan FOSS<mailto:dragan.f...@gmx.com>
Sent: ‎5/‎23/‎2015 4:55 PM
To: James Powell<mailto:james4...@hotmail.com>; 
dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] Slackware systemd creepin in maybe?

On 05/24/15 01:44 AM, James Powell wrote:
> SMF is more akin to uselessd, s6, and runit. It's an init system only.

http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] The more things change, the more they remain the same

[James Powell]

Mediocre developers who are arrogant end up in the unemployment lines... 
Beautiful phrase.

Sent from my Windows Phone

From: Steve Litt
Sent: ‎5/‎23/‎2015 3:17 PM
To: dng@lists.dyne.org
Subject: [Dng] The more things change, the more they remain the same

Hi all,

Updating a hoard of Troubleshooters.Com links, I came across an article
I wrote in 2008, back when systemd was a twinkle in Harry Poettering's
father's eye.

And yet, the human and technology issues discussed in this article are
eerily like today's systemd situation.

It's called "The Politics of Dependencies":

http://troubleshooters.com/linux/politics_of_dependencies.htm

Enjoy!

SteveT

Steve Litt
May 2015 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Slackware systemd creepin in maybe?

[James Powell]

SMF is more akin to uselessd, s6, and runit. It's an init system only. I think 
even launchd is only an init system as well.

Sent from my Windows Phone

From: Dragan FOSS
Sent: ‎5/‎23/‎2015 3:42 PM
To: Nuno Magalhães; 
dng@lists.dyne.org
Subject: Re: [Dng] Slackware systemd creepin in maybe?

On 05/23/15 11:54 PM, Nuno Magalhães wrote:
> BSD and Solaris
> ecosystems are still systemd-free,

And always will be.

SMF is absolutely perfect service manager in comparison with systemd.
---
root@hipster-oi:~# ptree -a
4 kcfpoold
6 zpool-rpool
1 /sbin/init
   10/lib/svc/bin/svc.startd
 624   /usr/lib/saf/sac -t 300
   685   /usr/lib/saf/ttymon
 630   /usr/lib/saf/ttymon -g -d /dev/console -l console -m
ldterm,ttcompat -h -p hips
   12/lib/svc/bin/svc.configd
   46/sbin/dlmgmtd

.
...
---

OpenRC is good enough for linux ... works perfectly in TRIOS.

Cheers,
Dragan
___
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] Slackware systemd creepin in maybe?

[James Powell]

OpenRC supports a lot of platforms.

Technically, OpenRC solves the problem of sysvinit in every way. Centralized 
scripts, tree based dependencies, service supervision on some level, and 
parallel start up of multiple service trees.

Nothing systemd offers other than mediocre code, bad designs, and destructive 
is useful on any level.

Sent from my Windows Phone

From: Jaret Cantu
Sent: ‎5/‎23/‎2015 3:09 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] Slackware systemd creepin in maybe?

On 05/23/2015 05:54 PM, Nuno Magalhães wrote:
> There's a UNIX ecosystem? The Linux ecosystem may become strictly
> commercial and be used to hunt baby seals, but the BSD and Solaris
> ecosystems are still systemd-free, are they not?

That is one of the arguments against systemd and its seepage (a more
appropriate word than creeping!); systemd is geared entirely to the
Linux kernel with its hard requirements for features like cgroups.
(Also, specifically geared towards Linux DE.)
Thus, systemd cannot even be used on non-Linux systems (or, if it can,
only in a stripped down, impotent form).

In fact, if you look at the Debian packaging files, there are already
exceptions to install around systemd when using the BSD or Hurd kernels.

That really makes the systemd default even more confusing for Debian; it
isn't the default init system for every architecture? (Is that was
kfreebsd is considered in Debian's eyes?) and it cannot be since systemd
doesn't work on those kernels, so Debian essentially has to maintain
*multiple* default init systems as long as they support kfreebsd or want
to support hurd.

It would have been much less of a maintenance burden to just pick one
that worked for every supported platform.



~jaret
___
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] Slackware systemd creepin in maybe?

[James Powell]

Very well said Steve. Xfce fortunately is trying to stay agnostic to software 
as much as it can, after all they are sponsoring ConsoleKit2.

It's a shame Devuan can't make a bold statement against the kernel itself to 
not want to buy into Greg Kroah-Hartman's systemdified kdbus future, and try to 
force the kernel to be forked as well.

I honestly think this needs to be our warcry to every software project out 
there.

"No more!!! Systemd is not your SDK!"

Too much is being poisoned by systemd, and if the UNIX ecosystem of software 
collapses because of this, who is going to be able and willing to pick up the 
pieces?

Nobody, because once software gets too entangled within one system, untangling 
it is just too much work.

To be bluntly honest, at times I hope Linux as a whole implodes because of 
systemd and then all these fadware loving hipsters can go back to Windows and 
suffer.

Sent from my Windows Phone

From: Steve Litt<mailto:sl...@troubleshooters.com>
Sent: ‎5/‎23/‎2015 11:22 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] Slackware systemd creepin in maybe?

On Sat, 23 May 2015 07:29:56 +
toki  wrote:

>
>
> On 23/05/2015 05:18, James Powell wrote:
> > True, but developers are banding together to resist this as well,
> > and fork projects as needed.
>
> But what happens when one has to fork everything from Firefox to
> Enkive to Hadoop to Tryton?

In a word, boycott.

Xfce is starting to get too entangled, so I use Openbox. If Openbox
gets snared, I'll go to dwm. If firefox becomes entangled, I'll move to
xxxterm or one of the other "light" browsers. If those get entangled,
I'll use a text browser for most things, and a containerized GUI
browser for the remainder.

We work with free software, and pay no money for it, but maintaining
*our* standards for what goes on our boxes is anything but free. We,
and I mean we as a user community, not necessarily we as a distro, need
to scale back our expectations, work harder, be more innovative, be
flexible in changing our work habits to accommodate less-dependencied
software. The person who "simply must" work a certain way and will not
consider changing to adapt when his pet software goes entangled, will
not survive in owner-maintainable software, and must join those who
gleefully add locked computers to their locked phones.

You know when I knew Devuan had it right? When Devuan declined to
support Gnome. Declined to jump through ever increasing hoops to
depoetterize ever more sabotaged software, but instead basically said
"hey, if you're so in love with Gnome that it's a must have, then
Devuan is the wrong place for you."

If Tryton demands systemd, find a different ERP. If Hadoop demands
systemd, find a different big data system. If Firefox (which isn't the
the most stable program anyway) requires systemd, use xxxterm or
whatever. If Enkive requires systemd, find something else to do
whatever email machinations Enkive does. And when I say "different", I
specifically include commercially licensed software, because vendor
lockin is vendor lockin, whether by contract or by complexity ruling
out owner maintenance. If it weren't for PC-BSD, Manjaro-OpenRC and
Devuan, I'd be using a Mac today. Once I can't fix/modify my own
possessions, does it really matter whether it's free software or not?

If every consumer walked away from bad deals like systemd requirements,
such bad deals would wither on the vine. We've come together as a
community to make a systemd-free distro. That's half the job. The other
half is each of us, as consumers, saying goodbye to those programs that
decide it would be [hip|easier|necessary] to enmesh with V'jer. If
enough of us do that and publicise it enough, "upstreams" might think
twice before walking happily into their assimilation.

By the way, for that one app that's absolutely business critical with
absolutely no substitute, the consumer can use a container, so we
don't have to put ourselves out of business to do this.

SteveT

Steve Litt
May 2015 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Slackware systemd creepin in maybe?

[James Powell]

I know a few projects do, but they are at least isolated. What did the 
developer say afterwards?

Sent from my Windows Phone

From: toki<mailto:toki.kant...@gmail.com>
Sent: ‎5/‎23/‎2015 12:30 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] Slackware systemd creepin in maybe?



On 23/05/2015 05:18, James Powell wrote:
> True, but developers are banding together to resist this as well, and fork 
> projects as needed.

But what happens when one has to fork everything from Firefox to Enkive
to Hadoop to Tryton?

I've forgotten what I installed, but it was SystemD only, and the
developer had no idea that it required SystemD.

jonathon


___
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] Slackware systemd creepin in maybe?

[James Powell]

True, but developers are banding together to resist this as well, and fork 
projects as needed.

Sent from my Windows Phone

From: toki
Sent: ‎5/‎22/‎2015 8:27 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] Slackware systemd creepin in maybe?



On 19/05/2015 12:00, Irrwahn wrote:

> If, OTOH, in contrast an upstream maintainer were to introduce hard 
> dependencies on any specific init system,

disabling or crippling crucial core functionality of the software when
used with any other init system,

Part of the issue is that developers are being subtly pressured to
support systemd, and drop support for other init systems.

jonathon

___
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

[Dng] Suggestion for vdev

[James Powell]

Jude, when vdev gets mature enough, could you submit an init script to the 
OpenRC project, please?

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

Re: [Dng] Slackware systemd creepin in maybe?

[James Powell]

I think Patrick means unless systemd becomes 100% unavoidable as a dependency. 
However as replacement software is made available this will lessen.

Currently we still use udev-classic and ConsoleKit with little else, but as 
KDE/Plasma5 is being looked at, things are being considered.

Runit is nice, but not without it's problems. We tried to import it to LFS, and 
did so with moderate success. We did have to import ArchIgnite's init clone 
tools as init-shim for our project. Our scripts were very alpha grade, to just 
"get it working", but we did prove it viable.

Sent from my Windows Phone

From: Steve Litt<mailto:sl...@troubleshooters.com>
Sent: ‎5/‎20/‎2015 2:45 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] Slackware systemd creepin in maybe?

Runit rocks! IMHO it's one of the very best init systems, and I doubt
it would be difficult for a Devuan end user to retrofit with runit.

I don't know Patrick's or Devuan's opinion of the http://unlicense.org/
style Public Domain, but if it's acceptable, Epoch, while not quite as
full featured as runit, is a dead-bang easy way to add another init to
your system.

These two init systems are much easier to add to uncontaminated distros
like Slackware and Devuan.

SteveT

Steve Litt
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz


On Wed, 20 May 2015 21:25:51 +
James Powell  wrote:

> Currently work is being made to offer alternatives to sysvinit in
> Slackware such as OpenRC and Runit, as they are the most complete
> init replacement systems. Work has been slow in progress, but there
> are solid efforts to bring offerings around over at LinuxQuestions.
> We have been met with resistance, but so far, we are still somewhat
> active in the efforts.
>
> To: james4...@hotmail.com; dng@lists.dyne.org
> Subject: RE: [Dng] Slackware systemd creepin in maybe?
> From: yve...@tpg.com.au
> Date: Thu, 21 May 2015 05:28:46 +1000
>
>  Hi James,
> Thanks for the info.
>
> Keeping Slack stable is the reason why some have picked this
> excellent distro instead of a bsd during the mass migration away from
> the systemd/Debian debacle. Sure hope the same fiasco that occurred
> with systemd/Debian does not happen with Slack in future.
>
> IMHO, that would be very destructive to Slackware :-(
>
>
> Thanks again and keep slacking.
>
>
>
>
> - Original Message -
> From: "James Powell" 
> To:"Anto" , ,
>  Cc:
> Sent:Tue, 19 May 2015 14:18:40 -0700
> Subject:RE: [Dng] Slackware systemd creepin in maybe?
>
>
>
> Hey guys, let me clarify the Slackware position on systemd.
>
>
> Patrick has no intent on enforcing the usage of systemd upon
> Slackware and it's users unless it becomes an unavoidable issue. So
> far, this has not been the case in the slightest, and we doubt it
> will be. Slackware intends to keep the bsd-stylized sysvinit
> implementation.
>
>
> Packages do have some systemd files for systemd systems, but because
> all packages in Slackware try to stay as vanilla as possible to
> "./configure && make && make install" methodology. You are free to
> remove them after-the-fact, or modify the Slackbuild scripts to
> remove them during the package construction stages.
>
>
> There is a systemd experimental repackage of Slackware called
> Dlackware by a package developer named bartgymnast, but while the
> repack is specific to systemd, it is unsupported, unofficial, and
> still considered unstable in build.
>
>
> I hope this clarifies this.
>
>
> Sent from my Windows Phone
>
>
> From:
> Anto
> Sent:
> ‎5/‎19/‎2015 12:14 PM
> To:
> yve...@tpg.com.au;
> dng@lists.dyne.org
> Subject:
> Re: [Dng] Slackware systemd creepin in maybe?
>
>
>
>
>
>
> On 19/05/15 20:31, yve...@tpg.com.au wrote:
>
> >
>
> >  Hi Anto,
>
> >
>
> > From your posts it appears that you are doing a lot of work
> > cleaning
>
> > up these packages.
>
> >
>
> > Apologies if I've missed a previous post as I think it would be
>
> > extremely helpful to all interested if you documented your
> > invaluable
>
> > work on a wiki of sorts?
>
> >
>
> > Perhaps more could assist with the cleanups :-)
>
> >
>
> >
>
> > Thanks
>
> >
>
>
> Yes, it has been quite a lot of work for me, especially due to the
> lack
>
> of my skills in the programming and Debian packaging as I am just an
>
> ordinary user. So what I have been doing is basically trial and
> error :)
>
>
> Chan

Re: [Dng] Slackware systemd creepin in maybe?

[James Powell]

Currently work is being made to offer alternatives to sysvinit in Slackware 
such as OpenRC and Runit, as they are the most complete init replacement 
systems. Work has been slow in progress, but there are solid efforts to bring 
offerings around over at LinuxQuestions. We have been met with resistance, but 
so far, we are still somewhat active in the efforts.

To: james4...@hotmail.com; dng@lists.dyne.org
Subject: RE: [Dng] Slackware systemd creepin in maybe?
From: yve...@tpg.com.au
Date: Thu, 21 May 2015 05:28:46 +1000

 Hi James,
Thanks for the info.

Keeping Slack stable is the reason why some have picked this excellent distro 
instead of a bsd during the mass migration away from the systemd/Debian debacle.
Sure hope the same fiasco that occurred with systemd/Debian does not happen 
with Slack in future.

IMHO, that would be very destructive to Slackware :-(


Thanks again and keep slacking.




- Original Message -
From: "James Powell" 
To:"Anto" , , 
Cc:
Sent:Tue, 19 May 2015 14:18:40 -0700
Subject:RE: [Dng] Slackware systemd creepin in maybe?



Hey guys, let me clarify the Slackware position on systemd.


Patrick has no intent on enforcing the usage of systemd upon Slackware and it's 
users unless it becomes an unavoidable issue. So far, this has not been the 
case in the slightest, and we doubt it will be. Slackware intends to keep the 
bsd-stylized sysvinit implementation.


Packages do have some systemd files for systemd systems, but because all 
packages in Slackware try to stay as vanilla as possible to "./configure && 
make && make install" methodology. You are free to remove them after-the-fact, 
or modify the Slackbuild scripts
 to remove them during the package construction stages.


There is a systemd experimental repackage of Slackware called Dlackware by a 
package developer named bartgymnast, but while the repack is specific to 
systemd, it is unsupported, unofficial, and still considered unstable in build.


I hope this clarifies this.


Sent from my Windows Phone


From:
Anto
Sent:
‎5/‎19/‎2015 12:14 PM
To:
yve...@tpg.com.au;
dng@lists.dyne.org
Subject:
Re: [Dng] Slackware systemd creepin in maybe?






On 19/05/15 20:31, yve...@tpg.com.au wrote:

>

>  Hi Anto,

>

> From your posts it appears that you are doing a lot of work cleaning 

> up these packages.

>

> Apologies if I've missed a previous post as I think it would be 

> extremely helpful to all interested if you documented your invaluable 

> work on a wiki of sorts?

>

> Perhaps more could assist with the cleanups :-)

>

>

> Thanks

>


Yes, it has been quite a lot of work for me, especially due to the lack 

of my skills in the programming and Debian packaging as I am just an 

ordinary user. So what I have been doing is basically trial and error :)


Change something, re-compile, revert back when fails, again and again 

until the packages get successfully compiled. But that is not the end of 

it. The installation of the packages that have been successfully 

compiled are not always smooth. I broke my install several times. But I 

didn't spend time to troubleshoot, again due to the lack of my skills. 

After taking some logs and notes on something which I thought might be 

related to the changes that I made. I put back the disk image which I 

always take before any installation, then start all over again :)


So I think that is quite embarrassing, especially for Devuan (for me, I 

don't really care) if that kind of process would be documented some 

where on Devuan site :)


I have leant a lot by reading the commits on Devuan gitlab, especially 

the ones with the title related to "removing systemd" like 
https://git.devuan.org/packages-base/dbus/commit/2ebb243f3fa51790d93e7f21a11dca324df6b0fd,

https://git.devuan.org/packages-base/network-manager/commit/665eb3cb32e9ca3f4294f783375e4118d9b78427


and many others.


Cheers,


Anto


___

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] Slackware systemd creepin in maybe?

[James Powell]

Hey guys, let me clarify the Slackware position on systemd.

Patrick has no intent on enforcing the usage of systemd upon Slackware and it's 
users unless it becomes an unavoidable issue. So far, this has not been the 
case in the slightest, and we doubt it will be. Slackware intends to keep the 
bsd-stylized sysvinit implementation.

Packages do have some systemd files for systemd systems, but because all 
packages in Slackware try to stay as vanilla as possible to "./configure && 
make && make install" methodology. You are free to remove them after-the-fact, 
or modify the Slackbuild scripts to remove them during the package construction 
stages.

There is a systemd experimental repackage of Slackware called Dlackware by a 
package developer named bartgymnast, but while the repack is specific to 
systemd, it is unsupported, unofficial, and still considered unstable in build.

I hope this clarifies this.

Sent from my Windows Phone

From: Anto
Sent: ‎5/‎19/‎2015 12:14 PM
To: yve...@tpg.com.au; 
dng@lists.dyne.org
Subject: Re: [Dng] Slackware systemd creepin in maybe?



On 19/05/15 20:31, yve...@tpg.com.au wrote:
>
>  Hi Anto,
>
> From your posts it appears that you are doing a lot of work cleaning
> up these packages.
>
> Apologies if I've missed a previous post as I think it would be
> extremely helpful to all interested if you documented your invaluable
> work on a wiki of sorts?
>
> Perhaps more could assist with the cleanups :-)
>
>
> Thanks
>

Yes, it has been quite a lot of work for me, especially due to the lack
of my skills in the programming and Debian packaging as I am just an
ordinary user. So what I have been doing is basically trial and error :)

Change something, re-compile, revert back when fails, again and again
until the packages get successfully compiled. But that is not the end of
it. The installation of the packages that have been successfully
compiled are not always smooth. I broke my install several times. But I
didn't spend time to troubleshoot, again due to the lack of my skills.
After taking some logs and notes on something which I thought might be
related to the changes that I made. I put back the disk image which I
always take before any installation, then start all over again :)

So I think that is quite embarrassing, especially for Devuan (for me, I
don't really care) if that kind of process would be documented some
where on Devuan site :)

I have leant a lot by reading the commits on Devuan gitlab, especially
the ones with the title related to "removing systemd" like
https://git.devuan.org/packages-base/dbus/commit/2ebb243f3fa51790d93e7f21a11dca324df6b0fd,
https://git.devuan.org/packages-base/network-manager/commit/665eb3cb32e9ca3f4294f783375e4118d9b78427
and many others.

Cheers,

Anto

___
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] A novice attempt to speed up Devuan development

[James Powell]

Not exactly.

Eudev is free of systemd, but it shares nearly 99.5% of it's code base with 
systemd-udev, plus some minor fix ups from the Gentoo developers.

It's name technically means Extracted udev. You get the same udev if you build 
the systemd-udev with an extraction kit as eudev, minus the fix ups.

The only time eudev will become a true fork is when kdbus gets official, but no 
one is betting on it, nor holding our breath... yet.

Sent from my Windows Phone

From: Hendrik Boom
Sent: ‎5/‎14/‎2015 3:13 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] A novice attempt to speed up Devuan development

On Thu, May 14, 2015 at 10:15:50PM +0200, Svante Signell wrote:
> On Thu, 2015-05-14 at 12:15 -0500, T.J. Duchene wrote:
> > > I think the fact that I pointed out clearly shows that there is very good
> > > technical reason to exclude udev, unless you are willing to be the 
> > > maintainer
> > > of udev outside systemd source tree in Devuan.
> >
>
> > The shortest and most reasonable route to release a stable 1.0 of
> > Devuan is to use udev for the present.
>
> See below.
>
> >  Eudev might make a good
> > replacement, but udev is still the best candidate in terms of people
> > using it if you follow the principle that "eyes make bugs shallow".
>
> People are working _now_ on eudev as a replacement for udev until vdev
> is finished. It might even be a good replacement for udev already for
> the devuan jessie release. What do you do, except chat?

Isn't eudev actually the systemd-free fork of udev everyone is asking for?

-- hendrik
___
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] [dng] vdev status update (2015-05-03)

[James Powell]

There's no issues, but due to the variable in the way Slackware packages 
things, I have to create directories in the temp install, then use cp to 
installing things which ends up being messy.

Not to complain, but the lack of a traditional configure file to set the 
install paths does make things more hectic, especially with some of the config 
files and other shell scripts.

While unnecessary, yet, it does make packing vdev a bit more hectic.

Slackware uses a sort of fakeroot style packager, pkgtools, that creates a temp 
directory for source and one for the build output. It then uses configure to 
create $DEST set paths for installing into the temp directory before packaging.

It's not anything major needed, but it would help in the future, especially 
installing to /lib64 for the lib path instead of /lib which is symlinked on 
other 64-bit distros.

Sent from my Windows Phone

From: Jude Nelson<mailto:jud...@gmail.com>
Sent: ‎5/‎14/‎2015 12:33 AM
To: James Powell<mailto:james4...@hotmail.com>
Cc: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] [dng] vdev status update (2015-05-03)

Hi James,
On Thu, May 14, 2015 at 12:04 AM, James Powell 
wrote:

>  Thanks Jude.
>
> The Slackware package is delayed, but only due to the lack of a Slackware
> style script. I might try to ask one of the Slackware team for assistance
> when I resume work. However, the package is fairly much completed in terms
> of installation points and directory setup.
>

Hey, that's pretty cool!  First the AUR packages (from Jack Frost aka
openfbt), now Slackware.

I'm not a Slackware or Arch user, but please let me know if there's
anything I can do to make packaging easier?  I don't want to make things
needlessly difficult :)

-Jude


> Sent from my Windows Phone
>  --
> From: Jude Nelson 
> Sent: 5/13/2015 8:24 PM
> To: dng@lists.dyne.org
> Subject: [Dng] [dng] vdev status update (2015-05-03)
>
>  Hey everyone,
>
>  I have the latest news for vdev:
>
> * vdev now creates symlinks for:
> -- /dev/v4l/by-path
> -- /dev/disk/by-partuuid
> -- /dev/disk/by-partlabel
>
>  Thank you Scooby for helping me confirm this!
>
>  * vdev now sets the proper ownership and permissions for:
>  -- /dev/mISDNtimer
> -- /dev/mwave
> -- /dev/parport[0-9]
> -- /dev/printer
> -- /dev/ppdev
> -- /dev/lp[0-9]
> -- /dev/irlpt[0-9]
> -- /dev/sch[0-9]
> -- /dev/pktcdvd[0-9]
> -- /dev/qft[0-9]
> -- /dev/zqft[0-9]
> -- /dev/nqft[0-9]
> -- /dev/nzqft[0-9]
> -- /dev/rawqft[0-9]
> -- /dev/nraqft[0-9]
> -- /dev/rawctl
> -- /dev/aoe
> -- /dev/lirc[0-9]
> -- /dev/legousbtower
> -- /dev/sonypi
> -- /dev/mmtimer
> -- /dev/sgi_*
> -- /dev/z90crypt
>
>  * Didier Kryn has gotten vdevd and vdevfs to statically link and compile
> with musl libc.  I'm looking forward to merging his contributions :)
>
>  * the build system has been refactored to use Makefiles more
> appropriately:
> -- every generated file gets written to a separate build/ directory
> -- every generated file is created by a non-phony target (i.e. nothing
> happens by side-effect)
> -- global buildconf.mk for setting variables
> Thanks to Didier again for the suggestion!
>
>  * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup,
> blkid, etc.  Moreover, vdev's helpers conditionally use these programs if
> they are present.  This means that vdev doesn't strictly depend on them
> anymore, which is good if you're not using mapped devices or logical
> volumes.  Thanks to Anto for the suggestion!
>
> * the initramfs hook pulls in the correct GNU libc files now, so chown(1)
> will work correctly in the initramfs.  Thanks to Scooby, Isaac Dunham, Tom
> H for their help!
>
>
> [For Next Time]
>
>  * The next immediate objective is to package vdevd for Devuan, to make
> it easier to test (in particular, easier to get a working initramfs).  I'm
> currently dissecting udev's packaging and reading through Isaac's mdev
> scripts to see what to expect and what we can recycle.  I've never packaged
> something this complex before.  Thanks to Scooby, Anto, Tom H, and others
> for all their help on getting me this far!
>
>  * Symlinks and permissions for RAID devices (/dev/md[0-9] and friends).
> I don't run a RAID myself, so I'll need to go set one up in QEMU.  If
> someone wants to test vdev with a RAID, let me know, and I'll try to write
> a helper script to play around with sooner rather than later.
>
>  * In some distros and configurations, a separate device manager (like
> mdev) can populate just enough of /dev to mount root, but not try to set up
> any symlinks.  Vdevd m

Re: [Dng] [dng] vdev status update (2015-05-03)

[James Powell]

Thanks Jude.

The Slackware package is delayed, but only due to the lack of a Slackware style 
script. I might try to ask one of the Slackware team for assistance when I 
resume work. However, the package is fairly much completed in terms of 
installation points and directory setup.

Sent from my Windows Phone

From: Jude Nelson
Sent: ‎5/‎13/‎2015 8:24 PM
To: dng@lists.dyne.org
Subject: [Dng] [dng] vdev status update (2015-05-03)

Hey everyone,

I have the latest news for vdev:

* vdev now creates symlinks for:
-- /dev/v4l/by-path
-- /dev/disk/by-partuuid
-- /dev/disk/by-partlabel

Thank you Scooby for helping me confirm this!

* vdev now sets the proper ownership and permissions for:
-- /dev/mISDNtimer
-- /dev/mwave
-- /dev/parport[0-9]
-- /dev/printer
-- /dev/ppdev
-- /dev/lp[0-9]
-- /dev/irlpt[0-9]
-- /dev/sch[0-9]
-- /dev/pktcdvd[0-9]
-- /dev/qft[0-9]
-- /dev/zqft[0-9]
-- /dev/nqft[0-9]
-- /dev/nzqft[0-9]
-- /dev/rawqft[0-9]
-- /dev/nraqft[0-9]
-- /dev/rawctl
-- /dev/aoe
-- /dev/lirc[0-9]
-- /dev/legousbtower
-- /dev/sonypi
-- /dev/mmtimer
-- /dev/sgi_*
-- /dev/z90crypt

* Didier Kryn has gotten vdevd and vdevfs to statically link and compile
with musl libc.  I'm looking forward to merging his contributions :)

* the build system has been refactored to use Makefiles more appropriately:
-- every generated file gets written to a separate build/ directory
-- every generated file is created by a non-phony target (i.e. nothing
happens by side-effect)
-- global buildconf.mk for setting variables
Thanks to Didier again for the suggestion!

* the initramfs hook conditionally pulls in iproute2, lvm, dmsetup, blkid,
etc.  Moreover, vdev's helpers conditionally use these programs if they are
present.  This means that vdev doesn't strictly depend on them anymore,
which is good if you're not using mapped devices or logical volumes.
Thanks to Anto for the suggestion!

* the initramfs hook pulls in the correct GNU libc files now, so chown(1)
will work correctly in the initramfs.  Thanks to Scooby, Isaac Dunham, Tom
H for their help!


[For Next Time]

* The next immediate objective is to package vdevd for Devuan, to make it
easier to test (in particular, easier to get a working initramfs).  I'm
currently dissecting udev's packaging and reading through Isaac's mdev
scripts to see what to expect and what we can recycle.  I've never packaged
something this complex before.  Thanks to Scooby, Anto, Tom H, and others
for all their help on getting me this far!

* Symlinks and permissions for RAID devices (/dev/md[0-9] and friends).  I
don't run a RAID myself, so I'll need to go set one up in QEMU.  If someone
wants to test vdev with a RAID, let me know, and I'll try to write a helper
script to play around with sooner rather than later.

* In some distros and configurations, a separate device manager (like mdev)
can populate just enough of /dev to mount root, but not try to set up any
symlinks.  Vdevd must have a way for the admin to tell it to run helper
scripts for the device even if its device node was already created
(indicating that it has been set up), so the symlinks and permissions still
get set appropriately.  Thanks to Scooby for reporting this!

Thanks,
-Jude
___
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] Systemd discussions at LinuxQuestions.

[James Powell]

I agree T. J.

The problem is too much "thinking" about problems, rather than offering a clear 
solution other than scrapping the fore and replacing it entirely seems to be 
the source of the problem.

One argument I stand by adamantly is that while sysvinit was imperfect in 
design, it left room to allow the tree to branch in various ways with the 
applied tools. OpenRC is a prime example of taking sysvinit and expanding upon 
it in a way that allows for diversity just like daemontools, bsd-style 
scripting, and other service supervisors do brilliantly. Sysvinit doesn't have 
to be the workhorse, but it can be the harness providing the standard functions 
of startup and shutdown for the workhorse of your choosing.

However few people are willing to step outside their boxes and look for ways to 
improve systems without resulting to rampant progressivism with new software 
than isn't even finished in it's goals.

In the late 90s Dan Bernstein's daemontools could have ended the overreliance 
on sysvinit, but few embraced it.

Now we see the rush to "do" when something comes along to create a rift. No ill 
will to anyone, but if anyone had have "done" years ago, there might be less a 
need to "do" now.

Sent from my Windows Phone

From: T.J. Duchene
Sent: ‎5/‎13/‎2015 8:27 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] Systemd discussions at LinuxQuestions.





Unfortunately this seems to be a growing trend following the Microsoft playbook 
of acquisition, suppression, and extinction on various Linux communities and 
mailing lists I've been privy to as of recent.

Fewer and fewer distributions have avoided systemd but discussion into 
alternatives is growingly met with hostilities. ArchLinux took a severe 
hardline approach and rampantly banned any anti-systemd topics and users as 
well as anyone offering alternatives. While LQ has been trying to maintain 
neutrality as a position, growing numbers of systemd fanboys who immediately 
attack and troll people just to get them hushed or banned is climbing.



In advance, I just want to say that what I am about to say is my own opinion 
and in no way reflects or represents anyone else.



Put politely as possible: “Stuff them.”



I do not think that this is any one person, community or agenda.  The Linux 
community for the most part has been dominated by communities beholden to a 
particular version of Linux and never to Linux as a whole.  This encourages 
“group think.”  Once you get them fixated on anything – it does not have to be 
systemd – it could be package format or filesystem, everyone else is wrong and 
they are right.  It does not matter what the  reasons are.  Almost all 
individual impulse is subsumed.  When someone objects, for example Ian Jackson 
over at Debian, the community becomes so hostile that they leave.



I just use the code.  That is the whole point of opensource, and if people do 
not like my opinions then so be it.  I seldom participate in Linux communities 
outside of developer discussions or help topics.  Devuan is an exception.  I 
came back, because for some reason I am genuinely curious about what goes on 
here.  In the main, it is my opinion that the entire community is just too 
toxic.  Just like politics, people have become intolerant beyond reason.  I try 
very hard to be reasonable, but I frown on Linux these days.

___
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] Systemd discussions at LinuxQuestions.

[James Powell]

Unfortunately this seems to be a growing trend following the Microsoft playbook 
of acquisition, suppression, and extinction on various Linux communities and 
mailing lists I've been privy to as of recent.

Fewer and fewer distributions have avoided systemd but discussion into 
alternatives is growingly met with hostilities. ArchLinux took a severe 
hardline approach and rampantly banned any anti-systemd topics and users as 
well as anyone offering alternatives. While LQ has been trying to maintain 
neutrality as a position, growing numbers of systemd fanboys who immediately 
attack and troll people just to get them hushed or banned is climbing.

If you read the other, long closed, systemd topics, there are several trolls 
who have mercilessly attacked several users including TobiSGD.

Trying to talk technicality on systemd gets futile unless you are pro-systemd.

-Jim

P.S. - I'm working on a better email client, but unfortunately this is all I 
can manage currently. Sorry if it's awkward for Devuan's mailing list here.

Sent from my Windows Phone

From: Philip Lacroix<mailto:phi...@posteo.de>
Sent: ‎5/‎13/‎2015 9:15 AM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] Systemd discussions at LinuxQuestions.

I've read the mentioned thread, although not completely yet, and I
appreciated Jude's and nextime's interventions. Guys, you met TobiSGD,
who should be a LQ moderator but is also an active systemd advocate,
according to what I've seen in the past (and more than ever on that very
thread). Unfortunately, several systemd-related threads (as well as
others about other "controversial" topics) have been turned into
disgusting cesspits quite recently on LQ, hence I can understand why
other moderators like unSpawn prefer not to see anything like that
anymore. Too bad that the Devuan thread was closed down, but IMHO it was
not because of Devuan as such: somebody, apparently, is not willing to
clean up heaps of trolls' rubbish once again.

Best,
Philip


Am 10.05.2015 23:17 schrieb James Powell:
> Unfortunately the moderators at LinuxQuestions have closed off
> discussing the Devuan stance topic that had been open and participate
> in over the repeated squabbling, though honestly, very little was done
> other than the people who seemed offended by the choice of Devuan's
> developers lack of choice of systemd, and unwillingness to stop asking
> about funding and other repeatedly defended arguments which turned the
> discussion of Devuan into a defense of Devuan.
>
> Just to make it known, the LQ staff have not taken kindly to systemd
> topics since many of the pro-systemd crowd seem to act more in
> attacking the stance of being anti-systemd rather than the principles
> of being anti-systemd for software sanity reasons. Very little real
> discussion of systemd's merits and technicals (if topics even can be
> soundly made) ever seems to go anywhere due to the crowd there.
>
> This is unfortunate but due to the fact several staff members are from
> the pro-systemd camp, and the fact the staff have made their decisions
> on those topics, any discussion is probably going to continually go in
> that same direction, and topics will go nowhere on that forum when
> that topic is brought up.
>
> I though I'd let you all know before going to the LinuxQuestions topic
> and finding it locked out.
>
> -Jim

___
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

[Dng] Systemd discussions at LinuxQuestions.

[James Powell]

Unfortunately the moderators at LinuxQuestions have closed off discussing the 
Devuan stance topic that had been open and participate in over the repeated 
squabbling, though honestly, very little was done other than the people who 
seemed offended by the choice of Devuan's developers lack of choice of systemd, 
and unwillingness to stop asking about funding and other repeatedly defended 
arguments which turned the discussion of Devuan into a defense of Devuan.

Just to make it known, the LQ staff have not taken kindly to systemd topics 
since many of the pro-systemd crowd seem to act more in attacking the stance of 
being anti-systemd rather than the principles of being anti-systemd for 
software sanity reasons. Very little real discussion of systemd's merits and 
technicals (if topics even can be soundly made) ever seems to go anywhere due 
to the crowd there.

This is unfortunate but due to the fact several staff members are from the 
pro-systemd camp, and the fact the staff have made their decisions on those 
topics, any discussion is probably going to continually go in that same 
direction, and topics will go nowhere on that forum when that topic is brought 
up.

I though I'd let you all know before going to the LinuxQuestions topic and 
finding it locked out.

-Jim

Sent from my Windows Phone___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A novice attempt to speed up Devuan development

[James Powell]

> And on the other side, anything actually committed by the author means 
> it is part of/a fix for eudev development alone.  Here's an example of 
> such a commit:
> 
> https://github.com/gentoo/eudev/commit/93fc111c3c701a588f6ba7c39e514f8ffec425a4
> 
> Fix builds on gcc 4.5?  Yeah, I can see systemd scoffing at that.  I 
> almost want to, too!
> I suppose there is nothing which would prevent systemd from taking fixes 
> from eudev if they wanted them.

>From previous dealings with the systemd developers and monitoring how they 
>look at bugs, they often will scoff at and ignore issues with older systems 
>and software claiming that it's either not a bug or not worth fixing things 
>for outdated software.

I think the eudev developers are importing relevant-only code as needed, and 
fixing the rest as they find problems, and ignoring the garbage. At least we 
know where the real talent is.

There's an old rule of thumb about coding piss poor software, and it's straight 
out of the Microsoft Bible oddly. "Never let bad and poorly written code 
compound upon itself." 
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Suckless init and friends

[James Powell]

As a co-submission, the Runit-for-LFS project over at Bitbucket is freely 
available. We also have a subproject called init-shim which duplicates many of 
the sysvinit software.

https://bitbucket.org/ReaperX7/runit-for-lfs

If Devuan can find it useful, by all means clone and redevelop as needed. Our 
stuff is MIT licensed to maximize freedom to you to users/deployers so as long 
as you acknowledge the original developers, feel free to make it your own as 
you see fit as Runit-for-Devuan.

Sent from my Windows Phone

From: Steve Litt
Sent: ‎5/‎8/‎2015 11:28 AM
To: dng@lists.dyne.org
Subject: [Dng] Suckless init and friends

Hi all,

This email isn't a recommendation for the Devuan distribution, it's
just some interesting info for the more DIY members of the Devuan
community...

Consider the following:

* Suckless init: http://git.suckless.org/sinit

* Suckless svc: http://core.suckless.org/svc

* Suckless portable utils (sbase): http://core.suckless.org/sbase

* Suckless nonportable utils (ubase): http://core.suckless.org/ubase

The init program does initialization with no process management. It
passes control to rc.whatever. In that respect, it doesn't conform to
Laurent's minimum of supervising at least one process, but rc.whatever
can exec to something that manages all processes, so you have only that
one tiny process at risk.

The ubase utilities include something called "respawn", which
apparently manages a process via fifo
(http://git.suckless.org/ubase/tree/respawn.c). They have some
shellscripts in the svc svc-master group, which appear to make for very
simple init scripts.

=== MY PLANS ===

So what I'm going to do, when I get the time, is init a Linux box with
Suckless init (http://git.suckless.org/sinit/tree/sinit.c), and have it
transfer control to rc.whatever, which will be a tiny script using
respawn to run all the rest of the process management, using respawn
for early stuff, and daemontools or daemontools-encore for the rest.

I've already done a proof of concept, I can init to /bin/bash using
Suckless Init, and when I send the proper SIGUSR1, SIGCHLD, or SIGINT
to PID1, it runs rc.shutdown with the expected arguments. Here's an
example rc.shutdown: http://git.2f30.org/ports/tree/fs/bin/rc.shutdown

The result will be very close to an init system as defined by Laurent:
The only unmanaged process will be rc.whatever, and that will be a tiny
script unlikely to abort by itself.

If I *really* get into it, I think there might be a possibility of
mixing the code of sinit.c with the code of respawn.c, to produce an
init that *supervises* rc.whatever instead of just running it, with
rc.whatever supervising and sub-supervising all the rest. What would
make this challenging is that respawn.c
(http://git.suckless.org/ubase/tree/respawn.c) depends on a fifo, and
this might be before the root filesystem is mounted.

Like I said before, I'm not advocating that Devuan put in any hooks or
packages for this stuff, I'm just commenting on what's available for
experimentation.

SteveT

Steve Litt
May 2015 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng