Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, Jul 13, 2016 at 07:32:11PM -0700, Rick Moen wrote: [cut] > > And I'm not the one who sought to wave that in the faces of the Dng > mailing list, either. You are. Because, I rather suspect, you wanted > to engineer a confrontation between me and the Devuan Project. > Unfortunately, this doesn't work because I am a fan of that project. Wait Rick, I don't think anybody wants to engineer a confrontation between you and Devuan, indeed :) I personally appreciate your contribution to the discussion, and I understand some of the critics moved by Steve Litt. I am sure that the thread will be useful to many of us, or at least to those who dare delving into the prolonged emails that compose it :D We're grown-ups, aren't we? So we can discuss without hanger, since hanger we do not need. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, Jul 13, 2016 at 03:54:46PM -0700, Rick Moen wrote:
[cut]
>
> > I am pretty sure I have never raised any critique to your work. I have
> > just stressed that I *believe* that, given the current attitude of
> > systemd & co., that consists into eating as much as they can of almost
> > anything in the low-level userspace, breaking things in the process
> > without saying "sorry", there is probably not much time left until
> > everything down there will depend on systemd.
>
> I am not at all convinced of this.
>
> However, I'm quite certain that such eventualities would immediately
> inspire creation and publication of even more alternate packagings and
> repos of same, to sidestep that and fix that (hypothetical) step.
Look Rick, Devuan is exactly trying to do this, in a consistent and
comprehensive way, well before it will be too late.
[cut]
>
> > Hence, pinning is not, IMHO, a viable long-term solution.
>
> This does not follow logically from your premises. However, {sigh} also
> I did not _say_ package-pinning is a viable long-term solution (to
> anything in particular).
>
> What I said was 'Hey, I tried, this, it works for these [cited]
> use-cases.' And then I said 'Third-party repos with package preferences
> are an already-proven way to perpetuate a Debian-variant community,
> imposing an external policy on it. I see no reason this could not
> be used with a no-systemd policy.'
>
> And I said a lot more, such as (when challeged by Mr. Steve Litt about
> my opinion that Devuan was an overreaction) outlining general methods of
> maintaining Debian-variant communities that are already proven and in
> use.
I think I know very well what you said, since I believe I can
understand English a little :) The conclusion seemed to be that since
pinning worked for your use case, there was no reason to fork Debian
and start Devuan. The latter one is either a logical fallacy on your
side, or my misunderstanding of what you have written. I wouldn't be
bothered that much in either case.
The bottom line is: what you think works for you might not work for
others :)
[cut]
>
> NetworkManager? GNOME crud.
>
> gdm3? GNOME crud.
>
> nautilus-dropbox? GNOME crud.
>
> apper? GNOME crud.
>
> daisy-player? I don't use text-to-speech, and if I did and wanted that
> package, I'd use dpkg-buildpackage to recompile and rebuild the package
> locally without the dumb GNOME build dependency.
>
> The only package my survey found that gave me pause was package 'hplip'
> -- until I found in a couple of minutes' reading that it's a bloated
> metapackage with GNOME crud, and that what you actually want is packages
> printer-driver-hpcups and printer-driver-hpijs. So, I made a point of
> documenting that in particular.
>
> 'Avoid GNOME crud' is in fact good overall advice. ;->
>
> I specifically say I do _not_ speak for all use-cases. However, my page
> does cover an enormous range of use-cases. Unless it has errors -- and
> I keep asking people what 'important' packages I'm missing and (e.g.)
> what 'compromises' there are, and I hear nothing back except lazy
> rhetoric.
>
Well, you know better than me by now that each user tends to put
himself at the centre of the world, and is normally biased in thinking
that his or her use case is so common that there is no reason why
people should need anything else. Reality is a bit more complicated
than that, and ways more colorful :)
[cut]
>
> I greatly doubt that a bunch of Freedesktop.org desktop-computing
> weenies and GNOME freaks are much of a threat to my computing stability,
> maintainability, and security, but I have a great deal of experience
> working around blockheaded distro policies, and tools I can sharpen to
> do as much more of that as circumstances merit.
There will probably come a day in which the amount of work you need to
do in order to work around blockheaded distro policies will be so
large that you would be better off using some other distro, if you can
find any other distro around that does not have the same problem. Or
you will be forced to make your own distro (which is something that
almost anybody with a basic understanding of Linux should be capable
of doing).
>
> You call it 'duct tape'. I call it local implementation of policy.
> This is, frankly, _exactly_ what all of the professional field
> Operations concerns. Local packages as required, local configuration in
> version control, applied preferably by configuration management software
> (chef, puppet, ansible, salt, cfengine -- pick your poison).
>
I call it duct tape, because if I choose a distribution like Debian
Jessie, which has 42000 packages available, and then I end up being
able to use roughly 60% or 70% of them if I don't want systemd around,
then what I need is another distribution, and if it is not just know,
it will be the case in the near future.
Debian used to be one of the few distributions which enforced
basically one policy: the package manageme
Re: [DNG] Need for documentation
On 14/07/16 17:27, Steve Litt wrote: > On Wed, 13 Jul 2016 22:39:34 -0400 > Steve Litt wrote: > >> Hi all, >> >> When installing, you get to pick which window manager you want. >> Trouble is, there's no obvious way to change your window manager >> after the fact. Somebody needs to document how to do this, and keep >> the document in an obvious place, with a link from the top of our >> documentation tree. > > Golinux told me that to change the window manager, when on the login > screen, you repeatedly press F1 to cycle through the installed window > managers. I confirm this, and will document it. > > However, I think somebody from Devuan should add to the login window's > graphic (the stylized lightgreen and darkergreen Login graphic) the > string "Press F1 to switch window managers." Today's computers should > be discoverable, and this is just too easy not to do. I'd do it myself > but I don't know which graphic, and probably my modification would be > an aesthetic step backward. > File a bug against desktop-base and slim packages and I'll try to make sure we do that on both Regards, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Need for documentation
On Wed, 13 Jul 2016 22:39:34 -0400 Steve Litt wrote: > Hi all, > > When installing, you get to pick which window manager you want. > Trouble is, there's no obvious way to change your window manager > after the fact. Somebody needs to document how to do this, and keep > the document in an obvious place, with a link from the top of our > documentation tree. Golinux told me that to change the window manager, when on the login screen, you repeatedly press F1 to cycle through the installed window managers. I confirm this, and will document it. However, I think somebody from Devuan should add to the login window's graphic (the stylized lightgreen and darkergreen Login graphic) the string "Press F1 to switch window managers." Today's computers should be discoverable, and this is just too easy not to do. I'd do it myself but I don't know which graphic, and probably my modification would be an aesthetic step backward. Thanks, SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Larcenous mail threads.
Hi, Lately, I have been noticing repeatedly that sending mail to "Studying C as told. (For help)" results in mail being sent to "Re: [DNG] Studying C as told. (For help)". My repeated emails at the end of the latter are the result of my attempts to send main to the proper thread. Why is this happening? In my latest code submits to the thread, I presented a functional and efficient parser for Boolean expressions but I got no replies. I had my latest code evaluated by an experienced C coder who confirmed the code works and is efficient. The only correction was to test for the return value of malloc even though on today's systems RAM runs into Giga Bytes. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Following up on 'DE doesn't let user shutdown/reboot'. I wrote: > I've heard of some DE glue not working if you lack PolKit and/or upower > _by default_, but can't remember details. It was something like XFCE4's > shutdown graphical controls didn't work until you retofit optional > package blahblahblah. > > And my recollection is that you can find the 'retrofit optional package > blahblahblah' tip in every case I've observed that to be findable in > five minutes of Web-searching. So, for example: http://www.spencerstirling.com/computergeek/shutdown.html Covers KDE and XFCE4, plus shows how to create shell script '/usr/bin/reboot' (should be /usr/local/bin/reboot) and make all members of new system group 'shutdown' able to run it. Specifically for XFCE4, the key bit is (a) adding users permitted to shutdown/reboot the machine to /etc/xfce4/shutdown.allow, and (b) add a passwordless entry in /etc/sudoers for system group shutdown permitted to run XFCE app xfsm-shutdown-helper. This un-greys 'Reboot computer' / 'Turn off computer' on XFCE4's menus, that otherwise would be disabled if you lack the PolKit lobotomy. Where xfsm-shutdown-helper is located is distro-specific. E.g., on Debian it's /usr/lib/[$ARCH]/xfce4/session/xfsm-shutdown-helper, on CentOS/RHEL/Fedora /usr/libexec/xfsm-shutdown-helper, etc. > Personally, if a DE or WM gave me more than five minutes of trouble in > this area, I'd just fall back on the workaround that's sufficed since > dinosaur days: > > $ su - > $ shutdown -h now On reflection, I'd do it the lazy way: 1. Ctrl-Alt-F2 (switch to text console) 2. Ctrl-Alt-Del (initiate reboot). 3. Shut off computer at end of shutdown, before boot. ;-> A dock application for Window Maker called wmshutdown exists, but I personally don't bother with it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Need for documentation
Hi all, When installing, you get to pick which window manager you want. Trouble is, there's no obvious way to change your window manager after the fact. Somebody needs to document how to do this, and keep the document in an obvious place, with a link from the top of our documentation tree. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan dmenu docs complete
Hi all, I just added the dmenu hotkey instructions for Xfce and Openbox to the existing instructions for LXDE. The document's now useable to the majority of Devuan users (I think). SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Steve Litt (sl...@troubleshooters.com): > The only problem comes in when you express the opinion (and fair > enough, you state it's your opinion) that forking Debian was whichever expression you want>, without adding the vital words "for my > use case." Had you added those four words, there would be no problem. I wouldn't have said that, because I don't think it's factually accurate. I've detailed at length (primarily on the SVLUG mailing list thread) how Debian-variant communities Siduction and Aptosid each successfully maintain a policy-constrained variant of Debian-unstable. (The former live CD desktop distro is a schism of the latter, so they're very similar.) I've described how they do it. I merely expressed my offhand opinion that that _sort_ of method would be a less-difficult way to enforce a no-systemd policy for a Debian-variant community. (I marked that as an offhand opinion with phrases like 'As far as I can see...'.) I could be mistaken, in holding that offhand opinion. But it is not an offence to anyone for me to hold it. And I'm not the one who sought to wave that in the faces of the Dng mailing list, either. You are. Because, I rather suspect, you wanted to engineer a confrontation between me and the Devuan Project. Unfortunately, this doesn't work because I am a fan of that project. > For my use case, Devuan's a good thing. Nothing I said, on the SVLUG list or elsewhere, would suggest it isn't. You seem to be having a logic problem: Saying a project did something you think to be not strictly necessary and that less-arduous measures would, as far as you can see, have sufficed is not an attack on that project. It's not like I said the project in question has has a millionaire-businessman Benevolent Dictator for Life, and is in the community-overriding stranglehold grip of a for-profit corporation headquartered in the Isle of Man for tax-dodging purposes because the millionaire-businessman founder/owner is a tight-ass manipulator of gullible volunteers, who goes around poor-mouthing the Linux community and attempts to special-plead and con the for-profit corporation's way into proprietary favours usable for proprietary-software side-deals like an infamous so-called Contributor Licence Agreements that is actually a legal handover of copyright ownership under a deceptive name. ...which I _did_ say in the same discussion about a different distribution project, known to many because of its relently PR. _That_ might be legitimately seen an an attack on that distribution project. And also true. ;-> > Why don't you just admit that for the ex-Debian person who liked Debian > until the systemd thing, but now no longer trusts Debian, Devuan fits > their use case well. 1. I haven't yet had occasion to use Devuan. 2. I see no reason to switch topics to whether ex-Debian people ought to be happy with whatever-else-they-use-now, which is simply not what I was writing about. 3. In any event, I also reject your fundamental premise that I or other people who rely on Debian-packaged software are necessarily 'trusting Debian' (by which you mean the Debian Project). The Debian Project can kiss my Scandinavian ass. I don't trust _it_, don't endorse its erroneous decisions, don't think highly of its bumbling politics (where they cannot even debate the correct issue, which _should_ have been whether they're willing to be lead into dumb decisions by GNOME), and don't have any inherent respect for the views of its ~1000 package maintainers. Trusting the Debian Project is not in this picture. I have nothing to do with the Debian Project. What I do is administer systems that in most cases use selected Debian packages, with application of my system administration judgement and in accordance with my local policies. I had already drawn for you the distinction between the Debian Project as a bureaucratic entity (what you erroneously called a 'vendor') and Debian as a malleable system architecture that is blessedly in the hands of its users and is thus, in part, me. It seems likely that none of that sunk in, because you keep talking about 'trusting Debian' (the bureaucratic entity), when that was not under discussion, and I specifically do _not_ do that. This is a poor use of your time, and mine. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, 13 Jul 2016 11:14:18 -0700 Rick Moen wrote: > Hullo, I'm the rat bastard who wrote > http://linuxmafia.com/faq/Debian/openrc-conversion.html and is thus > either ignorant or a very sadistic systemd hooligan. See here's the thing. There's nothing wrong with http://linuxmafia.com/faq/Debian/openrc-conversion.html . I wish I had discovered/created that recipe before writing Manjaro Experiments. Tech information is all good, and that's some excellent tech information. The only problem comes in when you express the opinion (and fair enough, you state it's your opinion) that forking Debian was , without adding the vital words "for my use case." Had you added those four words, there would be no problem. For my use case, Devuan's a good thing. I like having an easy to install Linux with apt-get, but because I don't trust the Devuan project as far as I can throw my house, I refuse to depend on Debian, at least in the long run. Devuan's a sans-systemd Debian fork fitting my use case very well, and not fitting your use case especially well. Why don't you just admit that for the ex-Debian person who liked Debian until the systemd thing, but now no longer trusts Debian, Devuan fits their use case well. I'm not asking *you* to use Devuan, or recommend Devuan to your friends, or contribute to Devuan. Just admit that for former Debian users who no longer trust Debian, and don't want to keep undoing what Debian does in perpetuity, Devuan fits their use case. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Steve Litt (sl...@troubleshooters.com): > In lieu of the apology I'll post links to the emails from which I took > those quotes, so all interested can see their context in the email and > in the thread: Absolutely. I would really appreciate everyone seeing the full context and noting the cheap and shoddy attempt at calling me dishonest through selective quotation, followed by refusal to apologise for your misrepresentation when called on it. That would please me very much. I have many decades' experience saying exactly the same thing _very_ bluntly to people, and the same thing directly that I say in their absence, like the Viking-descendant I am. I will doubtless continue to suffer said lamentable character defect of extreme plain-spokenness for the rest of my life, too. Publiser og bli fordømt. (That's not the way the language the Duke of Wellington spoke the sentiment in, but I think it would make a fine Scandinavian motto in translation.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, 13 Jul 2016 16:05:44 -0700 Rick Moen wrote: > Quoting Steve Litt (sl...@troubleshooters.com): > > > Deeeude, that's not what you're saying over on SVLUG. I quote: > > > > * Far as I can tell, Devuan was a operatic overreaction, and by no > > means the most efficient way to deal with the problem. > > > > * "Nor did it merit a fork, IMO." > > > > * "The whole forking thing seemed like gratuitous drama, really. > > Just my opinion." > > This doesn't contradict what I said, in any way -- and, for some > reason, you are choosing not to quote the bits where I _specifically > said_ on the SVLUG list that I think Devuan's work is valuable and > that I appreciate it (which I also said in my Web page). > > Moreover, Jaromir has known me as a fan of Devuan for a lot longer > than you've been in contact with me. > > I would accordingly appreciate your prompt and full public apology. In lieu of the apology I'll post links to the emails from which I took those quotes, so all interested can see their context in the email and in the thread: http://lists.svlug.org/archives/svlug/2016-July/062102.html : Rick's quotes about gratuitous drama and lack of merit http://lists.svlug.org/archives/svlug/2016-July/062085.html : Rick's quote about Devuan being an "Operatic overreaction" Anyone interested in the thread as a whole can sort by subject or thread. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd discussion on the Samba mailing list
On Wed, 13 Jul 2016 22:59:40 +0100 Simon Hobson wrote: > Jaromil wrote: > There's also been a short thread on the MythTV mailing list about how > to get the MythTV Frontend to only start after there's a working > network. It started with a user reporting that after upgrading his > MythBuntu install the Frontend would sometimes start properly and > sometimes start into the setup screen (which is what it does if it > can't find the backend) - with no apparent pattern as to when it does > or doesn't work. Of course, the upgrade put SystemD on the machine. > > The fun part ? For some reason that must have made sense to someone, > networking is only started when the user logs into the desktop. WTF ? > So the suggested fix is to disable the network manager and manually > configure the network via /etc/network/interfaces. I'm glad I wasn't drinking water when I read this, or there'd be water all over my keyboard and monitor. Yeah, by all means, wait til the user logs into the GUI to start the network. Geez, why couldn't *I* have thought of that. On a more serious note, this all plays into what I said last month about Red Hat's failure to complete their takeover. I'm sure their business plan called for all of Linuxdom to be happily working with systemd by 7/2016, so they could start the next phase of their monopolization. But as it stands, they're still having to put out fires all over the place: A --without-systemd here, Devuan there, extreme anger every time anyone on any list has problems with systemd. How much did they budget for this takeover, and how much more are they willing to risk? Could it be that, just like Microsoft before them, they'll run out of money trying to fight a community that needs no money to code, or to remove their booby traps? I think Red Hat lives in interesting times. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Steve Litt (sl...@troubleshooters.com):
> Deeeude, that's not what you're saying over on SVLUG. I quote:
>
> * Far as I can tell, Devuan was a operatic overreaction, and by no means
> the most efficient way to deal with the problem.
>
> * "Nor did it merit a fork, IMO."
>
> * "The whole forking thing seemed like gratuitous drama, really. Just
> my opinion."
This doesn't contradict what I said, in any way -- and, for some reason,
you are choosing not to quote the bits where I _specifically said_ on
the SVLUG list that I think Devuan's work is valuable and that I
appreciate it (which I also said in my Web page).
Moreover, Jaromir has known me as a fan of Devuan for a lot longer than
you've been in contact with me.
I would accordingly appreciate your prompt and full public apology.
> You'd be amazed at the number of people who mock Devuan, who are angry
> at Devuan, who say bad things about Devuan.
This drama has nothing to do with me.
> You've said a number of times that forking isn't necessary because you
> can do your Debian package manager-foo.
That is not what I said.
> In fact, the outcome of Ian Jackson's GR enforces their right to such
> sabotage.
That is not an accurate representation of the GR outcome, which I
already wasted time explaining to you. (As a reminder, I have no
connection to the Debian Project. I am just a system administrator who
uses some of its stuff, and is sometimes obliged to take measures to
reverse some of its policies and practices.)
> Although all forks ruffle feathers a little bit
{shrug} No concern of mine.
I've been explaining to people the essential role of forking in open
source since at least that 1999 essay that Slashdot picked up.
http://linuxmafia.com/faq/Licensing_and_Law/forking.html
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting KatolaZ (kato...@freaknet.org):
> Wait :) First of all, I might have been unclear in the previous email,
> but I really appreciate your work, and that of others who are making
> an effort to contain systemd. So there is no reason to start a fight:
> that's not my intention at all, and would be counterproductive and
> useless beyound measure :)
Sorry about any misunderstanding.
> I might be mistaken on this, but my understanding is that already in
> the current Jessie if you don't have systemd and polkit installed you
> can't shutdown your system from GNOME, and from other WMs and DMs, for
> that matter.
That has not been my experience with Window Maker.
I've heard of some DE glue not working if you lack PolKit and/or upower
_by default_, but can't remember details. It was something like XFCE4's
shutdown graphical controls didn't work until you retofit optional
package blahblahblah.
And my recollection is that you can find the 'retrofit optional package
blahblahblah' tip in every case I've observed that to be findable in
five minutes of Web-searching.
Personally, if a DE or WM gave me more than five minutes of trouble in
this area, I'd just fall back on the workaround that's sufficed since
dinosaur days:
$ su -
$ shutdown -h now
> I don't use GNOME, and I never shutdown or reboot my machines unless a
> cataclysm has struck, so I could safely ignore the problem, but I know
> that pinning systemd does not solve it. It just "contains" the
> avalanche, in some cases, and postpones the search for a solution to
> an undetermined point in the future, but does not *solve* the problem.
Everyone keeps telling me that the Poettering Horsemen of the Apocalpse
are producing thundering hoofbeats just around the corner, and they keep
not coming around the corner. Some day, this could change, but there's
sure a long history of it not doing so, and (in my experience)
commenters keep ignoring modest fixes.
> Good. Nice. Perfect. I care about a solution that goes beyond my needs
> of today, while that is not your first priority. I think we can safely
> disagree on this point and continue :)
Works for me.
I might care about 'a viable long-term solution for the Linux
community'. I might care deeply.
I'm an old-school Linux system administrator who long ago got wary of
sweeping rhetorical claims, and prefers to discuss specific things where
possible, and to be careful about definitions/meanings when not.
> I am pretty sure I have never raised any critique to your work. I have
> just stressed that I *believe* that, given the current attitude of
> systemd & co., that consists into eating as much as they can of almost
> anything in the low-level userspace, breaking things in the process
> without saying "sorry", there is probably not much time left until
> everything down there will depend on systemd.
I am not at all convinced of this.
However, I'm quite certain that such eventualities would immediately
inspire creation and publication of even more alternate packagings and
repos of same, to sidestep that and fix that (hypothetical) step.
I am, speaking for myself, an example of a Debian-using system
administrator who became aware that, through laziness and inattention,
I'd stood by and let some pieces of questionable software enter my
systems, starting with udev. I'd already started to (belatedly)
question the necessity, and to ensure that upower, udisks2, PolKit,
packagekit, and the rest of the Freedesktop.org CADT bugpile did not get
pulled into my systems via dependency chains. I have tended to mostly
stop with Works for Me[tm] corrective measures. If there were a bigger
intrusion problem, I would take stronger measures. (My page hints at
the general shape those would probably take.)
> Hence, pinning is not, IMHO, a viable long-term solution.
This does not follow logically from your premises. However, {sigh} also
I did not _say_ package-pinning is a viable long-term solution (to
anything in particular).
What I said was 'Hey, I tried, this, it works for these [cited]
use-cases.' And then I said 'Third-party repos with package preferences
are an already-proven way to perpetuate a Debian-variant community,
imposing an external policy on it. I see no reason this could not
be used with a no-systemd policy.'
And I said a lot more, such as (when challeged by Mr. Steve Litt about
my opinion that Devuan was an overreaction) outlining general methods of
maintaining Debian-variant communities that are already proven and in
use.
> See above. I genuinely appreciate your effort, which is scientific and
> sound, and I know that *so far* it is still possible to find
> appropriate workarounds around systemd, remaining in Debian and
> accepting a few compromises.
I just don't see those as compromises.
There's not a single package in the list of problem packages on
http://linuxmafia.com/faq/Debian/openrc-conversion.html that I care
about.
NetworkManager? GNOME crud.
gdm3? GNOME crud.
nautilus
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, 13 Jul 2016 11:14:18 -0700 Rick Moen wrote: > Hullo, I'm the rat bastard who wrote > http://linuxmafia.com/faq/Debian/openrc-conversion.html and is thus > either ignorant or a very sadistic systemd hooligan. > > Hi, Jaromil! You and I have corresponded in e-mail, and you'll recall > that I like Devuan, appreciate its work, and follow it with interest. Deeeude, that's not what you're saying over on SVLUG. I quote: * Far as I can tell, Devuan was a operatic overreaction, and by no means the most efficient way to deal with the problem. * "Nor did it merit a fork, IMO." * "The whole forking thing seemed like gratuitous drama, really. Just my opinion." [snip] > On the other hand, I have absolutely no problem with your deciding to > fork the distribution instead, and appreciate your work. Which is all I expect. Heck, the appreciation isn't even necessary. Although I speak for myself here, I suspect there may be others on this list who see it the same way. You'd be amazed at the number of people who mock Devuan, who are angry at Devuan, who say bad things about Devuan. On a broader scale, whatever means a person chooses to use a PID1 that's not systemd is mocked and draws angry reactions from the Debianistas and systemd enthusiasts. You've said a number of times that forking isn't necessary because you can do your Debian package manager-foo. I've responded every time that I just don't trust Debian not to sabotage continuing ability to do that, either out of malice or ignorance or laziness. In fact, the outcome of Ian Jackson's GR enforces their right to such sabotage. And also, there are people, like me, who don't want to play whack-a-mole undoing all the stuff systemd-entanglement as Debian puts it in. Hence the fork. As I mentioned on SVLUG, Devuan is a special case. Although all forks ruffle feathers a little bit, no fork I've heard of comes close to the level of anger that the Debianistas and systemd-enthusiasts heap on Devuan. Which reminds me of this little quote from a great person: "First they ignore you, then they laugh at you, then they fight you, then you win." Which in turn makes me think of another little quote from another great person: "Don't Panic and Keep Forking Debian" SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd discussion on the Samba mailing list
Jaromil wrote: >> Hi, over on the Samba mailing list, somebody asked what '--with-systemd' was >> for. It has now degenerated into a discussion on how to get systemd to start >> the 'samba' deamon, There's also been a short thread on the MythTV mailing list about how to get the MythTV Frontend to only start after there's a working network. It started with a user reporting that after upgrading his MythBuntu install the Frontend would sometimes start properly and sometimes start into the setup screen (which is what it does if it can't find the backend) - with no apparent pattern as to when it does or doesn't work. Of course, the upgrade put SystemD on the machine. The fun part ? For some reason that must have made sense to someone, networking is only started when the user logs into the desktop. WTF ? So the suggested fix is to disable the network manager and manually configure the network via /etc/network/interfaces. > said by a Samba developer , this is priceless > > """ > You have your opinion and I have mine and my opinion (for what it is > worth) is that systemd is something that is looking for a problem that > doesn't really exist and then fixing the problem in a totally insane > way. If systemd was just another init system and was easy to change then > I wouldn't mind, but it keeps gobbling up things that have nothing to do > with an init system and is becoming extremely hard to remove. > > As far as I am concerned, this ends this conversation, you have my > opinion and nothing will change it, so don't bother trying. > """ Yes, a brilliant response > besides, people at Samba are very good and well seasoned coders. They > haven't only managed to reverse-engineer a closed protocol and make an > open source daemon which is massively used and works across all major > operating systems. Some of them are also responsible for developing > rsync, which is... well before it existed the world was different. > > I have massive respect for them and I'm not surprised someone among > them has such an opinion of systemd. +1 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, Jul 13, 2016 at 01:56:02PM -0700, Rick Moen wrote:
[cut]
Wait :) First of all, I might have been unclear in the previous email,
but I really appreciate your work, and that of others who are making
an effort to contain systemd. So there is no reason to start a fight:
that's not my intention at all, and would be counterproductive and
useless beyound measure :)
Second, sorry but I just replied to some of your points (which were
too many :)). I hope I have not forgotten anything important for the
discussion.
>
> What you call 'a minimal window manager and xterm', I see as absolutely
> free access to around 20,000 packages including the richest variety of
> graphical desktop applications on the planet including (if I cared)
> about a dozen graphical file-managers.
>
I was referring to what *I* need, namely a minimal window manager
(that also in my case is Window Maker, you see, we agree on much more
than it looks at a first sight...) and a terminal.
I might be mistaken on this, but my understanding is that already in
the current Jessie if you don't have systemd and polkit installed you
can't shutdown your system from GNOME, and from other WMs and DMs, for
that matter. I don't use GNOME, and I never shutdown or reboot my
machines unless a cataclysm has struck, so I could safely ignore the
problem, but I know that pinning systemd does not solve it. It just
"contains" the avalanche, in some cases, and postpones the search for
a solution to an undetermined point in the future, but does not
*solve* the problem.
[cut]
>
> You say that is not 'a viable long-term solution for the Linux
> community'? Fine, OK, whatever in Gehenna that means. But that wasn't
> what I set out to do. I set out to scratch my own itch and then to give
> correct, useful information to anyone with a use-case similar to my own.
> Judging from feedback, some actually read the page with context and
> found it useful. Others _claim_ to have read the page with context and
> want to argue, but raise non-sequitur objections because they didn't pay
> attention.
Good. Nice. Perfect. I care about a solution that goes beyond my needs
of today, while that is not your first priority. I think we can safely
disagree on this point and continue :)
>
> And of course, there are probably errors on that page. But erroneous
> critiques and vague ideological appeals won't find them.
>
I am pretty sure I have never raised any critique to your work. I have
just stressed that I *believe* that, given the current attitude of
systemd & co., that consists into eating as much as they can of almost
anything in the low-level userspace, breaking things in the process
without saying "sorry", there is probably not much time left until
everything down there will depend on systemd. Hence, pinning is not,
IMHO, a viable long-term solution. And yes, I am very interested in a
viable long-term solution, for my personal, egoistic reasons.
[cut]
> > That's why, although I appreciate efforts like yours and those of a
> > dozen more who have been experimenting with pinning (we have done that
> > as well, for months), I remain convinced that maintaining a
> > systemd-free fork of a distributition, and of a fundamental one like
> > Debian, is a more sustainable way of dealing with the problem. It's
> > not easy, but nothing is easy :)
>
> I agree -- of course -- than nothing is devoid of difficulties.
>
> All I said was that, as far as I can see, lesser measures than forking
> the distribution, with less effort, would have sufficed to enforce a
> no-system policy on Debian-stable indefinitely. My small experiment was
> a de-minimus effort without bothering to have a third-party repo of
> packages (daisy-player, etc.) recompiled and repackaged without the
> --with-system build option or other corrective steps. My speculation is
> that such a repo would be very feasible and a successful way to
> perpetuate a no-system Debian-variant community -- and as an example of
> communities doing exactly that for other enforced policies applied to
> Debian, cited (on the SVLUG mailing list) the Siduction and Aptosid
> Debian-variant communities, successfully maintained for many years by
> just a few developers as a variant on Debian-unstable, using nothing
> more than third-party repos and package preferences ('pinning').
>
See above. I genuinely appreciate your effort, which is scientific and
sound, and I know that *so far* it is still possible to find
appropriate workarounds around systemd, remaining in Debian and
accepting a few compromises.
But I know that two years ago we had a very nice brand-new toy, which
was working perfectly, and for which such workarounds were not needed.
So I don't want to give up, go down with a lot of duct tape and just
"let it go". Duct tape is a wonderful and perfectly sensible temporary
solution. It might even be a long-lasting and reliable temporary
solution. But remains a temporary solution.
You are optimistic, and think that a
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting KatolaZ (kato...@freaknet.org): > I personally don't see the reason for such a reaction on your side > Rick (BTW, welcome here :)), but I am sure I am missing something. I > personally believe that all the work to avoid and contain systemd and > other nonsense is valuable, independently of where it comes from :) I cannot imagine why you would ever think I don't agree! I can only guess that you didn't bother to attentively read what I said -- because I think Devuan's work is valuable and have already said so on my OpenRC conversion page, on the referenced SVLUG mailing list thread, and on this mailing list. When you try to pick a fight with someone who admires what you're doing, just because he doesn't agree with you on every single particular, and _particularly_ when you attribute to him views he doesn't hold and whose opposite he just expressed, maybe you should relax a bit and consider switching to decaf. ;-> > It is true that the pinning game can actually work for you or for me, > who are content with a minimal window manager and xterm I do not call window managers 'minimal'. FWIW, I personally like Window Maker, in part because it's designed in imitation of NeXTStep's aesthetics and design, and I was a big fan of NeXTStep back in proprietary Unix days. Moreover, althrough I have no personal use for the graphtical file-manager applications that are the characteristic feature of DEs, all of them, Thunar, Nautilus, etc., my survey of all Debian 8 'Jessie' packages using apt-caache found _no_ packaged graphical file-manager app to suffer systemd dependency as presently packaged, not even GNOME's. Moreover, if my testing was correct, six DE metapackages (tasks, IIRC) can be installed in their entirety in Debian 8 'Jessie', and all five of the others can be installed almost complete, excepting a couple of apps packaged with a dependency chain to systemd. GNOME, MATE, and Cinnamon are (naturally) the worst-affected DE metapackages. What you call 'a minimal window manager and xterm', I see as absolutely free access to around 20,000 packages including the richest variety of graphical desktop applications on the planet including (if I cared) about a dozen graphical file-managers. Even though I've always thought DEs are bullshit, my results suggest that a systemd-free Debian 8 'Jessie' system can, with no other measures, have access to just about everying in all eleven packaged DEs, and literally the entirety of six of those eleven. You call that 'minimal'? Seriously? Some minimal! > ...but this is not a viable long-term solution for the Linux > community. First of all, your term 'solution for the Linux community' is suspiciously vague and undefined. Second, even if it were defined, I have little confidence that I would care. It sounds suspiciously like a figurative football to kick around for polemical purposes. I'm suddenly reminded of any number of time-wasting threads on comp.os.*.advocacy. Third, I said nothing on my Web page, the SVLUG mailing list thread, this mailing list, or anywhere else about providing (or seeking) a 'viable long-term solution for the Linux community' or doing anything else other than investigating and documenting what happens on Debian 8 'Jessie' when one replaces systemd with a different init system, enforces a no-systemd package policy using apt thereafter, and observes what can and cannot be installed from regular packages. FWIW, I found the few problems resulting to be trivial and orders of magnitude less numerous than _both_ anti-systemd and pro-systemd people had confidently predicted. Additionally, I outlined all the methods I know to work around package dependency problems that I'm aware of on deb-based architectures -- in case someone actually cares, e.g., about daisy-player on Debian-stable. _And_, I carefully qualified what I said about use-cases that this approach could address only with some difficulties. Finally, I added my page to the links on http://without-system.org/ , pro bono publico. You're welcome. You say that is not 'a viable long-term solution for the Linux community'? Fine, OK, whatever in Gehenna that means. But that wasn't what I set out to do. I set out to scratch my own itch and then to give correct, useful information to anyone with a use-case similar to my own. Judging from feedback, some actually read the page with context and found it useful. Others _claim_ to have read the page with context and want to argue, but raise non-sequitur objections because they didn't pay attention. And of course, there are probably errors on that page. But erroneous critiques and vague ideological appeals won't find them. > Maybe those are still good solutions in some speficic cases, who might > allow single individuals to continue their computing as "normal", but > IMHO pinning won't work forever... You might be correct, but why not? > ...for the same reason why in just two years you already have several > dozens
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/13/2016 09:20 PM, KatolaZ wrote: That's why, although I appreciate efforts like yours and those of a dozen more who have been experimenting with pinning (we have done that as well, for months) Can you explain what is the *essential difference* between Pin-Priority: -1 for systemd packages in /etc/apt/preferences and ... banpkgs: systemd,systemd-sysv ... part of amprolla.conf ? Thanks in advance :) Dragan https://foss.rs/threads/trios-mia-openrc-zfs.3057 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, Jul 13, 2016 at 11:14:18AM -0700, Rick Moen wrote: > Hullo, I'm the rat bastard who wrote > http://linuxmafia.com/faq/Debian/openrc-conversion.html and is thus > either ignorant or a very sadistic systemd hooligan. > > Hi, Jaromil! You and I have corresponded in e-mail, and you'll recall > that I like Devuan, appreciate its work, and follow it with interest. > Normally, I follow dng (intermittently) only via its Web archive, > because I don't really have time for more mailing lists, but I'll be on > here for at least present discussion for a while. > [cut] I personally don't see the reason for such a reaction on your side Rick (BTW, welcome here :)), but I am sure I am missing something. I personally believe that all the work to avoid and contain systemd and other nonsense is valuable, independently of where it comes from :) It is true that the pinning game can actually work for you or for me, who are content with a minimal window manager and xterm, but this is not a viable long-term solution for the Linux community. For that matter, most of us could have simply solved the systemd-problem two years ago by playing the pin game for a while and then switching to (or in some cases, just remaining with) *BSD. Maybe those are still good solutions in some speficic cases, who might allow single individuals to continue their computing as "normal", but IMHO pinning won't work forever, for the same reason why in just two years you already have several dozens basic packages depending in a way or another on systemd. That's why, although I appreciate efforts like yours and those of a dozen more who have been experimenting with pinning (we have done that as well, for months), I remain convinced that maintaining a systemd-free fork of a distributition, and of a fundamental one like Debian, is a more sustainable way of dealing with the problem. It's not easy, but nothing is easy :) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Jaromil (jaro...@dyne.org): > yes I recall your help facing that meshuggah guy aggressing me and the > whole drama and the wikipedia cancelation and all that at the > beginning of Devuan. and I really appreciated your words of > encouragement, advice and experience :^) You are entirely welcome. > Now I must admit having commented on the thread without even reading > the page. But on the pinning plan solidity we've done our homework > and together with Nextime at the very beginning of this adventure and > with the help of other VUAs we understood we cannot rely on the long > term on this solution. It's entirely possible that I've missed something -- and, of course, also there are many _other_ use-cases people care about with Linux distributions, that I do not. I have even been known to concede that people who like GNOME are human and it might be nice to help them. ;-> There are good reasons for Devuan. There might have been compelling reasons for its particular implementation, that haven't yet occurred to me. (When all is said and done, I'm just an easily confused sysadmin who hasn't yet had his coffee. ;-> ) There might even be dire and insidious consequences to the presence on one's server-role host of libsystemd0. If good solutions to making it go away (and I _would_ like it to go away), those solutions are more likely to come from the Devuan project than anywhere else. > I have no time now to recall all the analysis :^( plus for other > reasons I'm typing approx 2000 words per day and its becoming sort of > taxing on my hands. I deeply sympathise -- and you're doing good work that I don't wish to distract you from. > But you did well following your own path and I personally applaud all > efforts going into the direction of liberating us from all the systemd > nonsense that has been going down in the past years. Thank you indeed. > so my proposal, since we have two approaches and a gentlemen > disagreement which can only be proven in the future, is that we wait > until August, give me time to look better into your documentation, > with the intention to take up your bet. Then we can agree on a > reformulation. Approximately, it should be about running a production > system with pinning, updating it through the life of Jessie and see if > it holds the few services we agree it should run. For something like > that, I am ready to place 1 BTC starting from 1:1 odds, that the > system will not resist the updates and break (aka want to install > systemd) before Debian 9. However lets nail down the details later if > you want, this can be a funny bet :^) Seems feasible, and I'm more than glad to state that you may be completely justified in such a bet. For completeness, I'll mention that, if a Debian 8 'Jessie' or Debian 9 'Stretch' system does end up suffering packager-caused intrusion of systemd into important packages (for some value of 'important' ;-> ), then I can confidently predict that alternative packages in third-party repos will become wildly popular among Debian admins. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
dear Rick, yes I recall your help facing that meshuggah guy aggressing me and the whole drama and the wikipedia cancelation and all that at the beginning of Devuan. and I really appreciated your words of encouragement, advice and experience :^) Now I must admit having commented on the thread without even reading the page. But on the pinning plan solidity we've done our homework and together with Nextime at the very beginning of this adventure and with the help of other VUAs we understood we cannot rely on the long term on this solution. I have no time now to recall all the analysis :^( plus for other reasons I'm typing approx 2000 words per day and its becoming sort of taxing on my hands. But you did well following your own path and I personally applaud all efforts going into the direction of liberating us from all the systemd nonsense that has been going down in the past years. so my proposal, since we have two approaches and a gentlemen disagreement which can only be proven in the future, is that we wait until August, give me time to look better into your documentation, with the intention to take up your bet. Then we can agree on a reformulation. Approximately, it should be about running a production system with pinning, updating it through the life of Jessie and see if it holds the few services we agree it should run. For something like that, I am ready to place 1 BTC starting from 1:1 odds, that the system will not resist the updates and break (aka want to install systemd) before Debian 9. However lets nail down the details later if you want, this can be a funny bet :^) ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Apologies for broken threading, but I'm responding to selected recent comments from the Web archive, having just subscribed. Edward Bartolo wrote: > If my memory serves me right, Debian have removed apt pinning... Happily, I can report that this is not the case, from direct investigation on the stable branch. (I greatly doubt that is the case in tip versions of apt, either, or on testing/unstable.) > ...and they see nothing wrong in making more packages depend on systemd. I will be keeping an eye on this, FWIW. -- Cheers, QA engineer walks into a bar. Orders a beer. Rick MoenOrders 0 beers. Orders 9 beers. Orders r...@linuxmafia.com a lizard. Orders -1 beers. Orders a sfdeljknesv. McQ! (4x80) -- @sempf, https://www.sempf.net/post/On-Testing1.aspx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Why Debian 8 Pinning is (or isn't) pointless
Hullo, I'm the rat bastard who wrote http://linuxmafia.com/faq/Debian/openrc-conversion.html and is thus either ignorant or a very sadistic systemd hooligan. Hi, Jaromil! You and I have corresponded in e-mail, and you'll recall that I like Devuan, appreciate its work, and follow it with interest. Normally, I follow dng (intermittently) only via its Web archive, because I don't really have time for more mailing lists, but I'll be on here for at least present discussion for a while. > Someone on the linked thread made a lot of arguments about how > Devuan was "an operative overreaction" in response to Systemd; Operatic, not operative. Far as I can tell, Devuan was a operatic overreaction, and by no means the most efficient way to deal with the problem. Yet, (1) their repos are compatible, so their work effectively _does_ supplement and assist Debian, and (2) again, it's their spare time to use as they please, when all is said and done. Downthread, I gave examples of how the third-party repos of how Aptosid or Siduction, among others, successfully maintain Debian-variant distros enforcing their policies using third-party repos and package pinning, without a distribution fork. So, that not only can work, it does work. On the other hand, I have absolutely no problem with your deciding to fork the distribution instead, and appreciate your work. 'dev' wrote: > You can pin all you want, and force-remove all you want, but > one day there will be a package you need (let's pretend it's > linux-libc-dev-xxx.x.x) which will have the hinge-pin baked-in. You > can no longer update libc. Really? The GNU libc package is going to suffer a dependency chain that requires package systemd? Would you like to wager either US $100 or €100 that this is going to happen in Debian-stable by the end of 2017? I will offer you 1:10 odds against. This wager offer will be extended for two days from the timestamp of this posting, and is extended to you _specifically_. If you wish to accept, send mail on-list to do so, and mail offlist giving me meaningful identification data for yourself (as obviously I would not make such a money deal just with a pseudonym named 'dev'). > Obviously, some packages are already at that point and already > have dependencies baked into some of the fundamental linux packages > everyone runs on Linux. Which package is that? NetworkManager? I do not concur about NetworkManager being essential. ConnMan is significantly better IMO for example, and was never a dependency hairball. hplip? That would be a serious problem if you _actually_ could not install the HPLIP software, but that software is actually in packages printer-driver-hpcups and printer-driver-hpijs, which have everything you actually need. It's very annoying that Debian package 'hplip' is a dependency hairball with GNOME glue that resolves hplip -> policykit-1 -> libpam-systemd -> systemd. However, that packaging error doesn't prevent using HPLIP. (Page covers this in detail.) daisy-player? gdm3? gnome-core? Which package is a 'fundamental Linux package everyone runs on Linux'? I ask merely for clarity. I did a fair amount of work with apt-cache on a Debian 8 'Jessie' test system in writing up http://linuxmafia.com/faq/Debian/openrc-conversion.html to see which packages suffer dependency chains resolving to systemd. If I've missed any, please advise, and I'll fix the omission and gratefully credit whoever sends me the correction. If I haven't missed any, please advise about which of the listed packags are 'fundamental Linux packages everyone runs on Linux'. For the record, as a Linux user since 1993, I don't find any of the listed packags essential for my own use-cases. > Devuan *is* relevant because any systemd bloat which makes it's way into future packages can be delt with by the Devuan community. Strongly agree! And please note that I am very far from wishing to claim Devuan irrelevant. > I mention all this becuase I took the "deb 8" pinning challenge today > and it failed miserably. I'm sorry to hear that, but let's look at particulars. > Systemd is vendor lock-in and there is no other way to explain it when > "apache2-common" cannot be installed due to libsystemd0 dependency. Ah, _libsystemd0_. Thanks for the clarification. You were not talking about a dependency that resolves to package systemd, but rather one that resovles to package libsystemd0. Well, then, that clarifies things. We can now agree to disagree about an almost certainly functionally meaningless package dependency on libsystemd0 equating to a system being chained to system, and thus a qualifying example of 'the tentacular and insidious reach of systemd'. Quoting my page: A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems entirely harmless. I respect the developers behind Devuan, and know they have done & are doing a great deal more than just omitting s
Re: [DNG] Systemd discussion on the Samba mailing list
On Wed, 13 Jul 2016, Rowland Penny wrote: > Hi, over on the Samba mailing list, somebody asked what '--with-systemd' was > for. It has now degenerated into a discussion on how to get systemd to start > the 'samba' deamon, after approx 50 posts on the subject, the discussion is > still going on. > > I thought that they said systemd was better than init scripts :-D > > see here for the first post: > > https://lists.samba.org/archive/samba/2016-July/201066.html said by a Samba developer , this is priceless """ You have your opinion and I have mine and my opinion (for what it is worth) is that systemd is something that is looking for a problem that doesn't really exist and then fixing the problem in a totally insane way. If systemd was just another init system and was easy to change then I wouldn't mind, but it keeps gobbling up things that have nothing to do with an init system and is becoming extremely hard to remove. As far as I am concerned, this ends this conversation, you have my opinion and nothing will change it, so don't bother trying. """ completely agree, and more besides, people at Samba are very good and well seasoned coders. They haven't only managed to reverse-engineer a closed protocol and make an open source daemon which is massively used and works across all major operating systems. Some of them are also responsible for developing rsync, which is... well before it existed the world was different. I have massive respect for them and I'm not surprised someone among them has such an opinion of systemd. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Kali Linux 0003165]: Find a way to disable most services by default with systemd
On 07/13/2016 09:42 AM, KatolaZ wrote: > On Wed, Jul 13, 2016 at 02:51:21PM +0200, Jaromil wrote: > > [cut] > >> >> >> I believe Kali is a great resource, a lot of well thought >> purpose-driven work was put in it before giving up to fancy desktop >> nonsense and its roots are anyway in the idea of a minimalist sharp >> tool. some of its arm building scripts prove themselves already to be >> a great resource for our own arm-sdk. >> >> I really hope you or someone else can put together something similar >> but smaller and based on Devuan. it would be useful to many. >> > > I think it would definitely be easy to add a list of forensic-oriented > tools to the current package list of devuan minimal live. I am not > particularly interested in that, but I can provide help on the matter, > if needed. > > My2Cents > > KatolaZ > OK, I'll start. Here's a list of command-line utilities that I add to Refracta. I also usually include zenmap and wireshark, but I pulled one or both of those from the latest releases to save space. So what's missing that can easily be added from the Devuan and Debian repos? I usually have a minimal iso with these tools included, but the last ones needed to be de-dmo'd, so I pulled them and haven't replaced them. But give me a package list, and I could crank out a basic (mostly unconfigured) live iso in a short time (hours to days). That could be a starting point for someone else to make it better or modify it for their own use. (1. I don't want to maintain another distro. 2. Even a pile of manure can turn into a beautiful garden.) arpscan ethtool fdupes gddrescue hddtemp hdparm hexedit htop hwinfo \ iftop iptraf irssi lm-sensors lshw nictools-pci nmap partimage pciutils \ scrot sdparm smartmontools testdisk traceroute whois wipe -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Systemd discussion on the Samba mailing list
Hi, over on the Samba mailing list, somebody asked what '--with-systemd' was for. It has now degenerated into a discussion on how to get systemd to start the 'samba' deamon, after approx 50 posts on the subject, the discussion is still going on. I thought that they said systemd was better than init scripts :-D see here for the first post: https://lists.samba.org/archive/samba/2016-July/201066.html Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is pointless
On Wed, 13 Jul 2016, Simon Hobson wrote: > That brings me to something I've been meaning to ask for a while. Is > there anything practical I can do to help ? well, besites being one of many nice people that are part of this community :^) what comes to me in mind is the Distrowatch rating for Devuan which is pretty good, but doesn't have a sustained rate of visits. The DW rating is really a community pulse, works by counting the visits to a distro page from every unique IPs every day. So if you visit daily this page https://distrowatch.com/devuan and even set it as homepage on your computers, then this will definitely help us putting the word out about Devuan. We can always use more visibility and DW is an excellent avenue for that. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is pointless
Hi, If my memory serves me right, Debian have removed apt pinning and they see nothing wrong in making more packages depend on systemd. That is enough of an indicator to decide in favour of more choice. Long Life Choice. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is pointless
dev wrote: > I mention all this becuase I took the "deb 8" pinning challenge today > and it failed miserably. I tried something similar not long ago. It "almost" worked except that one component of Clamav that the server in question needs has a dependency on libsystemd0. The response from the Debian packaging team was "not helpful". > I have around 40 Ubuntu 12.04 LTS machines in production. They > all need to be upgraded before April of 2017 when security patches > become deprecated. I don't know if Devuan will be 1.0 stable by > then but completely understand the complexity of the task at hand > considering the tentacular and insidious reach of systemd. Our > current plan is to go to 14.04 LTS where there is hopefully a > minimum of systemd invasion, but any hope for a "Debian" pinning > solution is certainly lost. I've somewhat less systems than that, mostly Debian Wheezy - and I have much the same situation regarding "supported" status and updates. > Do not let BS comments like "an operative overreaction" discourage your > efforts. +1 Jaromil wrote: > However what I really wanted to say is that you can count on the fact > Devuan 1.0 will be out and stable well before April 2017. That's good to hear. > BTW If there is a company that can step up and support some of the > work being done with a sponsorship ... That brings me to something I've been meaning to ask for a while. Is there anything practical I can do to help ? I can't offer anything through work*, or reasonably anything using company resources - so I couldn't slip a server in without the bandwidth being noticed. And my technical skills aren't that great either, and outside of work I have very little spare time due to the "DIY stuff" I have on for the next year or two. When I get sorted (IT wise, at home), I might be able to offer some bandwidth from home (mirror ?) - I have a VDSL2 service with about 15Mbps outbound & unmetered. I realise I'm probably no different to anyone else - no time, no money :-( * I work in a very MS/Windows centric shop - the sort of place where no-one sees anything wrong with the "you upgrade when we tell you" approach in Windows 10, or the data slurping it has built in, or the "opaque black box" it offers to sysadmins. The GNU/Linus stuff I run is mostly the support stuff (routers, DNS, Mail, Monitoring) and a couple of web servers because they run PHP stuff (Wordpress) "easier" than Windows. And all running on hand me downs as the Windows guys have upgraded to more grunt to run their bloatware :-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is pointless
hi there, thanks for the post. Also many others here and among VUAs have tried the pinning before proceeding with the debianfork plan and spotted many limitations. Pinning cannot work for serious production and long-term use, this was our conclusion. In my eyes anyone saying that Devuan can be substituted by pinning is either an ignorant on the matter or a very sadistic systemd hooligan who like to denigrate even those who left in peace after a poisoned GR vote count. However what I really wanted to say is that you can count on the fact Devuan 1.0 will be out and stable well before April 2017. I believe most developers involved understand this as possible. We may ask more help and resources if the deadline approaches without progress, but I really doubt that. We are at a good point already, its just that we give to the *stable* word a way deeper meaning than what Debian does nowadays. Helas. BTW If there is a company that can step up and support some of the work being done with a sponsorship, between now and October would really be the good time for making an handshake. Currently standing plans are that we'll push for a release candidate in September, which will lead to more announcements and proper visibility for our sponsors. ciao On Wed, 13 Jul 2016, dev wrote: > I have around 40 Ubuntu 12.04 LTS machines in production. They > all need to be upgraded before April of 2017 when security patches > become deprecated. I don't know if Devuan will be 1.0 stable by > then but completely understand the complexity of the task at hand > considering the tentacular and insidious reach of systemd. Our > current plan is to go to 14.04 LTS where there is hopefully a > minimum of systemd invasion, but any hope for a "Debian" pinning > solution is certainly lost. > > As anxious as I am to install Devuan on everything, my users would > not understand the decision to run beta software in production > when/if something goes wrong. Here's hoping for a Devuan 1.0 sometime > soon and thanks go to those working hard to make > that happen. Do not let BS comments like "an operative overreaction" > discourage your efforts. > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- ~.,_ Denis Roio aka Jaromilhttp://Dyne.org think &do tank "+. CTO and co-founder free/open source developers @) ⚷ crypto κρυπτο крипто गुप्त् 加密 האנוסים المشفره @@) GnuPG: 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10 (@@@) opmsg:73a8e097a038d82b 8afb4c05804bda0d 281b3880fbc19b88 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Why Debian 8 Pinning is pointless
*sigh* apologies for the length. It was not what I intended.. tldr: "Go devuan! Debian 8 pinning does not work for me" I don't have the thread anymore, but there was something posted within the past couple days which led me to this link -- I think it was something Steve posted; something about a mailing list thread: http://linuxmafia.com/faq/Debian/openrc-conversion.html Someone on the linked thread made a lot of arguments about how Devuan was "an operative overreaction" in response to Systemd; about how the same thing could be done with Debian 8 and the apt pinning workaround. There are two reasons why this will never work, and the logistics behind those two reasons are what makes the work being done on Devuan all the more relevant: 1) Hacking up a distribution which has committed to a systemd hinge-pin is a nice way to find yourself in a headlock someday. You can pin all you want, and force-remove all you want, but one day there will be a package you need (let's pretend it's linux-libc-dev-xxx.x.x) which will have the hinge-pin baked-in. You can no longer update libc. By consequence, you can no longer update anything which depends on libc. Which is like everything. 2) Obviously, some packages are already at that point and already have dependencies baked into some of the fundamental linux packages everyone runs on Linux. Devuan *is* relevant because any systemd bloat which makes it's way into future packages can be delt with by the Devuan community. Which is the fundamental idea Linux was built on. The same fundamental idea which systemd adoption kills. Systemd is vendor lock-in and there is no other way to explain it when "apache2-common" cannot be installed due to libsystemd0 dependency. I mention all this becuase I took the "deb 8" pinning challenge today and it failed miserably. After following all the pinning directions, and removing all systemd related software, my deb 8 system boots fine on openrc, but I cannot use a2enmod as it requires apache2-common which requires libsystemd0. uh whut??... I put the console session on patsebin for brevity here: http://pastebin.com/raw/wZkuskuv I have around 40 Ubuntu 12.04 LTS machines in production. They all need to be upgraded before April of 2017 when security patches become deprecated. I don't know if Devuan will be 1.0 stable by then but completely understand the complexity of the task at hand considering the tentacular and insidious reach of systemd. Our current plan is to go to 14.04 LTS where there is hopefully a minimum of systemd invasion, but any hope for a "Debian" pinning solution is certainly lost. As anxious as I am to install Devuan on everything, my users would not understand the decision to run beta software in production when/if something goes wrong. Here's hoping for a Devuan 1.0 sometime soon and thanks go to those working hard to make that happen. Do not let BS comments like "an operative overreaction" discourage your efforts. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan docs for dmenu
Nice! Thank you.
Here's a simple script I wrote for launching programs in X (dmenu_run
is overkill IMO):
---
#!/usr/bin/env bash
# Terminal emulator program (st is suckless.org simple terminal)
terminal=st
# Array of programs we want in our menu
programs=(cmus
emacs
firefox-esr
geeqie
libreoffice
palemoon)
# Checks whether above programs are available in $PATH and sends a new
# list to dmenu; your selection will be saved in the $chosen_program
# variable
chosen_program=$(for program in "${programs[@]}"; do
[[ $(command -v $program) ]] || continue
echo "$program"
done | dmenu -i -b -l "${#programs[@]}")
# Run the program! cmus is a special case because it has no GUI
case "$chosen_program" in
cmus)
exec /bin/bash -c "${terminal} -e cmus" >/dev/null 2>&1
;;
*)
exec "$chosen_program" >/dev/null 2>&1
;;
esac
---
Hope it proves to be useful as reference.
Also, this thread is full of great ideas:
https://bbs.archlinux.org/viewtopic.php?id=80145
2016-07-12 21:36 GMT-04:00 Steve Litt :
> Hi all,
>
> As promised, I created a documentation page for using dmenu in Devuan:
>
> http://troubleshooters.com/linux/devuan_docs/devuan_dmenu.html
>
> I licensed it GPL2.
>
> Hope you like it, use it to best advantage.
>
> SteveT
>
> Steve Litt
> July 2016 featured book: Troubleshooting Techniques
> of the Successful Technologist
> http://www.troubleshooters.com/techniques
> ___
> 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] An amusing swipe at SystemD
http://forums.theregister.co.uk/forum/1/2016/07/13/automotive_grade_linux_version_/#c_2916902 In the comments to this article : http://www.theregister.co.uk/2016/07/13/automotive_grade_linux_version_/ > Pimp your ride with new Linux for cars and an rPi under the hood > Automotive Grade Linux vastly expands its hardware support list in version 2.0 > > The Automotive Grade Linux (AGL) project is about to unleash the second > version of its unified code base - snappily called UCB 2.0 - with expanded > hardware support. > > For the participating car-makers and hardware vendors it's a big deal. > > ... > > What will be exciting the project most, we suspect, is that this version > supports a lot more hardware than AGL supported in January 2016. > ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Kali Linux 0003165]: Find a way to disable most services by default with systemd
On Wed, Jul 13, 2016 at 02:51:21PM +0200, Jaromil wrote: [cut] > > > I believe Kali is a great resource, a lot of well thought > purpose-driven work was put in it before giving up to fancy desktop > nonsense and its roots are anyway in the idea of a minimalist sharp > tool. some of its arm building scripts prove themselves already to be > a great resource for our own arm-sdk. > > I really hope you or someone else can put together something similar > but smaller and based on Devuan. it would be useful to many. > I think it would definitely be easy to add a list of forensic-oriented tools to the current package list of devuan minimal live. I am not particularly interested in that, but I can provide help on the matter, if needed. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Kali Linux 0003165]: Find a way to disable most services by default with systemd
On Wed, 13 Jul 2016, dev wrote: > tasks. Why these devs do these things is beyond reason. the main reason is that they are lazy and cannot bother to work their way against the trend. you said it after all: they just curate collections of other people's software and often get more credit and donations for that, as some curators do in place of artists... and you missed to mention Tails by the way. They are overly advertised as the secure privacy distro to use, yet they have moved into systemd without posing even a question about it. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Kali Linux 0003165]: Find a way to disable most services by default with systemd
On 07/12/2016 06:07 PM, Simon Walter wrote: On 07/12/2016 08:45 PM, vmlinux wrote: don't need Kali. most network problems can be resolved with the basics anyway: arping, arp, tcpdump, nslookup, traceroute, netcat, and iptraf. thankfully all standard tools. Problems, yes sure. What about attacking your network AKA pen testing. Does Metasploit require something specific to Kali in order to run it? As far as I know, Kali is just a collection of tools on a convenient disk. Why they need to insist on a systemd based distro boggles my mind in the same way that systemd boggles my mind. It's senseless, pointless and overly complex. As long as I'm on a rant, the same goes for Security Onion. They have a collection of good IDS tools, but they insist on a desktop GUI to be installed along with all the senseless, pointless and overly complex packages that I would simply never install on a box performing security tasks. Why these devs do these things is beyond reason. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Kali Linux 0003165]: Find a way to disable most services by default with systemd
On Wed, 13 Jul 2016, fsmithred wrote: > On 07/13/2016 01:13 AM, Ozi Traveller wrote: > > I guess gnome is there default. However, they have instructions to > > allow the user to build a custom kali for themselves using > > live-build. > > http://docs.kali.org/development/live-build-a-custom-kali-iso > > > > Since Kali 2.0, we now support built in configurations for various > > desktop environments, including KDE, Gnome, E17, I3WM, LXDE, MATE > > and XFCE. > > > > http://git.kali.org/gitweb/?p=live-build-config.git;a=tree > > > > > > Oh, that's interesting. It looks like a lot of the extra packages > that aren't in the debian repos are available this way. I suppose it > would be possible to clone and modify the process to work with > devuan. I believe Kali is a great resource, a lot of well thought purpose-driven work was put in it before giving up to fancy desktop nonsense and its roots are anyway in the idea of a minimalist sharp tool. some of its arm building scripts prove themselves already to be a great resource for our own arm-sdk. I really hope you or someone else can put together something similar but smaller and based on Devuan. it would be useful to many. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Kali Linux 0003165]: Find a way to disable most services by default with systemd
On 07/13/2016 01:13 AM, Ozi Traveller wrote: > I guess gnome is there default. However, they have instructions to allow > the user to build a custom kali for themselves using live-build. > http://docs.kali.org/development/live-build-a-custom-kali-iso > > Since Kali 2.0, we now support built in configurations for various desktop > environments, including KDE, Gnome, E17, I3WM, LXDE, MATE and XFCE. > > http://git.kali.org/gitweb/?p=live-build-config.git;a=tree > > Oh, that's interesting. It looks like a lot of the extra packages that aren't in the debian repos are available this way. I suppose it would be possible to clone and modify the process to work with devuan. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
