> Well the goal of systemd is to be a base system for GNU/Linux distributions to reduce the gaps between them.
Please note the "Linux only" focus. It's not compatible with _any_ other free software or open source based operating system. And "reducing the gaps between them" has been breaking many stable, long-working tools without significant benefit.
Nothing is preventing anybody to re-implement the external API's of systemd on any OS (well need D-Bus).
Regarding the benefits, I'll let you be the only judge, for my use cases it's a nice improvement
>> such as the default enabled "KillUserProcess" command
> No distribution that I know enable that by default
The default was changed to enabled in the systemd source code in release 230. Unless distributions or developers manually patch their configurations, this unrequested behavior is now on by default.
There is a configure flag. Anyway, systemd needs to be integrated inside the distributions, it's definitely not advised for random users to compile it themselves without using the distro patches.
3rd answer:
- It will be already running as a different process, will have not a lot to do vwith systemd PID1 and will only live in the same source code repository?
Each of the tenth of compentent of systemd are doing onething and are doing it well.
The fact that they are in the same source tarball doesn't mean that they all live in the same executable
Who is "Debian leadership"? The DLP? The FTP-masters? the Release team? the individual maintainers? the Pope?
You are quoting (or are you Gregory Smith or whatever alias?) https://lkml.org/lkml/2014/10/... which in is complete non-sense. Nobody has decided anything, systemd-shim is still in the archive at this point.
Euh, are you aware that clamav-daemon can be socket activated (at least on debian) and that if any program is trying at access the socket will automatically start the daemon. Therea are a lot of other daemon that can be socket activated (syslog-ng, pcscd,...) that then requires (in most of the cases) no explicit dependencies and will only be started on demand.
Also, systemd actually includes a lot of mechanism to know about the readiness of a service (see: http://www.freedesktop.org/sof...) and the different states are way more fine grained that what LSB initscripts could provide. It also has knowledge of the different mountpoint on the system (.mount unit files) and they can be used as dependencies.
It seems that the guy who transmitted the mail to TF1 has given his resignation which has been refused by the minister.
He only gets a one month suspension...
NAT are an evil hack to the ipv4 address exhaustion..
I think that ICANN recommends to the ISP to give a/48 pool to the end user, hope they will follow the recommendation (or at least give a/56)
Have you quite finished? Geez, it's a wonder multimedia-based services like YouTube even work on... just about every browser on the planet. Windows/MacOS/GNU/linux x86 is certainly "just about every browser on the planet."
Slashdot Mirror
The glibc does embed a copy of libidn in the source code and apparently link statically against it: https://sourceware.org/git/?p=... https://sourceware.org/git/?p=...
AFAICT, nscd (the glibc DNS cache) is also doing idn conversion right?
The init systemd (PID1) is not messing with DNS resolved, and optional component of the systemd ecosystem is
I don't understand, if it's not a bug in libidn2, why did they patch it to change the default behavior?
> Nothing is preventing anybody to re-implement the external API's of systemd on any OS (well need D-Bus).
D-Bus does not exist for any other kernel.
dbus-daemon exists on FreeBSD...
> Well the goal of systemd is to be a base system for GNU/Linux distributions to reduce the gaps between them.
Please note the "Linux only" focus. It's not compatible with _any_ other free software or open source based operating system. And "reducing the gaps between them" has been breaking many stable, long-working tools without significant benefit.
Nothing is preventing anybody to re-implement the external API's of systemd on any OS (well need D-Bus).
Regarding the benefits, I'll let you be the only judge, for my use cases it's a nice improvement
>> such as the default enabled "KillUserProcess" command
> No distribution that I know enable that by default
The default was changed to enabled in the systemd source code in release 230. Unless distributions or developers manually patch their configurations, this unrequested behavior is now on by default.
There is a configure flag. Anyway, systemd needs to be integrated inside the distributions, it's definitely not advised for random users to compile it themselves without using the distro patches.
such as the default enabled "KillUserProcess" command
No distribution that I know enable that by default
3rd answer: - It will be already running as a different process, will have not a lot to do vwith systemd PID1 and will only live in the same source code repository?
Each of the tenth of compentent of systemd are doing onething and are doing it well. The fact that they are in the same source tarball doesn't mean that they all live in the same executable
Who is "Debian leadership"? The DLP? The FTP-masters? the Release team? the individual maintainers? the Pope? You are quoting (or are you Gregory Smith or whatever alias?) https://lkml.org/lkml/2014/10/... which in is complete non-sense. Nobody has decided anything, systemd-shim is still in the archive at this point.
"security-challenged mash-up" like running huge pile of barely maintained code in ring0?
Euh, are you aware that clamav-daemon can be socket activated (at least on debian) and that if any program is trying at access the socket will automatically start the daemon. Therea are a lot of other daemon that can be socket activated (syslog-ng, pcscd,...) that then requires (in most of the cases) no explicit dependencies and will only be started on demand. Also, systemd actually includes a lot of mechanism to know about the readiness of a service (see: http://www.freedesktop.org/sof...) and the different states are way more fine grained that what LSB initscripts could provide. It also has knowledge of the different mountpoint on the system (.mount unit files) and they can be used as dependencies.
Could be interesting to change the link to use coral cache to prevent /.ing
Not sure why this one is ranked "funny"
It seems that the guy who transmitted the mail to TF1 has given his resignation which has been refused by the minister. He only gets a one month suspension...
Now let's talk about the US giving up the control over the DNS, the IP allocation...
Right, they are not idiots, they're corrupted...
No god == no intelligent design
End of the story
NAT are an evil hack to the ipv4 address exhaustion.. I think that ICANN recommends to the ISP to give a /48 pool to the end user, hope they will follow the recommendation (or at least give a /56)
According to a comment on IEBlog there is already a registry entry for that
Be careful, are you sure the png image doesn't have an alpha channel?
On my ubuntu hardy machine, I can start the game(get the minimap and the buttons) but the map on the right doesn't show anything... :(
Am I the only one who read memory leak?
Windows for gaming Linux for everything else