Water is not billed to you by consumption because in many places that is illegal. It is billed to your apartment complex ( ie property owner) by consumption, though. The Internet connection is almost certainly not. It is a flat rate to them and should be a flat rate to you as well.
Net neutrality concerns aside, unless this is a very unusual apartment complex, they are not an ISP!!! They contract to an ISP to provide Internet access to their tenants. Sure, they control the routers and and do some basic filtering, but they aren't really in a position to dictate peering terms and such.
35,000 across multiple college towns is very large? Maybe relative to other apartment complex owners, but relative to the total student population they are nothing.
Since water is billed by consumption and Internet usually is not, that comparison is not really relevant.
We've really entered bizarro-land in this discussion now that communicating over dbus has been declared wrong because it is the "Windows-way", whatever that means. Dbus is just IPC, that is all.
How about instead of misinterpreting what somebody said on a discussion forum on an unrelated matter, you read what the actual architect of systemd says.
Myth: systemd is monolithic.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
Myth: systemd is not modular.
Not true at all. At compile time you have a number of configure switches to select what you want to build, and what not. And we document how you can select in even more detail what you need, going beyond our configure switches.
This modularity is not totally unlike the one of the Linux kernel, where you can select many features individually at compile time. If the kernel is modular enough for you then systemd should be pretty close, too.
There are more of those here,
http://0pointer.de/blog/projec...
It should be able to identify an iscsi mount in fstab
How would it do that? Have you ever used iscsi? How about multipathing? It is not as simple as you seem to think it is. Autofs is another hack to make mount +
If systemd were being engineered in a manner appropriate for UNIX-like systems
The only thing about
The fact that it obfuscates these things is very much a design flaw.
Systemd doesn't obfuscate anything. Everything is very clearly documented, logical, and modular.
I *want* my scripts to be code.
Fine, until you want some basic security in your init process.
The UNIX way is to do one thing, and do it well.
If the scripts didn't need to cooperate to accomplish a task, you might have a point. But they do, which is why sysV init is broken.
Which is perfectly fine, as the parameters (if any are needed) are gathered at the top,
Uh, I don't know how you can think that rewriting the same 100 lines of code to do the same basic thing (but a little differently because everybody writes it differently) in 100 different scripts is a good engineering practice.
It's a monolithic lump
It is not, which you would know if you had bothered to gain even the most basic understanding of what systemd is and how it works.
Being difficult to understand is a definition of complicated.
Before you can claim that something is difficult to understand you first have to make an effort to understand it.
Systemd is openly trying to do pretty much 'everything' at startup instead of having multiple things that do one thing well working together.
It isn't really. Saying that "Systemd is mounting my filesystem, and bringing up the network, and setting my timezone" is functionally no different than saying "My collection of sysV init scripts are mounting my filesystem, bringing up the network, and setting my timezone."
Yes, trading bash scripts for a large blob of binary code that interprets another layer of text scripts is much less complicated, If you're just comparing the bash scripts to the large binary blob's scripts.
Some excellent sophistry there.
Look mate, anything new is going to require some effort to learn how it works. The only point I am trying to make is that it isn't really that hard, and for an app developer it should be trivial. Read the docs, learn how it works. That is all.
just because they're complaints YOU won't ever make (because you're the equivalent to a plumber with years of experience) does not invalidate their legitimacy.
It's funny you say that because I'm not. I'm just a guy who has read the docs and done some googling. To me, systemd is a heck of a lot easier to understand than GNU make.
Uh, they did actually. Each of those things was managed by an init script. They didn't just manage themselves.
The old shell scripts never yanked away system logs
This hasn't been done.
stole core dumps from out of your crashed program
This is actually quite useful.
forced system demons to be changed to conform to "the new way of doing things"
System daemons don't have to change, init scripts do.
Nice post. Complete FUD.
Does it? There's no reason for "its own" config files,
There is no reason for . Guess what, there is actually, and those reasons are documented on the systemd website.
Great, so you have a distro that does what you want. What is the problem then exactly? Not every distro is going to be like Slackware, and it shouldn't have to be.
- It breaks expectations of experienced Unix/Linux users.
I disagree. First of all because there is no reason to disregard something just because it acts a bit differently. Second, it is not as different from standard unix ways as people are determined to think. It is different from sysV, but even sysV was different from other competing systems at the time it was introduced. Not having console logging would be a serious shortcoming if it were true. Thankfully, logging is quite configurable and you can get almost anything you want from journald.
- Non-deterministic.
I would need some more information before I could conclude that it is non-deterministic. The only information I have at this point is "something stopped working." The cause can be any number of things which might be the fault of systemd or might not.
KISS is a principle because experience shows that simpler things work better.
A lot of people have been saying sysV is simpler with pretty much nothing to back it up. Systemd is not that complicated.
http://0pointer.de/blog/projec...
If systemd does badly something it is designed to fix
Understand the difference between "doing something badly" and being misconfigured. Nothing can work well if it hasn't been configured properly.
On a serious note: never tell me that I don't need to know how things work.
I didn't say that. You absolutely should know how systemd works. But that doesn't mean you will necessarily know the precise order in which things will start. Systemd has been designed to allow you to specify preferences and requirements, so that you don't have to specify order.
Correct me if I'm wrong, but if all filesystems are mounted early, then it does not matter where you have moved the service. How can it be easier than that?
When you can't mount all filesystems early, this doesn't work.
I'm not arguing it has to be syslog format, just text.
No argument from me there. I don't really understand the rationale of the binary log, so hopefully that will change in the future.
...until you don't GET the log because it wasn't *WRITTEN*,
In these situations you typically redirect the logs to a remote server, something that journald is supposed to be able to do very easily (I've haven't tried to do this yet). But I get your point. The problem with having only the console log, which was the case with most of the init scripts, is that you often don't have a console, or the console output is too long catch the error message. So the permanent log is a better place to put important messages. But I agree it is more convenient to have the console log as well as the permanent log in certain situations. Apparently this can be done with journald. Maybe it's worth a try.
http://log.or.cz/?p=327
Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log.
Agreed. Thankfully this is actually possible with systemd.
http://freedesktop.org/wiki/So...
How easy it is will depend on where the boot process failed, but it is possible to get to an emergency console in nearly every situation without rebooting.
don't *PREFER* an order, sometimes I *REQUIRE* an order.
Yes, you can require an order. But there is a difference between requiring a service (ex: apache requires net and syslog) and requiring an order (ex: net will probably come up first, but apache doesn't strictly require it to). If you do need a specific order, for example a service that requires a network filesystem to be mounted to get its config files, you use the Require combined with the Before or After directives.
http://www.freedesktop.org/sof...
In SysV, almost *nothing* happened before filesystems,
The thing is, not all filesystems can or need to be mounted at the same time, and this is not possible to encode within
I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy.
That's the thing, though. It really isn't any more complicated than modprobe.d or pam.d or if-*.d or any of the other config systems that compose a typical modern linux system. It is just new, and will probably require some reading of the docs. But it doesn't take hours. For most, it takes about 10-20 minutes to figure out how to do something you need to do with systemd.
I've gained *no* capability that I didn't already have
I think that's the problem. Too many people have a "works for me" mentality and don't acknowledge the possibly complex needs of other users. Ultimately, linux aspires to be as useful to as many people as possible, not only to the people who have succesfully used it up to now.
Six of your criticisms amount to "I don't know how systemd works or how to configure it." While I understand the frustration, it is not a shortcoming of systemd. If you didn't know how to write a shell script, or how runlevels worked, or how to handle your distributions special way of dependency orchestration, you would be saying the same thing about sysV. Systemd is a new way of doing things. It requires you to learn new things, but it is not as hard as you think. Certainly it is a lot easier to adapt to than some of the other fundamental changes to the userspace that have happened over the years.
- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
Technically, there is an easy way to look at the logs, it just requires a utility that is not cat or grep. But I get your meaning. Binary logs are certainly not my preference, but for tools that need to interact with and parse the logs, it is a necessity. There are ways to get your text logs back, though, and some distributions configure it this way by default.
- Failure to Log to the Console:
It is in the log. With sysV your were dependent on your particular shell script trapping certain errors and writing them to stdout (or not). With systemd, since the daemon follows the process of forking or attaching to dbus at every step, it collects all the debug information it can and sends it to the log. So "journalctl blah blah" is exactly how you get those messages.
- Failure to Drop to a Shell When It Breaks:
Once again, it is in the log. I'm not sure why being dropped to a busybox shell gives you a much better way to debug than just reading the log messages. If you want to test individual systemd services, you can do that with systemctl start/stop/etc.
However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
If that is true, it is a bug.
- Races: I no longer have any idea what order things are starting in.
If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. That is exactly the problem that systemd is designed to fix. You don't know what order services are starting in because you shouldn't need to. The only thing your unit should do is specify a preferred ordering. That is it. Systemd handles the rest.
SysV is just shell scripts. I *DO* deal with *those* every day so it's pretty easy to debug.
Have you every really had to deal with the complexities of the sysV init system? It is not pretty. "Jiggling the cord" until it works is about all you can reasonably do with sysV when you have a complex init.
I'm not entirely sure where systemd mounts filesystems, but it breaks *HORRIBLY* if you move some of the files needed by a service onto a filesystem that's not a "normal" filesystem.
It doesn't "mount filesystems" at a single time during boot the way sysV does. You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.
From all outward appearances, the developers have *no* interest in fixing much of any of those complaints.
Well, this is more of a rant than a series of legitimate complaints. You can't expect the systemd people to understand your issues if you haven't even taken the time to learn how systemd works first.
Intel CPUs are not defective, they just act that way. -- Henry Spencer
