Forgot your password?

Comment: Re: Remove It (Score 1) 521

by t_hunger (#48175491) Attached to: Debian Talks About Systemd Once Again

Yeap, the indexing in the journald files does increase the file size. That does speed up searches though, so it does have its advantage.

But systemd also logs a lot more than syslog ever could. This includes a lot of meta data (e.g. systems unit that started a process, cryptographic hash) for each entry as well as more entries (e.g. stdout and stderr from all daemons).

Comment: Re: Hope! (Score 1) 521

by t_hunger (#48175443) Attached to: Debian Talks About Systemd Once Again

What does systemd make worse?

I can e.g. restrict services far more effectively since I switched my machines to systemd. I really appreciate that. I also find the socket activation really convenient and am really happy to be rid of that horrible crontab syntax. Networkd works like a charm and debugging became so much easier since the log output is finally complete.

So far I have yet to find anything I miss from sysv unit.

Comment: Re: Hope! (Score 1) 521

by t_hunger (#48175385) Attached to: Debian Talks About Systemd Once Again

Why journald?

Because systemd logs stuff that is not accessible to syslog and thus needs an interface to buffer (e.g. before syslog is up) and forward that information to syslog.

That system grew up to handle most of the things syslog also does. So syslog was made optional, so that small systems have one less service that they need to run.

Send like a sensible decision to me.

Comment: Re: Some Sense Restored? (Score 1) 521

by t_hunger (#48175337) Attached to: Debian Talks About Systemd Once Again

The complexity of systemd is in stand-alone executables running inseverly restricted environments (no access to /home, private /tmp, read-only /, no network but through one file descriptor, etc.). That is a huge step forward.

This is especially true considering that the systems complexity is also running as separate, far less restricted services on non systemd systems (e.g. cron, xinetd, nwtpd, etc.).

Comment: Re: Some Sense Restored? (Score 1) 521

by t_hunger (#48175171) Attached to: Debian Talks About Systemd Once Again

How should that work? You need cgrouo support in the init system for that. Do you seriously think that is ever going to be added to sysv init?

Having some external process managing cgroups for init itself can not work, except by having init start the cgroup manager and then having that start everything else.

Comment: Re:Once again proving ARM is awesome (Score 4, Insightful) 97

by marcansoft (#48160329) Attached to: Android On Intel x86 Tablet Performance Explored: Things Are Improving

Um, no, x86 CPUs are nothing like ARM and I'm not aware of any commercial x86 CPU with an ARM backend. Yes, modern x86 cores use a RISC-ish microcode backend with an x86 decoder frontend, but that doesn't say anything in favor of ARM. All it means is that the industry has collectively agreed that CISC as a microarchitecture is a stupid idea - not necessarily as an instruction set.

I'm not a fan of x86 myself, and I think it's a stupid design with a vast amount of baggage causing a significant power/performance impact when designing an x86 CPU (that Intel can get away with because they're a generation or two ahead of everyone else in silicon tech), but then again ARM isn't the pinnacle of RISC either (though I do think it's better than x86).

Me, I'll take whatever microarch gets the best performance per watt at whatever TDP is relevant. If Intel can pull that off with x86-64, by all means. If ARM AArch64 ends up ahead, awesome. If both are about equal, I'll take whatever's more practical based on other factors.

Comment: Re:Duh! (Score 1) 75

And since this is a camera passthrough, not an optical overlay, that's a glaring implementation flaw. Properly aligning the head tracking framerate, camera framerate, and rendering would let them render the virtual objects in lockstep with the physical ones (at least at speeds where motion blur isn't a significant issue; you can fake that by minimizing motion blur in the real image by using a short shutter time on the cameras).

Comment: Doesn't look unreasoanble (so far) (Score 3) 192

by marcansoft (#48009543) Attached to: NVIDIA Begins Requiring Signed GPU Firmware Images

So, they're locking out things that can brick the card (flash ROM/fuses, screw up thermal sensors) and apparently a hint of OS security (the Falcons that respond to userspace commands can no longer access physical memory, only virtual memory). The latter sounds somewhat bizarre, considering the firmware should be fully under the control of the driver, not userspace (I guess/hope?), but not unreasonable. Maybe there are software security reasons for this.

Nouveau is free to continue using its own free blobs or to switch to nvidia's. If they start adding restrictions that actively cripple useful features or are DRM nonsense, then I would start complaining, but so far it sounds like an attempt at protecting the hardware while maintaining manufacturing flexibility for nvidia. This isn't much different from devices which are fused at the factory with thermal parameters and with some units disabled; the only difference is that here firmware is involved.

NV seem to be turning friendlier towards nouveau, so I'd give them the benefit of the doubt. If they wanted to be evil, they would've just required signed firmware for the card to function at all. The fact that they're bothering to have non-secure modes and are only locking out very specific features suggests they're actively trying to play nicely with open source software.

Operating Systems

Outlining Thin Linux 221

Posted by Soulskill
from the tux-on-a-diet dept.
snydeq writes: Deep End's Paul Venezia follows up his call for splitting Linux distros in two by arguing that the new shape of the Linux server is thin, light, and fine-tuned to a single purpose. "Those of us who build and maintain large-scale Linux infrastructures would be happy to see a highly specific, highly stable mainstream distro that had no desktop package or dependency support whatsoever, so was not beholden to architectural changes made due to desktop package requirements. When you're rolling out a few hundred Linux VMs locally, in the cloud, or both, you won't manually log into them, much less need any type of graphical support. Frankly, you could lose the framebuffer too; it wouldn't matter unless you were running certain tests," Venezia writes. "It's only a matter of time before a Linux distribution that caters solely to these considerations becomes mainstream and is offered alongside more traditional distributions."

Faith may be defined briefly as an illogical belief in the occurence of the improbable. - H. L. Mencken