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.
DoublcClick has such negative value that their servers should be blocked at firewalls, or at least "host.txt". Even if you have AdBlock, blocking them earlier saves bandwidth.
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
Frankly speaking, I'm mostly surprised that this doesn't already exist.
It does. There's a Craiglist-type feature on Bloomberg trading info terminals. Yachts, rentals in the Hamptons, that sort of thing. You can message other people via the Bloomberg system if you see something you like.
There's a paid social network for rich conservatives. This is independent, not a Bloomberg thing. It's only $5/month, which is apparently enough to keep the noise level down.
There's a persistent rumor that there are special news sources for rich people. There are, but they're very narrow. There are lots of newsletters you can buy for $50 to $1000 a month that provide detailed coverage of obscure business subjects. If you really need to know what's going on with bulk carrier leasing, oil drilling equipment activity, or wafer fab capacity shortages, there's a newsletter for that. Offshore Alert, which covers offshore scams, is one of the more readable ones, and you can see the first few lines of each story for free. There are expensive newsletters devoted to security and terrorism, which give the illusion of inside information, but they tend to be marketing tools aimed at rich paranoids.
If you want to know what's going on in the world, read The Economist. After you've been reading it for a year, you'll have a good understanding of how the world works.
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.
The weak prey on the weakest.
Eurasia is at war with Oceania. Eurasia has always been at war with Oceania.
Minecraft, Lego, Mechano...all branches on the same tree. I don't have children, but if I did I would rather they play Minecraft than CoD Whatever: The Sequelling.
Best of luck to Notch. Hopefully MS are good stewards of the property.
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.
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.