So how do you merge local changes and distribution updates?
It's not possible without examining what the change was to the distribution and what your local change was intending to do. For example, if the new default config file for an application changed default behavior for a very good reason, you need to think long and hard about what your local config should do...override the new default to act like before, or stick with the distro defined default. This will be a problem regardless of what packaging system and init system you use.
For the record, systemd does this cleanly by moving distro-provided unit into/usr while user overrides go into/etc.
This has nothing to do with really important things (for example, the Apache and MySQL config files), but only affects startup order and parameters to the daemons. For startup order, I let the distribution default decide in almost every case, but edit the startup script to change the start order if necessary. Only poorly-behaved package managers will overwrite my changes, and good ones install a new script next to the old one. As for startup parameters, I use/etc/sysconfig/servicename, as it has always been used.
Once again, systemd solves a problem that didn't really exist.
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yes. Absolutely. Positively. Yes, again and again. Mostly because they don't WANT to learn systemd, so the very process of doing so is agonizing enough that they don't get very far.
It is true that at least some 20-year *nix admins don't want to learn anything new.
On the other hand, there are a lot of 20-year *nix admins who love to learn about new things (I fit that category), but absolutely don't want to learn systemd because it is a waste of time in that it doesn't offer them any advantage over what they currently use.
The claim is that in the lag between systemd binary logs and the time when systemd has bothered to hand the message off to the next systemd and it gets written to disk, you can lose messages from your text logs that may or may not be in your systemd log due to truncation of the binary log in the case of a crash, and this is a fact.
The other issue is that journald has to perform a conversion on the log message to put it into text format. Based on all the other bugs with journald, I have no faith that this conversion is done in a way that correctly maintains all information.
sysvinit is still there, so just don't install systemd.
Explain, in detail, how to accomplish this on CentOS 7. I keep hearing systemd proponents say this, but nobody backs it up with a real-world example.
I don't even care if the default install disk forces systemd and your explanation is how to remove it, even though it isn't "just don't install systemd" as you claim is possible.
I do, however, care about being able to install real world packages, although nothing related to a GUI. But, things like apache, sendmail, mysql, samba, and cups are requirements.
I've followed many discussions on forums of people having trouble with a daemon and the debugging of that demon is made MORE complex by the fact that it is managed by systemd.
Exactly so. When all else fails with SysVInit or even upstart, you have a shell script that you can run from the command line, and could have added some debugging statements.
With systemd, you have to hunt through layers upon layers of files and links to find out exactly what executable is being run, and with what options.
As a very part-time server admin, I do in fact care about boot times
You really aren't a server admin, are you? How long does your choice of Linux distribution take to boot from the time grub gets control? And, how long is that compared to the time it takes the BIOS to verify the hardware on a typical physical server? For every system we have, the hardware check is literally orders of magnitude longer. It take less than 20 seconds for a system to be usable after grub starts (and that's one of our more complicated configs...generally, everything is up within a few seconds), while it isn't uncommon for the hardware check to take 3 minutes.
Yes, one could argue that all of those should be in their own little VMs, but if you're doing security updates, it boils down to having update everything sooner or later - might as well have it all on one machine.
Again, you aren't a Linux server admin. If you have a good VM infrastructure, it costs almost nothing to run another VM that uses the same OS. In addition, with the exception of kernel updates, reboots aren't required for Linux patches (okay, maybe one in a thousand). Yes, you might have to restart a service to get the new binary running, but since you've already tested this in your dev environment, you know it's just a simple restart. What...you don't have a dev environment? Again, not a sysadmin.
And with systemd I can finally be sure if Apache started or not
Really? How can systemd be sure that Apache has started completely and is ready to serve pages?
The answer is...exactly the same way every init script is "sure" that a service has started. It checks for the running instance, it checks PID, etc. But, unless it actually connects to the correct IP and port from a permitted IP and retrieves a web page that says something like "yeah, I'm running", systemd doesn't know.
I written service-monitoring scripts, and what systemd does isn't it, and is fundamentally no different from what is done by current init scripts. The difference is the current init scripts won't kill and restart Apache because they "think" something has gone wrong.
If systemd is so very very wrong then people wouldn't use it right? Certainly no major distro will go out of their way to adopt something wrong.
systemd solves problems that are mostly associated with systems that have users who log in directly using a GUI. Most major distros have a strong "desktop" following, and as such, are interested in systemd.
Unfortunately, for the vast majority of systems that run just fine without the need to notify logged in users that a USB device has been hot-plugged, systemd doesn't offer much compared to the learning curve required to figure it out without documentation. In addition, the systemd environment (since it's not just one program) has bugs, and unlike older programs where the bugs and failures are known and can generally be worked around, this is not the case for systemd.
Well, back in the early '90s, Texas A&M used lots of GM, and lots of students drove GM as well.
Interesting. I never heard anything about that, and the group of people I hung around with were just the sort that would pull that kind of stunt. I left in 1995, though, so maybe it was a little later.
The problem is lost keys. There has to be a mechanism for an automotive dealer or manufacturer to replace lost keys, and it has to function without the original key.
Why?
If you have no key available for the car, the car's private key can (and should) be wiped and replaced with a new one, and the key fob given the matching public key. Again, this is assuming that the system uses public key encryption (which it should) and that you have physical access to the car.
It's not like BMWs are bargain basement cars, surely they could have spent a bit on an actually secure keyless entry system.
The problem is that the only right way to do it is a public key-based challenge/response system. This prevents replays from snooping, keeps the keys secure (they never leave the car or key fob), and essentially prevents brute force.
The issue is that this requires the key fob to have both a transmitter and a receiver, plus more computing power, making it larger, and would likely run the battery down pretty fast (even if the receiver is only powered for a few seconds after a button is pressed). Nobody wants to replace their key fob battery every few months.
On the other hand, the biggest hazard facing a cyber warrior is likely to be the morning commute.
There are a lot of computer attacks that must be done from inside a network, either because it isn't connected to anything else or because firewalls are good enough to stop outside attacks. This might require being on the ground somewhere that being shot at is possible.
The solution is to relax the physical requirements, not toss them out completely. The military could allow someone to join who doesn't meet standards, but every year after that, they would have to get closer to the standard, and maybe even eventually meet the same ones as every other soldier.
"private businesses are still free to specify which forms of legal tender they will accept. If a shop doesn't want to take any currency larger than $20 bills, or they don't want to take pennies at all, or they want to be paid in nothing but dimes, they're entitled to do so"
The exception to this is if you are in debt to the private business. In that case, they must take cash, as it is "legal tender for all debts, public and private". Note that coins are not cash, so they can pick and choose about coins they will accept.
For any regular store, you haven't incurred a debt by the time you are ready to pay. Restaurants, on the other hand, generally have to take cash, as all but fast food serve you before you pay, thus it is a debt.
If he wants to upgrade to 4K or something he'd need a new video card, which should contain enough of it's own processing ability that all all the computer has to do is feed IT the minimally preprocessed video stream for decoding and display.
The Mac Mini has no component that can be upgraded other than the RAM (which is limited to 16GB). The video controller is soldered onto the motherboard, and there are no expansion slots. Thus, if you want to do anything with a particular model Mac Mini that Apple didn't anticipate, you have to buy another computer.
No point nitpicking just because the "b" denoting Megabits was forgotten.
It's not nitpicking because there is a vast difference between 200MB/sec and 200Mbps (about 25MB/sec). It's trivial to get 100MB/sec over gigabit Ethernet, and you don't have to spend a lot of money to do it. I've got a case that will hold 15 3-1/2" hard drives, and the guts (case, motherboard, RAM, RAID card, hot swap bays) cost about $1,500, which is a lot less than the Synology case without drives. I use 2TB drives because that's what I needed at the time, but could have the same 60TB as you if I used 4TB drives.
That machine also has a 10Gbit NIC, and when using that, I get around 600MB/sec transfer to this server. Now, part of that speed comes from the $350 I spent on 480GB of SSD cache for the array, but that's an option I have and the Synology doesn't. Even without the SSDs, 350MB/sec was the speed I saw. So, 25MB/sec for all the money you spent is pretty lame.
A speed of 200Mb/s is not huge but it's not too bad either, even though a fairly old machine (6 years) with a few disks in an array can get close to five times that and saturate gigabit (or even twice over if a second connection is going somewhere else).
Again, 200Mbps is terrible for transfer across a gigabit network. Even a single drive source should be able to supply 240Mbps, with any array easily saturating the link.
Also, you don't need disk arrays anymore...single SSDs will max out gigabit ethernet and give 10Gbit a run for its money. With arrays for the large data, fronted by SSD cache, fronted by RAM (again, lots of RAM is cheap, but not really an option for the Synology), even 10Gbit isn't up to the task.
If you need to run software that uses 20GB of RAM (very likely 5 years from now), you're SOL. If you want to play the latest games at high resolution, or want to drive a 4K monitor, you're SOL. If you want to use a USB 4.0 or Thunderbolt 3 (for example) peripheral at full speed, you're SOL, and depending on the updates to some of the connection standards you might not be able to use it at all.
These aren't all flaws with the Mac Mini specifically, but rather any computer with no generic (e.g., PCIe slots) upgrade options. Still, an only slightly larger form factor (mini-ITX) can often give you at least two slots...one for video and one for something else, and most generic motherboards offer more memory slots than you get on any all-in-one from any company.
180-200M/sec throughput is the norm. On the network.
You have a 10 gigabit network? I ask because a 1 gigabit network can only provide 125MB/sec throughput. I know that some of the Synology units offer link aggregation support, but that also usually requires support in the switch and multiple network cards in each client.
That said, even 200MB/sec isn't particularly good if you can only provide that total to one client at a time, especially for the cost of a Synology enclosure that can hold enough drives for 60TB of storage.
Most crimes have a "Mens rea" requirement - an intent to commit the crime.
Unfortunately, most of the time the law is actually enforced such that merely intending to commit the act that turns out to be prohibited by law is considered "intending to commit the crime".
As an example, driving 55mph in a 35mph zone can be punished regardless of whether you intended to drive over the speed limit. Likewise, breaking some obscure law can still be punished even if you didn't realize what you were doing was a crime. So, if Aunt Tilly intended to send that emoticon, then she can be prosecuted regardless of whether she intended harm. As the GP noted, she likely wouldn't be, but someone not as sympathetic might be.
The problem is MS never had a small tutorial during windows installation or during the first boot showing users how to create a Standard User account and have an administrative account for elevating your rights for doing administrative stuff.
The actual problem is that unlike Linux, doing this doesn't help you do a lot of the "administrative stuff" you need to do in Windows.
In Linux, a normal user with sudo permission can run "sudo su -" and everything run from that terminal will have admin privileges. You can do the same thing in Windows with "RunAs" either from a command prompt or from the Start Menu with Shift+RightClick. The problems then start. First, you have to figure out what command to enter to do something that is normally only done with the GUI. Then, you have to remember that everything is being done as the admin user, so any changes don't get put into the normal user's profile. This causes problems for some programs that don't have the "install for all users" functionality set up correctly.
In addition, there are some things that stupidly require elevated privileges but affect only the current account (like Control Panel->System->Advanced System Settings->Performance), which are thus impossible to change if your account isn't a member of "Administrators". There are also some things that even "Administrators" don't have permission to do, but "Administrator" does. And, there are some things that can't be done because you can't actually become the account that you need to be in order to do them (like "TrustedInstaller").
if you're not watching the ads, it means jack squat to the producers.
The producers of the show only care tiny bit about advertising, as they get their pay up front (a TV channel/network pays them to produce the content) and from various forms of direct sales (DVD, Hulu, Amazon, etc.). Because much of the value of a show has moved from the first-run airing, networks now partner with producers to produce the show, so that the network also gets a cut of the direct sales.
So, producers care a little bit about ratings and advertising, because if nobody is watching their show, they won't get any more money to make it, but as long as enough people watch in some form that puts money in the producer's pocket, the show will still get made.
I assume you were exaggerating, but just to be clear: it is not necessary to run all of the programs which make up the systemd "brand". With the exception of a few core dependencies like journald, you are free to pick the components you wish to run.
So, you've tried this? Either by compiling one of the "extras" and running it on a system where systemd isn't installed, or by completely removing the extras and running alternatives that give the same functionality?
in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.
The current init system has always done this, buffering up log entries until the logfiles are available. How else do you think dmesg has entries from milliseconds after the kernel starts?
The developers of systemd have all of those separate apps and daemons in one code repository, but you can pull each of them out and compile each of them separatly.
Slashdot Mirror
So how do you merge local changes and distribution updates?
It's not possible without examining what the change was to the distribution and what your local change was intending to do. For example, if the new default config file for an application changed default behavior for a very good reason, you need to think long and hard about what your local config should do...override the new default to act like before, or stick with the distro defined default. This will be a problem regardless of what packaging system and init system you use.
For the record, systemd does this cleanly by moving distro-provided unit into /usr while user overrides go into /etc.
This has nothing to do with really important things (for example, the Apache and MySQL config files), but only affects startup order and parameters to the daemons. For startup order, I let the distribution default decide in almost every case, but edit the startup script to change the start order if necessary. Only poorly-behaved package managers will overwrite my changes, and good ones install a new script next to the old one. As for startup parameters, I use /etc/sysconfig/servicename, as it has always been used.
Once again, systemd solves a problem that didn't really exist.
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yes. Absolutely. Positively. Yes, again and again. Mostly because they don't WANT to learn systemd, so the very process of doing so is agonizing enough that they don't get very far.
It is true that at least some 20-year *nix admins don't want to learn anything new.
On the other hand, there are a lot of 20-year *nix admins who love to learn about new things (I fit that category), but absolutely don't want to learn systemd because it is a waste of time in that it doesn't offer them any advantage over what they currently use.
Ubuntu and Redhat and Suse making money from their distributions, it's in their best interest what their users want.
RedHat and SuSE users don't care about anything but "does the application I bought from Oracle/IBM/whatever run, and is it supported?"
As long as somebody else (i.e., paid support) can debug the issues with systemd, users don't care.
The claim is that in the lag between systemd binary logs and the time when systemd has bothered to hand the message off to the next systemd and it gets written to disk, you can lose messages from your text logs that may or may not be in your systemd log due to truncation of the binary log in the case of a crash, and this is a fact.
The other issue is that journald has to perform a conversion on the log message to put it into text format. Based on all the other bugs with journald, I have no faith that this conversion is done in a way that correctly maintains all information.
sysvinit is still there, so just don't install systemd.
Explain, in detail, how to accomplish this on CentOS 7. I keep hearing systemd proponents say this, but nobody backs it up with a real-world example.
I don't even care if the default install disk forces systemd and your explanation is how to remove it, even though it isn't "just don't install systemd" as you claim is possible.
I do, however, care about being able to install real world packages, although nothing related to a GUI. But, things like apache, sendmail, mysql, samba, and cups are requirements.
I've followed many discussions on forums of people having trouble with a daemon and the debugging of that demon is made MORE complex by the fact that it is managed by systemd.
Exactly so. When all else fails with SysVInit or even upstart, you have a shell script that you can run from the command line, and could have added some debugging statements.
With systemd, you have to hunt through layers upon layers of files and links to find out exactly what executable is being run, and with what options.
As a very part-time server admin, I do in fact care about boot times
You really aren't a server admin, are you? How long does your choice of Linux distribution take to boot from the time grub gets control? And, how long is that compared to the time it takes the BIOS to verify the hardware on a typical physical server? For every system we have, the hardware check is literally orders of magnitude longer. It take less than 20 seconds for a system to be usable after grub starts (and that's one of our more complicated configs...generally, everything is up within a few seconds), while it isn't uncommon for the hardware check to take 3 minutes.
Yes, one could argue that all of those should be in their own little VMs, but if you're doing security updates, it boils down to having update everything sooner or later - might as well have it all on one machine.
Again, you aren't a Linux server admin. If you have a good VM infrastructure, it costs almost nothing to run another VM that uses the same OS. In addition, with the exception of kernel updates, reboots aren't required for Linux patches (okay, maybe one in a thousand). Yes, you might have to restart a service to get the new binary running, but since you've already tested this in your dev environment, you know it's just a simple restart. What...you don't have a dev environment? Again, not a sysadmin.
And with systemd I can finally be sure if Apache started or not
Really? How can systemd be sure that Apache has started completely and is ready to serve pages?
The answer is...exactly the same way every init script is "sure" that a service has started. It checks for the running instance, it checks PID, etc. But, unless it actually connects to the correct IP and port from a permitted IP and retrieves a web page that says something like "yeah, I'm running", systemd doesn't know.
I written service-monitoring scripts, and what systemd does isn't it, and is fundamentally no different from what is done by current init scripts. The difference is the current init scripts won't kill and restart Apache because they "think" something has gone wrong.
If systemd is so very very wrong then people wouldn't use it right? Certainly no major distro will go out of their way to adopt something wrong.
systemd solves problems that are mostly associated with systems that have users who log in directly using a GUI. Most major distros have a strong "desktop" following, and as such, are interested in systemd.
Unfortunately, for the vast majority of systems that run just fine without the need to notify logged in users that a USB device has been hot-plugged, systemd doesn't offer much compared to the learning curve required to figure it out without documentation. In addition, the systemd environment (since it's not just one program) has bugs, and unlike older programs where the bugs and failures are known and can generally be worked around, this is not the case for systemd.
Well, back in the early '90s, Texas A&M used lots of GM, and lots of students drove GM as well.
Interesting. I never heard anything about that, and the group of people I hung around with were just the sort that would pull that kind of stunt. I left in 1995, though, so maybe it was a little later.
The problem is lost keys. There has to be a mechanism for an automotive dealer or manufacturer to replace lost keys, and it has to function without the original key.
Why?
If you have no key available for the car, the car's private key can (and should) be wiped and replaced with a new one, and the key fob given the matching public key. Again, this is assuming that the system uses public key encryption (which it should) and that you have physical access to the car.
It's not like BMWs are bargain basement cars, surely they could have spent a bit on an actually secure keyless entry system.
The problem is that the only right way to do it is a public key-based challenge/response system. This prevents replays from snooping, keeps the keys secure (they never leave the car or key fob), and essentially prevents brute force.
The issue is that this requires the key fob to have both a transmitter and a receiver, plus more computing power, making it larger, and would likely run the battery down pretty fast (even if the receiver is only powered for a few seconds after a button is pressed). Nobody wants to replace their key fob battery every few months.
On the other hand, the biggest hazard facing a cyber warrior is likely to be the morning commute.
There are a lot of computer attacks that must be done from inside a network, either because it isn't connected to anything else or because firewalls are good enough to stop outside attacks. This might require being on the ground somewhere that being shot at is possible.
The solution is to relax the physical requirements, not toss them out completely. The military could allow someone to join who doesn't meet standards, but every year after that, they would have to get closer to the standard, and maybe even eventually meet the same ones as every other soldier.
"private businesses are still free to specify which forms of legal tender they will accept. If a shop doesn't want to take any currency larger than $20 bills, or they don't want to take pennies at all, or they want to be paid in nothing but dimes, they're entitled to do so"
The exception to this is if you are in debt to the private business. In that case, they must take cash, as it is "legal tender for all debts, public and private". Note that coins are not cash, so they can pick and choose about coins they will accept.
For any regular store, you haven't incurred a debt by the time you are ready to pay. Restaurants, on the other hand, generally have to take cash, as all but fast food serve you before you pay, thus it is a debt.
If he wants to upgrade to 4K or something he'd need a new video card, which should contain enough of it's own processing ability that all all the computer has to do is feed IT the minimally preprocessed video stream for decoding and display.
The Mac Mini has no component that can be upgraded other than the RAM (which is limited to 16GB). The video controller is soldered onto the motherboard, and there are no expansion slots. Thus, if you want to do anything with a particular model Mac Mini that Apple didn't anticipate, you have to buy another computer.
No point nitpicking just because the "b" denoting Megabits was forgotten.
It's not nitpicking because there is a vast difference between 200MB/sec and 200Mbps (about 25MB/sec). It's trivial to get 100MB/sec over gigabit Ethernet, and you don't have to spend a lot of money to do it. I've got a case that will hold 15 3-1/2" hard drives, and the guts (case, motherboard, RAM, RAID card, hot swap bays) cost about $1,500, which is a lot less than the Synology case without drives. I use 2TB drives because that's what I needed at the time, but could have the same 60TB as you if I used 4TB drives.
That machine also has a 10Gbit NIC, and when using that, I get around 600MB/sec transfer to this server. Now, part of that speed comes from the $350 I spent on 480GB of SSD cache for the array, but that's an option I have and the Synology doesn't. Even without the SSDs, 350MB/sec was the speed I saw. So, 25MB/sec for all the money you spent is pretty lame.
A speed of 200Mb/s is not huge but it's not too bad either, even though a fairly old machine (6 years) with a few disks in an array can get close to five times that and saturate gigabit (or even twice over if a second connection is going somewhere else).
Again, 200Mbps is terrible for transfer across a gigabit network. Even a single drive source should be able to supply 240Mbps, with any array easily saturating the link.
Also, you don't need disk arrays anymore...single SSDs will max out gigabit ethernet and give 10Gbit a run for its money. With arrays for the large data, fronted by SSD cache, fronted by RAM (again, lots of RAM is cheap, but not really an option for the Synology), even 10Gbit isn't up to the task.
My 2011 mac mini will last well into 2020.
That really depends on what you do with it.
If you need to run software that uses 20GB of RAM (very likely 5 years from now), you're SOL. If you want to play the latest games at high resolution, or want to drive a 4K monitor, you're SOL. If you want to use a USB 4.0 or Thunderbolt 3 (for example) peripheral at full speed, you're SOL, and depending on the updates to some of the connection standards you might not be able to use it at all.
These aren't all flaws with the Mac Mini specifically, but rather any computer with no generic (e.g., PCIe slots) upgrade options. Still, an only slightly larger form factor (mini-ITX) can often give you at least two slots...one for video and one for something else, and most generic motherboards offer more memory slots than you get on any all-in-one from any company.
180-200M/sec throughput is the norm. On the network.
You have a 10 gigabit network? I ask because a 1 gigabit network can only provide 125MB/sec throughput. I know that some of the Synology units offer link aggregation support, but that also usually requires support in the switch and multiple network cards in each client.
That said, even 200MB/sec isn't particularly good if you can only provide that total to one client at a time, especially for the cost of a Synology enclosure that can hold enough drives for 60TB of storage.
Most crimes have a "Mens rea" requirement - an intent to commit the crime.
Unfortunately, most of the time the law is actually enforced such that merely intending to commit the act that turns out to be prohibited by law is considered "intending to commit the crime".
As an example, driving 55mph in a 35mph zone can be punished regardless of whether you intended to drive over the speed limit. Likewise, breaking some obscure law can still be punished even if you didn't realize what you were doing was a crime. So, if Aunt Tilly intended to send that emoticon, then she can be prosecuted regardless of whether she intended harm. As the GP noted, she likely wouldn't be, but someone not as sympathetic might be.
The problem is MS never had a small tutorial during windows installation or during the first boot showing users how to create a Standard User account and have an administrative account for elevating your rights for doing administrative stuff.
The actual problem is that unlike Linux, doing this doesn't help you do a lot of the "administrative stuff" you need to do in Windows.
In Linux, a normal user with sudo permission can run "sudo su -" and everything run from that terminal will have admin privileges. You can do the same thing in Windows with "RunAs" either from a command prompt or from the Start Menu with Shift+RightClick. The problems then start. First, you have to figure out what command to enter to do something that is normally only done with the GUI. Then, you have to remember that everything is being done as the admin user, so any changes don't get put into the normal user's profile. This causes problems for some programs that don't have the "install for all users" functionality set up correctly.
In addition, there are some things that stupidly require elevated privileges but affect only the current account (like Control Panel->System->Advanced System Settings->Performance), which are thus impossible to change if your account isn't a member of "Administrators". There are also some things that even "Administrators" don't have permission to do, but "Administrator" does. And, there are some things that can't be done because you can't actually become the account that you need to be in order to do them (like "TrustedInstaller").
if you're not watching the ads, it means jack squat to the producers.
The producers of the show only care tiny bit about advertising, as they get their pay up front (a TV channel/network pays them to produce the content) and from various forms of direct sales (DVD, Hulu, Amazon, etc.). Because much of the value of a show has moved from the first-run airing, networks now partner with producers to produce the show, so that the network also gets a cut of the direct sales.
So, producers care a little bit about ratings and advertising, because if nobody is watching their show, they won't get any more money to make it, but as long as enough people watch in some form that puts money in the producer's pocket, the show will still get made.
Sure you can. systemd-ask-password is not even linking systemd.
Which isn't important when all communications between the two is via IPC.
I assume you were exaggerating, but just to be clear: it is not necessary to run all of the programs which make up the systemd "brand". With the exception of a few core dependencies like journald, you are free to pick the components you wish to run.
So, you've tried this? Either by compiling one of the "extras" and running it on a system where systemd isn't installed, or by completely removing the extras and running alternatives that give the same functionality?
Didn't think so.
in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.
The current init system has always done this, buffering up log entries until the logfiles are available. How else do you think dmesg has entries from milliseconds after the kernel starts?
The developers of systemd have all of those separate apps and daemons in one code repository, but you can pull each of them out and compile each of them separatly.
But you can't run them separately.