journald delivers ascii logs in real time, you just have to use a syslog daemon like you always have anyway.
Sure. So now I get an additional log daemon which doesn't feed logs back upstream. Explain how this is simplifying my system.
They claim they're moving things, not removing them. If done well this will help KDE immensely because current prefs dialogs treat trivial and significant settings as equally important by barfing them all up together into a big dialog.
The awesome structured and indexed log file format has a stable API and structure
Odd, so does a syslog. And you can still use tools to read it. Indexed files could be built from it if you had that much logging done. And since systemd has no option to output the ascii log in realtime, you have to use the tools. If you want to use the body of existing tools which do things with normal log files, you'll now need a FUSE filesystem to treat the binary logs like real logs, or you'll simply be out of date as you read the ascii logs from journald.
android-x86 is a bit of a dog's breakfast. They only kick out a release image every now and again, everything never works, lots of crashes. The latest 4.4 image is way less stable than the last 4.0 image they put out, and they stopped building nightlies and so did everyone else. It's really quite useless and always has been, because they never actually finish a release. Google kicks out a new version, they say "Ooh, shiny!" and they move on before they actually get the system working reliably or properly. Then you get to deal with all the apps that won't work right on x86 on top of that. It makes far more sense at this point to go ahead and run the emulator.
As Chinese economy grows, so does its middle class. As its middle class grows, it demands more democratic reforms and more government responsibility
Well, maybe. Or maybe it just demands a higher standard of living, one which cannot be supported without more oppression.
The chat messages are full of nasty, hateful language. It seems to me that the user experience varies greatly from one server to another.
too true. I like the servers with chat filters, which bring a level of amusement to the situation when the chat scrolls with tales of bananasing female dogs and so on
Logging isn't done by or in PID1.
You have fallen into my trap: So then why did it have to be part of systemd at all? Why couldn't it just be improvements to one of the existing syslog daemons? Answer, NIH.
They think it's about limiting yourself to pipelines, but it's not. It's about writing simple robust programs that interact through a common, relatively high level interface, such as a pipeline. But that interface doesn't have to be a pipeline. It could be HTTP Requests and Responses.
It's an ASCII pipeline any time that it's feasibly and meaningfully human-comprehensible; that is part of the Unix way. Any other time the format varies broadly, and has been all sorts of things including BDB — which has all the same problems as binary log formats ala systemd. Since the user-perceivable output of javascript in a browser is XML, you reasonably could use STDIO in a very normally Unix-y way.
Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs.
None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.
If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.
cgroups is a kernel feature. It doesn't stop working because whatever process you're using for cgroup management dies. The process comes back, reads the state from
The only reason that we even need a daemon for cgroup management is that we're making inadequate use of capabilities. When a user (or script) runs a tool which creates cgroups via a mount, they should not need to use any tool for privilege elevation because they should have the right to manipulate one or more cgroups in one or more approved ways — which can consist of a couple of lines in a file which is sourced by init scripts. In systems with init scripts of any complexity, all of which source external files, no changes need appear in them whatsoever.
Even with a[n old, slow] HDD it only takes about a minute to boot my Ubuntu PC, and that's with a stupid-long POST to deal with the second ATA controller's stupid-long POST added to the base machine's stupid-long POST.
With that said, I am not against improvements to boot speed. I simply question the need for a replacement for PID 1.
If you define "has" as "has within a mile," then you're absolutely correct. If you define it as "has passing the home," then definitely not.
I live on a paved road and I'm several miles (at least three) away from fiber. Literally the only company with fiber into my county is AT&T, and as you likely know, they are bastards of the first degree.
Minimum standard for what? 2014? Per individual? Per family? Per household? Per block? Per neighborhood?
Please try to keep up.
1. Standards change. 10Mbps might be an acceptable minimum today, but it certainly won't be in 2024, let alone 2054.
1. Standards change.
The devil is in the details.
So is the wankery of your comment.
Basically everything is doable at 10Mbps. It's an acceptable minimum standard. We'd all like to see more, but at least they're setting the bar someplace livable.
cgroups existed before systemd.
the cgroups functionnality existed in the kernel but wasn't really used that much before. [...] whereas current
Yes, my argument was that altering the init scripts would have solved most of what systemd solved. Thanks for confirming that.
each script end up fucking things up in its own original and different way.
The scripts are unified by maintainers. I've already made the proposal that you could actually interpret unit files as init scripts, with the right parser which basically stripped out the sections in brackets, dumped the rest of the content of the file into a series of variables by sourcing it, and then running a unified init script. This would work just fine for any daemons which are long-running, without any complex work. All you'd need is a hashbang at the top of the unit file.
proper handling of dependencies at runtime
Already handled by several init systems.
None of which are the original sysvinit.
Congratulations, you just hammered home the point that you don't understand Unix, while simultaneously proving that you don't understand sysvinit. Using fancy scripts with the original sysvinit is still using the original sysvinit. You are witnessing the awesome power of the Unix philosophy. Because sysvinit is small, simple, and completely modular, the scripts could be extended to provide functionality which sysvinit didn't try to claim for itself. Instead of moving more functionality into PID1, the functionality can be implemented at the script level.
Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
Why do we need 83 different way to start some code ?!
Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?
You failed to understand the Unix way. It's not to have one piece of software. That's the systemd way. It's to have many pieces of interoperable software which can be combined to perform complex tasks, and reconfigured to perform other complex tasks. So we have cron and at (which are often merged) and we have udev and inetd. And each of these things does one simple thing. It's not unusual to want to start processes in multiple ways, that is in fact common to all modern operating systems. You can start them from the command line, you can schedule them, you can start them from the GUI. Is that a problem for you?
Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.
And you still do. Only now, they're all managed by one process which, if it craters, will not just cause them all to fail, but which will cause a panic. Great idea!
if you don't like it, don't use it.
That's getting harder to do as people depend on it. I may finally have to go back to BSD.
He has not acquired a fortune; the fortune has acquired him. -- Bion
