LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 09-09-2014, 01:27 PM   #16
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886

Quote:
Originally Posted by ReaperX7 View Post
...but systemd grew beyond simply being an init system to become something else. It included at least a dozen or more co-services,
Yes, because it switched its focus from being an init system/service supervisor to being a system of OS building blocks in one tree.
Quote:
dragged in D-Bus and udev,
No, it didn't. DBUS is not part of the systemd tree and it was the udev developers that decided to get their project into the systemd tree.
Not that you don't already know that.
Quote:
creates a binary log which if corrupted is useless,
This is plain wrong and I personally explained that many times on this forum already.
Quote:
and created a dependency hole within the system.
Tell me more about that. When I installed systemd on my Gentoo system it installed exactly that: systemd, no additional dependencies. Also, as you are familiar with that project, show us all the additional dependencies that are necessary to install systemd on Slackware. For those that want to know, you have to recompile shadow and DBUS to install systemd on Slackware, no additional dependencies needed.
Quote:
Many services were deprecated all for systemd,
Please show us a list of those many services, I know of exactly one: Consolekit. Would be nice if oyu can show us more.
Quote:
some projects even went as far as to only support through systemd.
Really? Which ones and why do you think it is up to you to decide what developers of a certain project have to support. Why is there no complaining about Gedit only supporting GTK or KDE being based on Qt?
Quote:
Plus, it was egotistically created only for Linux and newer versions have lock outs on certain kernel versions.
So, using features that are only available in the Linux kernel , but not in other kernels is egoistical? Isn't it egoistical in that case also to not use one of the BSD kernels, but the Linux kernel with its advanced features and much better hardware support? Is it also egoistical that alsamixer does not work with plain BSD, just because it is aimed at ALSA, not at the BSD sound systems?
Quote:
To me, I point at the massive single point of failure this has created. Even though all the different parts of systemd are different parts, they all must still execute within PID1, and should a child process crash the parent process, the system is crashed.
This is also plain wrong and has been explained to you so many times that I seriously have problems to understand why you still repeat this point. See here:
Code:
>>> ps aux|grep /usr/lib/systemd
root         1  0.0  0.1  26120  4660 ?        Ss   12:35   0:01 /usr/lib/systemd/systemd
root       159  0.0  0.1  29208  6356 ?        Ss   12:35   0:01 /usr/lib/systemd/systemd-journald
root       182  0.0  0.0  38024  3088 ?        Ss   12:35   0:02 /usr/lib/systemd/systemd-udevd
systemd+   200  0.0  0.0 102120  2416 ?        Ssl  12:35   0:00 /usr/lib/systemd/systemd-timesyncd
systemd+   229  0.0  0.0  21540  2520 ?        Ss   12:35   0:00 /usr/lib/systemd/systemd-networkd
root       230  0.0  0.0  21604  2556 ?        Ss   12:35   0:00 /usr/lib/systemd/systemd-logind
tobi       309  0.0  0.0  33164  3740 ?        Ss   12:35   0:00 /usr/lib/systemd/systemd --user
tobi      5647  0.0  0.0  10552  2112 pts/3    R+   18:57   0:00 grep --color=auto /usr/lib/systemd
Quote:
I can't bring myself to support systemd because ...[snip]
Fair enough, if you don't want or can't support it that is your right and privilege. Just stop spreading misinformation that has been debunked over and over again.
Quote:
I just wish we could see exactly where systemd is headed. How many features and daemons is it going to include and/or offer as well as deprecate? Is it going to eventually become it's own OS? I know Lennart has said Linux needs to be competitive, but at what price?
It is as Lennart said: systemd will be extended until it can be used as a set of building blocks for a Linux OS. This includes all the necessary things for an OS to work, except the kernel: init system, service supervisor, essential daemons for setting up the system. About the price for it: That is also pretty simple, the price is that this set of building blocks is incompatible with the BSDs, because it uses advanced kernel features of Linux that are not present in those OSes.
Quote:
If we take out all the stuff that was added to systemd except the init system, we basically have yet another OpenRC, Runit, s6, etc. alternative init system that would work. However, if that's the case, why do we even need it all then?
Isn't that the real question? When all these things are present for years and are of high quality, why have so few distros switched to them long ago? What is it that causes distro developers to choose systemd instead. May it be that the cause is that systemd in fact is more than an init system, but the mentioned building blocks, where it is easy to add or remove the parts you want to have for your specific distro or system?
Quote:
I have always carefully considered one thing about Linux's competitiveness... GNU/Linux speaks for itself and doesn't need to be competitive in any arena. By forcing systems to upgrade kernel and systemd in lock-step you start to remove a long standing security feature of GNU/Linux, asynchronous systems running variety of kernels and software. GNU/Linux is harder to target because no two systems are the same, meaning it's difficult to insert malware effectively, because say you target Fedora, you try to target Gentoo and end up still only targeting Fedora because the two systems run two separate kernels and software. Now that we're going to have locked step kernels, malware authors could find it easier to target GNU/Linux, and by pushing GNU/Linux mainstream, it becomes a target. If we all are running the same CoreOS regardless if it's Debian, ArchLinux, Fedora, or SuSE with equal software, now we have four systems and distributions able to be targeted.
What? Do you really think that somehow suddenly Debian systems (where version updates never occur if not absolutely and totally necessary), Arch systems (which is always bleeding edge) and Gentoo systems (where the user decides which versions to run) run on the same versions of kernel and systemd. That somehow Debian is now lock-stepped with Arch? And you realize that this lock-step of kernel and systemd does not require a specific kernel version for a specific systemd version, but that all that is needed is a specific minimal version of the kernel (at this point you need kernel >=3.4 for the latest systemd)? So you can basically use all the kernels released in the last two years if you want?
 
1 members found this post helpful.
Old 09-10-2014, 12:48 AM   #17
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,554
Blog Entries: 15

Rep: Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097
First off, let me go back and read through that messy jumbled response...

D-Bus wasn't dragged in to systemd directly, but it requires it being dragged into the mix to use systemd. Journald does require d-bus to be of usage, or a patched kernel with kdbus.

A systemd system has systemd as the main core system dependency for many packages. I think UPower now requires systemd on some level with newer releases. Older versions may still work without it. GNOME requires it also.

The please enlighten us how a corrupted binary log can actually be read other than saying I'm wrong. From documentation I've read, if the journal is corrupted, it's useless, and has to be regenerated resulting in the loss of what caused the corruption, or any system problems that could have started it.

systemd deprecated consolekit yes, but it also deprecated the functions of other projects as well like ntpd, sysklogd, syslog-ng, rsyslog, hald (though it's been deprecated by udev for some time with only minor functions still useful), udev-classic (if you want to look at it in a sick twisted sense), dhcpcd, dhclient, networkmanager (not sure if these last three are even still useful since networkd came along), pm-utils, and possibly more if I had enough time to look for them. I think it even has it's own cron daemon too. Not all of those are actually deprecated, but within systemd they're useless because systemd has it's own set of tools.

Building blocks for an OS? Are you serious, or have we all been clueless forever that something was missing? That's honestly a laugh and a half because we've had a whole bazaar of building blocks for Linux based operating systems for quite some time with some variations betwixt and between others. Why do we need yet another set? Because someone egotistically says we "need" it? Are the current tools broken? Are the current tools incapable of building a proper Linux based OS? Why do we need a monolithic cathdralistic toolkit when we have a modular bazaar of toolkits that have worked and still work? Honestly, if that's the case, then ĦAy,_caramba! UNIX has been broken since it was created, so then what have we been using all this time? Toothpaste, bubblegum, chicken wire, and duct tape holding a kernel and GNU tools together? Wow how redneck is GNU/Linux?

Honestly, I don't know why other distributions chose what they chose, other than speculation into work ethic behind porting stuff in and developing it to work. other than that, I have no clue, but choosing systemd is their choice.

Yes, Tobi, if you even have read Lennart's blogs and mailing lists, you'll see where certain kernels are locked out from systemd requiring using of newer kernels as a minimum. As far as I know, I think you can still use the minimum of kernel 2.6.32 outside of systemd, but within systemd that may not be the case. Some talk around ArchLinux forums has it pegged at kernel 3.3.8 or later. Google it yourself.

Last edited by ReaperX7; 09-10-2014 at 12:50 AM.
 
3 members found this post helpful.
Old 09-10-2014, 02:27 AM   #18
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742
Redhat leads, the other follows,
I do not think that Pottering would be so successful without a company in the background
and the future will be this
http://0pointer.net/blog/revisiting-...x-systems.html
 
Old 09-10-2014, 02:33 AM   #19
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599Reputation: 3599
Please remain on topic, please remain factual and please don't let your personal irritation, or anything else that doesn't matter to the core question of this thread, influence your responses. Thanks in advance.
 
3 members found this post helpful.
Old 09-10-2014, 02:48 AM   #20
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,252
Blog Entries: 24

Rep: Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192Reputation: 4192
Quote:
Originally Posted by a4z View Post
Redhat leads, the other follows,
I do not think that Pottering would be so successful without a company in the background
and the future will be this
http://0pointer.net/blog/revisiting-...x-systems.html
Good point worth pondering...

Had systemd, as it exists now, originated from outside the corporate nest, such that it had to sell itself and survive entirely on its own merits... would any of us even be aware of it?

Asked another way, if the current incarnation and future roadmap of systemd were presented to the free software world by its actual author(s), but without guaranteed inclusion in multiple distros, and without the monetary and political muscle of a billion dollar corporate interest pushing it... would it have gained acceptance or survived?

That is not a positive or negative comment on corporate involvement, but it is intended to provide some balance to the merit based arguments.

If removal of the power backing it signifigantly shfts the balance of the equation, then it isn't primarily about merit, or even about merit at all!

Last edited by astrogeek; 09-10-2014 at 02:59 AM. Reason: typos, small wording change...
 
1 members found this post helpful.
Old 09-10-2014, 03:13 AM   #21
Germany_chris
Senior Member
 
Registered: Jun 2011
Location: NOVA
Distribution: Debian 12
Posts: 1,068

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
Quote:
Originally Posted by astrogeek View Post
Good point worth pondering...

Had systemd, as it exists now, originated from outside the corporate nest, such that it had to sell itself and survive entirely on its own merits... would any of us even be aware of it?

Asked another way, if the current incarnation and future roadmap of systemd were presented to the free software world by its actual author(s), but without guaranteed inclusion in multiple distros, and without the monetary and political muscle of a billion dollar corporate interest pushing it... would it have gained acceptance or survived?

That is not a positive or negative comment on corporate involvement, but it is intended to provide some balance to the merit based arguments.

If removal of the power backing it signifigantly shfts the balance of the equation, then it isn't primarily about merit, or even about merit at all!
But the corporate part is generating some if not most of the resistance.
 
Old 09-10-2014, 03:14 AM   #22
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,554
Blog Entries: 15

Rep: Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097
You could use the proverbial statement, "Follow the money and paper trail back to where it started" with systemd very effectively.

I doubt that if Red Hat had not sponsored it, it wouldn't have gained no greater a foothold than Runit has. The LSB still classifies sysvinit as part of the requirements for LSB standards.

A question to ponder though somewhat off topic (sorry unSpawn) but has Red Hat had any significant losses in the UNIX server OS market in the last 10 years compared to other server minded and oriented distributions like Solaris, openBSD, etc.?

Last edited by ReaperX7; 09-10-2014 at 03:15 AM.
 
Old 09-10-2014, 03:20 AM   #23
Germany_chris
Senior Member
 
Registered: Jun 2011
Location: NOVA
Distribution: Debian 12
Posts: 1,068

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
From the look of their financials no.
 
Old 09-10-2014, 03:26 AM   #24
Randicus Draco Albus
Senior Member
 
Registered: May 2011
Location: Hiding somewhere on planet Earth.
Distribution: No distribution. OpenBSD operating system
Posts: 1,711
Blog Entries: 8

Rep: Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635
Quote:
Originally Posted by TobiSGD View Post
Why is there no complaining about Gedit only supporting GTK or KDE being based on Qt?
[...]
Is it also egoistical that alsamixer does not work with plain BSD, just because it is aimed at ALSA, not at the BSD sound systems?
These are honestly supposed to be analogous comparisons? Alsamixer being made to work specifically with Alsa is the same as systemd development?

Quote:
Fair enough, if you don't want or can't support it that is your right and privilege. Just stop spreading misinformation that has been debunked over and over again.
It is as Lennart said: systemd will be extended until it can be used as a set of building blocks for a Linux OS. This includes all the necessary things for an OS to work, except the kernel:
There is no mis-information there. Only truth. A very frightening truth. It explains with clear details where things are going.

Quote:
Originally Posted by ReaperX7
Building blocks for an OS? Are you serious, or have we all been clueless forever that something was missing? That's honestly a laugh and a half because we've had a whole bazaar of building blocks for Linux based operating systems for quite some time with some variations betwixt and between others. Why do we need yet another set? Because someone egotistically says we "need" it? Are the current tools broken? Are the current tools incapable of building a proper Linux based OS? Why do we need a monolithic cathdralistic toolkit when we have a modular bazaar of toolkits that have worked and still work? Honestly, if that's the case, then ĦAy,_caramba! UNIX has been broken since it was created, so then what have we been using all this time?
+1
 
Old 09-10-2014, 04:43 AM   #25
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,554
Blog Entries: 15

Rep: Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097
If Red Hat hasn't had any losses then why push a new project as massive as systemd that poses to develop a "LinuxOS" to duplicate other system control services like SMF, svchost, and launchd in every aspect? That makes little or no sense... but...

One of the aspects I've noticed is with systemd is distribution maintainers like for example, Red Hat, Fedora, and the like have less to maintain on their end. By fair comparison, how well are Fedora and Red Hat's sysvinit scripts written compared to other distributions, out of curiosity? I only ask because a while back on a few Linux forums similar to LQ, someone mentioned that the scripts used by Red Hat or Fedora, I forget which of the two exactly, maybe both(?), had very poorly or sloppily written script sets.

I honestly don't get why such the aggresive push.

ArchLinux I understand as they typically use bleeding edge software without second thought, and have a track record of breaking their own distribution, but others made little sense to abandon perfectly working systems designs, unless they had shortcomings in areas internally.

As far as Canonical, Upstart is a nightmare unto itself, no question why they dumped it, other than monkey-see monkey-do with Debian.

Debian, I don't get at all. That was very strange. Debian has a record of using only the highest levels of using software that's tested, proven, and absolutely non-proprietary in any way, shape, or form.

As far as other distributions, who knows but trend following and monkey-see monkey-do. I've seen few distributions dump systemd also. Only VoidLinux has dared to pasture systemd out in favor of an alternative init and service supervisor.

Last edited by ReaperX7; 09-10-2014 at 04:59 AM.
 
Old 09-10-2014, 04:51 AM   #26
Randicus Draco Albus
Senior Member
 
Registered: May 2011
Location: Hiding somewhere on planet Earth.
Distribution: No distribution. OpenBSD operating system
Posts: 1,711
Blog Entries: 8

Rep: Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635
With sufficient money and promotion, anything can be made popular or even a "need" for it created. McDonald's did not become so immensely popular by selling good food. They became king by throwing large amounts of money into promotion. Quality and need do not play a part. Enter Red Hat and their Poettering front man.
 
Old 09-10-2014, 05:03 AM   #27
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,554
Blog Entries: 15

Rep: Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097
So... Corporate power play with intention of hostile takeover?
 
Old 09-10-2014, 05:10 AM   #28
Germany_chris
Senior Member
 
Registered: Jun 2011
Location: NOVA
Distribution: Debian 12
Posts: 1,068

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
I don't see any push but I'm not "in" the community.
 
Old 09-10-2014, 08:07 AM   #29
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886
Quote:
Originally Posted by ReaperX7 View Post
First off, let me go back and read through that messy jumbled response...

D-Bus wasn't dragged in to systemd directly, but it requires it being dragged into the mix to use systemd. Journald does require d-bus to be of usage, or a patched kernel with kdbus.
xfce4-power-manager also needs DBUS to function. Can we conclude that XFCE now has dragged in DBUS, so as you state systemd has?
Quote:
A systemd system has systemd as the main core system dependency for many packages.
These are the package on my system that require systemd:
Code:
>>> equery depends systemd
 * These packages depend on systemd:
app-admin/syslog-ng-3.5.5 (systemd ? sys-apps/systemd)
app-emulation/libvirt-1.2.6 (systemd ? sys-apps/systemd)
gnome-base/gvfs-1.20.2 (systemd ? sys-apps/systemd:0)
media-sound/pulseaudio-5.0-r2 (systemd ? sys-apps/systemd:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
net-misc/networkmanager-0.9.8.10-r1 (systemd ? >=sys-apps/systemd-183:0)
                                    (>=sys-apps/systemd-183)
sys-apps/dbus-1.8.6 (systemd ? sys-apps/systemd:0)
sys-apps/gentoo-systemd-integration-4 (>=sys-apps/systemd-207)
sys-auth/pambase-20140313 (systemd ? >=sys-apps/systemd-204[pam])
sys-auth/polkit-0.112-r2 (systemd ? sys-apps/systemd:0)
sys-fs/udisks-2.1.3 (systemd ? sys-apps/systemd)
sys-process/procps-3.3.9-r2 (systemd ? >=sys-apps/systemd-209)
virtual/libgudev-215-r1 (systemd ? >=sys-apps/systemd-212-r5:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,gudev,introspection?])
                        (systemd ? >=sys-apps/systemd-208-r3:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,gudev,introspection?])
                        (systemd ? >=sys-apps/systemd-208:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,gudev,introspection?])
virtual/libudev-215-r1 (systemd ? >=sys-apps/systemd-212-r5:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
                       (systemd ? >=sys-apps/systemd-208-r3:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
                       (systemd ? >=sys-apps/systemd-208:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
virtual/logger-0 (>=sys-apps/systemd-38)
virtual/service-manager-0 (kernel_linux ? sys-apps/systemd)
virtual/udev-215 (systemd ? >=sys-apps/systemd-208:0)
x11-base/xorg-server-1.15.99.903 (systemd ? sys-apps/systemd)
Most of these packages don't actually require systemd, but can be compiled with support for it, which I have done. Also, when we go back to bartgymnast's project (running Slackware with systemd), you can see that only shadow and DBUS had to be recompiled for use with systemd. I wouldn't exactly call this "many".
Quote:
I think UPower now requires systemd on some level with newer releases. Older versions may still work without it.
I don't know much about UPower, so I can't comment on that.
Quote:
GNOME requires it also.
Yes, also a decision by GNOME developers, not systemd developers. If you think this is bad you have two options: Either join the Gnome team and add support for ConsoleKit again, or join the OpenBSD team that develops the systemd shim software. After all, this is still open source, if you don't like something do something about it.
Quote:
The please enlighten us how a corrupted binary log can actually be read other than saying I'm wrong. From documentation I've read, if the journal is corrupted, it's useless, and has to be regenerated resulting in the loss of what caused the corruption, or any system problems that could have started it.
The journal is encoded on a line-by-line basis (how else would you do it with a log?), which means if a corruption occurs only the corrupted lines are affected, the rest of the journal is still readable. Pretty much the same as with a text file.
Quote:
systemd deprecated consolekit yes, but it also deprecated the functions of other projects as well like ntpd, sysklogd, syslog-ng, rsyslog, hald (though it's been deprecated by udev for some time with only minor functions still useful), udev-classic (if you want to look at it in a sick twisted sense), dhcpcd, dhclient, networkmanager (not sure if these last three are even still useful since networkd came along), pm-utils, and possibly more if I had enough time to look for them. I think it even has it's own cron daemon too. Not all of those are actually deprecated, but within systemd they're useless because systemd has it's own set of tools.
systemd did not deprecate ConsoleKit, it was simply abandoned by its developer. If that bothers you feel free to take ConsoleKit over. Also, all the services you list, except the ones I will address in a minute, are still existent and can be used fine together with systemd. No one is forcing you to use the inbuilt variants in systemd (just disable them at compile time or, even simpler, just don't use them), you can install and use the daemons you listed just fine. You can use ntpd (and you actually have to, since systemd does not contain a NTP server), the syslog daemons can be used (with even extended functionality) together with journald, and so on. Pretty much the same as in, for example, Busybox, where you also have the choice to use the inbuilt functions or to replace them with whatever you want. So they are hardly useless in systemd systems. You can also still use all these components outside of systemd, so where is the deprecation. You would have made a point with pm-utils, but it was not systemd that removed ConsoleKit support in pm-utils, it was lack of maintenance of ConsoleKit that is the cause and it was a decision by pm-utils developers, not by systemd.
Quote:
Building blocks for an OS? Are you serious, or have we all been clueless forever that something was missing? That's honestly a laugh and a half because we've had a whole bazaar of building blocks for Linux based operating systems for quite some time with some variations betwixt and between others. Why do we need yet another set? Because someone egotistically says we "need" it? Are the current tools broken? Are the current tools incapable of building a proper Linux based OS? Why do we need a monolithic cathdralistic toolkit when we have a modular bazaar of toolkits that have worked and still work? Honestly, if that's the case, then ĦAy,_caramba! UNIX has been broken since it was created, so then what have we been using all this time? Toothpaste, bubblegum, chicken wire, and duct tape holding a kernel and GNU tools together? Wow how redneck is GNU/Linux?
So you are telling me that we don't need KDE, GNOME or XFCE, since WMs and other tools existed before. That nobody should use Gedit because Vi(m) and Emacs exist? Are you serious? As I said above, they want to have the building blocks for an OS in one tree, so that you can decide at compile time which features you need with a simple switch to the configure command. Also things don't need to be broken to be replaced, it is enough that a competitor of those things is better suited for a certain job. As it seems many distribution developers do actually think that systemd is better suited, otherwise they would just use something different (which in fact at least some do, see the switch of Void Linux from systemd to runit). Fact is: systemd consolidated (or is in the process of consolidating) building blocks for a Linux OS in one tree, many distro developers appreciate that effort. So there must be an advantage for systemd here.
Quote:
Yes, Tobi, if you even have read Lennart's blogs and mailing lists, you'll see where certain kernels are locked out from systemd requiring using of newer kernels as a minimum. As far as I know, I think you can still use the minimum of kernel 2.6.32 outside of systemd, but within systemd that may not be the case. Some talk around ArchLinux forums has it pegged at kernel 3.3.8 or later. Google it yourself.
I don't have to Google it (I would use DuckDuckGo, anyways), I gave you the answer in my last post, LP himself said that you need at least 3.4 for the latest systemd (at that point 216). This number, by the way, was given by one of Lennart's answers on the mailing list.

Quote:
Originally Posted by Randicus Draco Albus View Post
These are honestly supposed to be analogous comparisons? Alsamixer being made to work specifically with Alsa is the same as systemd development?
Yes these are honestly supposed to be analogous comparisons. How is it not egoistical of alsamixer not to support BSD sound systems because it is written specifically for ALSA sound system and all the features it has, when it is egoistical for systemd not to support BSD kernels because it is specifically written for the Linux kernel and all the features it has?
Quote:
There is no mis-information there. Only truth. A very frightening truth. It explains with clear details where things are going.
When ReaperX7 repeats again and again that all systemd services have to run in PID 1, despite this having been debunked and explained to him over and over again, then this is spreading of misinformation, it is not telling the truth (unless you think repeating a made-up "fact" often enough makes it somehow the truth). I can't say if that is deliberately or has other reasons, but that does not change the fact that he is spreading misinformations.
 
1 members found this post helpful.
Old 09-10-2014, 08:45 AM   #30
Randicus Draco Albus
Senior Member
 
Registered: May 2011
Location: Hiding somewhere on planet Earth.
Distribution: No distribution. OpenBSD operating system
Posts: 1,711
Blog Entries: 8

Rep: Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635
Quote:
Originally Posted by TobiSGD View Post
Yes these are honestly supposed to be analogous comparisons. How is it not egoistical of alsamixer not to support BSD sound systems because it is written specifically for ALSA sound system and all the features it has, when it is egoistical for systemd not to support BSD kernels because it is specifically written for the Linux kernel and all the features it has?
Developing a mixer as an additional component for a sound system is vastly different than OS-kernel compatibility.
Quote:
When ReaperX7 repeats ... I can't say if that is deliberately or has other reasons, but that does not change the fact that he is spreading misinformations.
I am not sure if the meaning of my post was clear, but I was referring to your description of systemd being extended, until it can be used as a set of building blocks for a Linux OS. You are completely correct. And I wish you were not, because the implications are frightening.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Is systemd as bad as boycott systemd is trying to make it? LXer Syndicated Linux News 0 09-03-2014 06:50 PM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 10:02 AM
adopted new regulations Volcano General 4 03-06-2010 06:55 AM
Institutions in India which have adopted Linux sawant priyanka Linux - General 3 05-20-2009 12:50 PM
Children to be adopted into home of a Child Molester littlejimm General 0 12-01-2003 08:07 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 05:15 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration