Still an order of magnitude more complex than systemd.
Actually, its not. In FreeBSD, the
Then what are we discussing? Use your old style sysvinit.
Usually you can't just disable SystemD, and the tendency (IE it WILL happen), sysvinit will be removed. Try CentOS or Debian w/o SystemD and let me know how well it goes.
I don't know again what you mean. The sysvinit init scripts are still working.
They aren't, at least not fully. This requires an extra step in SystemD, to enable legacy processing of rc.d scripts.
The journald is used internally by systemd, and services can opt-in to use it.
Its not really op-in, is it? if SystemD generates diagnostic messages to journald instead of syslog or whatever you're using, you need to use it at least in some point. And when shit happens, systemD instructs you to use some crazy command to parse the binary logs, not a "hey this program is logging elsewhere". So, from a systemd user perspective, there is no other logging facility - error messages instruct you to parse journald, not to check the application log in
At least systemd captures sysout and syserr into the journal, so it's not lost
Precisely. Its not opt-in. And when you manually startup scripts, it captures the useful information the program is outputing *at that instance*.
Another huge improvement over sysvinit. How many times I had to start a daemon manually so I can see the errors from syserr.
Most daemons will log the relevant messages. And its actually trivial to enable logging of those on your startup script, if you want it (and some programs, like crontab, already have them). What we have now, are deamons silently failing and requiring an extra command to understand why.
But again, the MySQL logs are still there in
No, they aren't. In many Linux distros MySQL is configured in
Then you want systemd. As I mentioned before, the sysvinit start scripts are huge, complicated and error prone (the loop in Apache init script). In systemd all you have is a 17 lines file for Nginx: https://projects.archlinux.org... [archlinux.org]
Your argument is a bit flawed. You can actually bootstrap apache with a single command (apachectl start) you can include in
systemd adds a lot of extras, and does not take anything away. It adds, a) info on whether the service was started, b) automatic restart of crashed services, c) journald, d) limit resource usage per service, e) simple and powerful service configuration files, f) inter service dependencies management (start Thin only if Nginx is started, or start MySQL after Apache) g) a lot of tools that were missing like systemd-ask-password.
...None of them are useful to me. a) Info if the service is started or not is standard in every rc.d/init.d system I know, via the service command or other methods. b) the LAST thing I want is automatic restart of crashed services. I want to know it crashed, and investigate why (automatic restart easies the process of remote code execution in network daemons). c) journalD adds nothing useful. If I wanted my logs in a database, pretty much half of the loggers available have that option. d) this already exists in (every?) unix system. Its called process accounting and limits. Dependency managent is a solved problem - either via explicit ordering as in traditional linux systems, or explicit dependency enumeration in FreeBSD/NetBSD. If you think this is a cool feature, you've been living under a rock for the past decade or so. g) systemd-ask-password is a prime example of a cool feature that has *nothing* to do with the init process, so it should not be part of it.
And systemd does not take anything away from you. You can still use all your old school tools and your old style logging, and even the old sysvinit scripts.
Theoretically. In practice, it overrides the way sysvinit works, and you need to explicitly re-enable it.
"but if not, why the f*ck is it taking control over MySQL initialization? " What do you mean by that? It starts the service and watches the service that it is really started, and it gives you info that it is started or it didn't started or it crashed. For example, on my laptop:
Try it with MySQL. Your output actually has useful info, in MySQL's case, it doesn't, as systemd isn't capturing the program's log. And what if I had multiple mysql copies running?
In the end, systemd adds nothing to the existing process. Maybe stuff boots faster on a laptop, but I don't really care about startup times. I care about reliability and being able to fix stuff when it breaks. Again, systemd stands in the way, its not a help. If you feel intimidated by a 9Kb shellscript file, It may be suitable for you, but it's not for me. I prefer to dig around a small shellscript file than to have to read manpages and google stuff dispersed on the internet.
You can take your MSDOS and boot it on your new i7 computer.
You're mixing ISA (Instruction Set Architecture) with ISA (Industrial Standard Architecture). Two completely different things.
you could easily make a LPC to ISA adaptor in a FPGA
Good for you. I'd be a bit skeptical about that (at least with full compatibility, including DMA & IRQ support), but never tried it.
But I guess you are trying to insert some non-existent expert knowledge or something?
I could say exactly the same about you. The difference is, I don't automatically assume everyone is wrong, nor that they are assholes. Different perspectives, I guess.
Also referred to in the past as the ISA (Industrial Standard Architecture)
ISA is actually a set of standards. Many/most XT ISA boards won't work in AT systems and vice-versa. Your parallell port may work, but a SCSI card may not.
PCs still are compatible with the old standard
Hum, no. ISA has been dead at least since the Pentium IV days, and even then it would require extra circuitry to use it. Maybe some modern industrial PCs still have it, but I'd guess its mostly emulated. DMA and IRQs are handled differently, bus timings and AFAIK voltages are different.
- today's x86
Its not from today. It has been happening for the last, huh, 20 years or more. Started with Pentium Pro.
I only did it to say I did, there was NO software to install on it
Just like in Alpha. Not even software from MS would run on that
With netstat you don't even need to know the service name (I actually never use servicenames). There is a table for that in most (all?) unix systems, in
What I want is quite simple. To be able to configure and manage stuff with the least hassle. SystemD is a stone in my shoe, not a solution. And its not because I'm BSD-centric (I am), its because it hides complexity AND useful info. I'm fine if MySQL isn't logging into SystemD, I really don't care - but if not, why the f*ck is it taking control over MySQL initialization?
I've worked with SMF in Solaris. Coming from a BSD background, its a bit of a steep learning curve, because it works quite differently from the init.d/rc.d approach. Some operations are overly complex, some ways of doing stuff are convoluted, but I could see the added value in the tool. I see none in SystemD.