You are not logged in.
Offline
Different take:
http://blog.halon.org.uk/2014/11/barbie … developer/
Last edited by johnraff (2014-11-21 08:55:55)
John
--------------------
( a boring Japan blog , Japan Links, idle twitterings and GitStuff )
#! forum moderator BunsenLabs
Offline
So anyway, it seems that there's been a vote among the Debian developers community (easily found via any internet search engine), and they've come to the conclusion that they don't need to come to a conclusion...and that this whole fracas has been for naught.
Works for most governments.
Point & Squirt
Offline
Ian Jackson resigns, as do Colin Watson and Russ Alberry, although twoion already told us about Russ Alberry.
Last edited by KrunchTime (2014-11-21 03:28:24)
Linux User #586672
Come and Die -- Kyle Idleman
Offline
^ Wow, a little shakin' goin' on.
"Let me explain something to you. Um, I am not "Mr. Lebowski". You're Mr. Lebowski. I'm the Dude. So that's what you call me. You know, that or, uh, His Dudeness, or uh, Duder, or El Duderino if you're not into the whole brevity thing."
The Dude.
Offline
Yeah, and the first link alludes to the fact that it probably isn't over.
Last edited by KrunchTime (2014-11-21 03:48:03)
Linux User #586672
Come and Die -- Kyle Idleman
Offline
Call for reflection:
http://www.eyrie.org/~eagle/journal/2014-11/003.html
and on anger vs abuse:
http://www.eyrie.org/~eagle/journal/2014-11/001.html
Last edited by johnraff (2014-11-21 09:01:08)
John
--------------------
( a boring Japan blog , Japan Links, idle twitterings and GitStuff )
#! forum moderator BunsenLabs
Offline
^Thank you for posting those John, I think they are a good read for everyone.
#! forum moderator - Please help us keep your forums manageable.
Offline
Can you demonstrate, in layman's terms, how systemd is unfit for use in "sensitive environments"?
When writing 'sensitive' here I was thinking of 'not applicable/not ready for deployment in a specific system environment'.
For example, a great issue with systemd in Debian or elsewhere is not systemd per se but the transition. In-place upgrades from (sqeeze->)wheezy->jessie of existing systems for example are everything but safe now. Even 'stable' distributions with systemd core like CentOS 7 are buggy. This problem is due to systemd disturbing hundreds if not thousands or tens of thousands of component relations in Linux distributions. You don't even care about systemd functionality and administrate 10.000 Linux computers? Better wait and see.
Offline
In-place upgrades from (sqeeze->)wheezy->jessie of existing systems for example are everything but safe now.
You'll find this just about everywhere, and not just with regard to init systems. When I installed python-pip in stable, for example, I noticed that one of the lib* packages has been flagged as breaking Python if installed before upgrading from squeeze to wheezy. (No idea why such a bug report would be attached to a package in wheezy, unless that package itself is the same version from squeeze...)
Offline
systemd
As of Jessie systemd is the default init system in Debian.
How can I temporarily boot with another init on Jessie?
Install the package sysvinit if not already present and boot with the parameter.
init=/lib/sysvinit/init
How can I prevent systemd to run as PID 1 (init) on Jessie?
Remove the package systemd-sysv and install one of the alternative Pre-Depends: of the package init (either sysvinit-core or upstart as of 2014-10-22)
Please note that some applications need components of systemd (mainly systemd-logind) and will therefore depend on the package libpam-systemd (which needs the package systemd to function properly and therefore depends on it). If you don't want to use systemd as PID 1, but want to be able to use applications that need systemd-logind you will also need to install the package systemd-shim. All of this can be done with just one command:
apt-get install sysvinit-core systemd-shim systemd-sysv-
(the '-' behind systemd-sysv means remove)
How can I remove the systemd package from my Jessie system?
If you want to remove the package systemd from your system you will also have to remove any package depending (directly or indirectly) on libpam-systemd. Your prefered APT tool should do this automatically if you try to remove the package systemd. See above for a different approach that requirese keeping the systemd package, though only a few of its components will be used.
How can I remove any traces of systemd from my Jessie system
Removing any traces of systemd from your system is going to be a bit more difficult, since many packages, including Essential ones, link against libsystemd (the systemd shared library, package libsystemd0 in Jessie). Removing this package will require recompilation of every package depending on it.
Please note the library is only used by other packages when they need to interact with systemd (or one of its components) and is otherwise inert.
Offline
@Sector11: I believe I've made this point in this thread already, but:
Yes, systemd has enormous flexibility & can be used to control virtually any service; if you don't like this:sudo systemctl mask <name of the thing you think is bad>
And systemd will no longer be in charge of that process...
If you want to do it before you boot, symlink the service files (lib/systemd/system/) to /dev/null...
I really don't see how a program can be criticised for offering a large degree of (switchable) functionality.
A "masked" service is in fact in control of systemd - e.g. dbus hands over a service to systemd, which then links it to /dev/null - disabling it altogether.
I've recently done this on my Archbook:
sudo systemctl mask udisks2
sudo systemctl mask upower
sudo systemctl mask avahi-daemon
Now I can use KDE apps without having a broken system. ]:D
The question is why systemd has this functionality but dbus itself not... But you might try to copy dbus services to /etc/dbus-1/services, and change Exec to /bin/false.
Last edited by Alad (2014-11-22 15:08:21)
Round off #! Waldorf Part I/II
Scripts | Run new applications | Thunar 1.6.3 | Default soundcard | Settings daemon
On mixing sources :8
Offline
Original post deleted, see the discussion of the piece I originally posted.
I came across that as well. It scared me, considering that dbus is pretty much a core element in all Desktop Environments. Do you know if this has improved with kdbus?
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
I am a #! forum moderator. Feel free to send me a PM with any question you have!
Offline
twoion wrote:Original post deleted, see the discussion of the piece I originally posted.
I came across that as well. It scared me, considering that dbus is pretty much a core element in all Desktop Environments. Do you know if this has improved with kdbus?
I can't outline kdbus development and trajection since I don't have no special knowledge about the project, but this is a guess from poking around a bit:
You surely have read about kdbus in general (like on lwn, but in as far the points raised in the short blog post are concerned, at least the 'specification' for the kernel-side kdbus interface seems to define its own terms properly, and the interface kdbus.h has good documentation.
Needlessly to say, it's not a 'simple' mechanism at all. Reminds we a bit of the misguided attempt for 'introducing' the simple arc4random() to Linux in the form of getrandom(), which is quite complex in comparison.
Offline
A comment on Distrowatch draws a parallel between Windows svchost and systemd, noting also that both present a large "attack surface".
Making all Linux distros the same "under the hood*" would also increase vulnerability in some ways it would seem.
*That would be bonnet for the UK folks.
Last edited by jeffreyC (2014-11-26 05:04:46)
There's a reason you separate military and the police. One fights the enemies of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.
Offline
*That would be bonnet for the UK folks.
Round off #! Waldorf Part I/II
Scripts | Run new applications | Thunar 1.6.3 | Default soundcard | Settings daemon
On mixing sources :8
Offline
They're doing it: https://devuan.org/
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
I am a #! forum moderator. Feel free to send me a PM with any question you have!
Offline
This looks interesting:
Offline
^ Is there an actual issue with keeping libsystemd installed? It doesn't require a running systemd (as far as I know)... I do like the "nobus" idea though.
Last edited by Alad (2014-11-29 06:13:25)
Round off #! Waldorf Part I/II
Scripts | Run new applications | Thunar 1.6.3 | Default soundcard | Settings daemon
On mixing sources :8
Offline
They're doing it: https://devuan.org/
I just came across that site early this morning checking the latest news on LXer. It will be interesting to see where that goes, if anywhere.
Linux User #586672
Come and Die -- Kyle Idleman
Offline
^ Is there an actual issue with keeping libsystemd installed? It doesn't require a running systemd (as far as I know)... I do like the "nobus" idea though.
But for how long?
There is a strong tendency toward increasing dependencies there.
There's a reason you separate military and the police. One fights the enemies of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.
Offline
They're doing it: https://devuan.org/
I've spent some time on the Dng (Debian next generation, I guess) mailing list and the github pages where they plan to write the project... In my humble opinion, I think Devuan will die a quick death.
> Aside from fixing Debian(!) and other than being anti - systemd, it
> seems unclear to me what the aims and goals are for the project.For me its not anti-systemd - but pro-choice.
One day soon. Within a year or so I suspect.
Debian downloads will drop to a trickle. Red Hat
will loose clients but maybe not the business community
where they are entrenched today, but certainly any
new business.Our fork will be seen as one of the few PURE LINUX
distros available.
> traditionally we do not have any means of moderation at dyne.org, because of Foucaultian principles lets say. But then we have rather small groups (400/500 subscribers average per list) if compared to what this list may become.
>What does that mean? Because if it means that this list is going to
endlessly rant about differing views of freedom, the religious meaning
of debian, et al.... then this will not the venue to get such a project
off the ground.ALSO if this list is to driven to create an 'agnostic' init
distributionm that can be swapped out freely, that is problably not even
technically feasable and is a a waste of time. There are a truckload of
issues just between BSD type init system to SySV to whatever is being
passed for that in todays distros. Package mainmence becomes very
difficult.
GitHub does not value software freedom
etc etc etc
YAWS (cli weather script with conkyForecast syntax) | Bitbucket | Github | Blog
Member of the Unofficial #! Emergency Tinfoil Hat Distribution Center
Emergency Tinfoil Hat Conky Alert System development team
Offline
GitHub does not value software freedom
etc etc etc
In the linked thread: A link to Gitlab. This is a pretty sweet git web frontend, maybe I'll use it in the future when I need issue tracking instead of cgit
Faster than Github and very responsive, with interesting features, example: systemd repo.
Offline
In the linked thread: A link to Gitlab. This is a pretty sweet git web frontend, maybe I'll use it in the future when I need issue tracking instead of cgit
Gitlab is great. The only thing you need to keep in the back of your head is the relatively high resource demand. My installation serves roughly a dozen repositories with less than five commits per day and still needs around 750MB of RAM. I was able to bring it down to around 600MB by playing around with different parameters, especially for MySQL. But that's still a lot for your average cheapo VPS.
Offline
Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.
Server: acrobat