6 ms·
> And now systemd adds to this. What the flying fuck? While I agree with you that these layers of caching can lead to headaches, Linux doesn't have a built-in
by ominous_prime 12y ago
> And now systemd adds to this. What the flying fuck?
While I agree with you that these layers of caching can lead to headaches, Linux doesn't have a built-in cache (and distros often don't provide one by default). Systemd would be one way to provide this, instead of other daemons that have been used in the past, like nscd, dnsmasq or bind. So it's not adding yet another layer, just providing the layer at the local host.
As for technical reasons, I'm not sure what you want to hear, each layer implements a cache for performance and/or efficiency. No one throws in a DNS cache just because they feel like it.
- jacquesm 12y agoLinux doesn't need a cache, you can simply run a local DNS server. The kernel should not do more than it needs to do. (It's bloated enough as it is)
- ominous_prime 12y agoI don't understand your comment. a DNS server is typically also a cache, and this is what systemd was attempting to provide, without the public server part. It's the same thing that distros were using e.g. dnsmasq for. What does the kernel have to do with this? No one is proposing that the kernel should have a DNS cache.
- jacquesm 12y agoGP says 'Linux doesn't have a built in cache'. I presume (hopefully correct) that he means 'the kernel', since Linux doesn't have anything 'built in' that you don't run as a user process. The kernel of course has plenty of stuff built in but (fortunately) it tries hard to stay away from things that can and should be done in userland. Systemd is a user process and now tries to replicate functionality that we already had a perfectly good solution for. Since a DNS server is typically also a cache we already had this functionality (and more), simply make it listen to a local port and nothing else. That way you don't need to resort to rebuilding things we already have with incompatible interfaces.
- _delirium 12y agoLinux hasn't been just a kernel for a while; it's a kernel with some associated userland utilities that are developed together and normally expected to be present. That's been the case in the filesystem part for a long time; the userland fs-related binaries are developed in sync with the kernel side. Systemd is doing something similar with e.g. cgroups. Linux develops fewer things this way than the BSDs typically do, outsourcing a lot of userland to other projects like GNU, but it doesn't literally develop only kernelspace code. Imo it's generally an improvement; the situation with trying to get things like cgroups to work together with process management previously was terrible.
- jacquesm 12y agoThis is absolutely true, which is why linux is as large as it is and why you need certain stuff in order to bring up a functioning linux system. As for the filesystems they are modules plugged into the kernel (linked directly so you can boot our kernel straightaway or through a ram disk kludge as modules in linux, not the most elegant solution because technically that duplicates a buch of stuff but nobody seems to care too much) and a bunch of supporting programs, this has been the unix way since time immemorial, I think even the first unix I ever used had fsck. The reason those have to be kept in sync is simply because you don't want to run fsck on a filesystem that was built with a newer kernel that possibly has datastructures that your fsck (or other filesystem aware utility) accesses directly without going through the kernel. Essentially such programs re-implement a bunch of kernel functionality because they access file systems that are not currently mounted. Systemd on the other hand (in the case at hand) replicates the functionality of another user process that we already have, know how to use and have hardened over many millions of hours of use. That seems folly to me, it duplicates functionality, makes troubleshooting harder and increases the size of the codebase without actually improving anything. What's next? The framebuffer? Keyboard interface? TCP stack? There are no really hard reasons why those could not be user programs. It's fine with me if we make linux a micro kernel but let's do that in a way that we do not need to revisit the last decade or so of security issues and ill thought out interfaces. Once we start to need things like DBUS and X in order to bring up a server we've really lost the plot.
- rdtsc 12y ago> this is what systemd was attempting to provide Why does systemd need to provide it? I already provides enough things. Are there any bugs in : http://www.thekelleys.org.uk/dnsmasq/doc.html http://www.thekelleys.org.uk/dnsmasq/doc.html I had great success using that. Both installing it on my own or run it part of Ubuntu's base install. (And the answer of "but it already provides everything + kitchen sink, might as well provide DNS caching too" would probably not be what most people would want to hear).
- RexRollman 12y agoBecause it is the Emacs of init systems.
- josteink 12y agoDepending in your standing as far as emacs goes, that may actually be something good. I doubt you will find anyone interpreting this as such.
- parfe 12y agoEmacs is the Emacs of init systems http://www.informatimago.com/linux/emacs-on-user-mode-linux.html http://www.informatimago.com/linux/emacs-on-user-mode-linux....
- deleted 12y ago[deleted]
- ominous_prime 12y ago> Why does systemd need to provide it? I already provides enough things. I'm not saying it needs to, or trying to defend systemd. All I'm saying that systemd is providing and alternative to running another resolver.
- takeda 12y agoThat's pretty much systwhatemd is doing, except it is just subset of dns server that does caching.
- jacquesm 12y agoExactly, so imnsho this is simply wrong and should be un-done. Systemd should do those things that can only be done at init time and/or those things that need to be there and no more and leave the rest of the lifting to those tools that we already know how to use and that have stood the test of time. Otherwise we end up with 2 sets of incompatible tools with one of them not only re-inventing the wheel but replaying a whole bunch of security issues from the past on top. This is the worst case of feature creep in system land in a long time.
- VLM 12y agoThat is a good architectural design, but is in direct opposition to the projects mission statement of "embrace, extend, ..." you guess the third word. If a group is actively trying to ruin something, noticing that they're trying to ruin things isn't going to stop them. That's a useful strategy with accidents and friendly groups, but not with actively aggressive oppositional destructive groups. Mostly I'm just angry about having to waste the labor hours moving everything to Freebsd from Debian. Its interesting, but not exactly productive.