41–50 of 89 posts
Earlier quoted context omitted.
Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?
I switched all my servers and desktops to FreeBSD. It's like going back in time in many, many good ways (commandline/text-config focus, less magic, etc.), and one bad way (HW support).
Earlier quoted context omitted.
I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1]. All good lessons learnt from package managers? Gone. Nix? Forgotten. Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the…
> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. > However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind…
Ahh, there's the talking point I mentioned in my earlier post[1].
What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).
As an example in the opposite direction, consider busybox. While it compiles into a single binary, the features provided by busybox are very modular. You could remove any of the utilities it can emulate without that change cascading into lots of other unrelated features (with build system support), and I could replace any of the utilities with something else (i.e. the standard non-busybox version) by simply removing a symlink.
Systemd is designed in the opposite manner, on purpose. They put every but of code the project absorbs into the same repository, claiming it makes development easier. Of course it does... initially; you get to skip the all those clearly and rigorously defined interfaces. They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run.
[1] https://news.ycombinator.com/item?id=9515413
[2] See the "Rule of Modularity": http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
Earlier quoted context omitted.
Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?
Particularly that it doesn't work. I always hear about people for whom It Just Works, but that hasn't been the case for me over the course of a couple handfuls of machines. For what it's worth, LP and his gang seem like people for whom "it mostly works" is satisfactory, and that's not something I'm comfortable with in something like an init system, to be frank, because what about when it doesn't? The answer there unf…
Earlier quoted context omitted.
Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout. Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Un…
Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy": > Write programs to handle text streams, because that is a universal interface. ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming : > Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. > Before devisin…
Earlier quoted context omitted.
Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout. Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Un…
That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.
Earlier quoted context omitted.
I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1]. All good lessons learnt from package managers? Gone. Nix? Forgotten. Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the…
Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands... This is exactly the same as the virtualization scenario, where you might have hundreds of possibly vulnerable virtual-machines running under the same virtualization platform (which maybe Linux). Or lots of Docker containers, some of which may have vulnerable software. App-containerization…
Solaris has had this with zones since, IIRC, before Oracle bought Sun.
Earlier quoted context omitted.
we run a ~70 node system, ~95% virtual/5% physical, almost fully converted from Scientific Linux 6 to CentOS 7 (only the NFS boxes left!), which is systemd based. Concerning systemd as an init system, it's been extremely reliable and simple to use and manage. Writing unit files, even ones with complex requirements, is incredibly easy, because the FDO documentation is really terrific. For instance, we have a host runn…
I may be showing my gray ear hairs, but I remember the early days of Gentoo where ZOMG boot 3ms faster by optimizing! The init portion of systemd reminds me of those days. Your mention of requirements for service execution is certainly an interesting avenue for me to think about. Honestly for my day to day "spin up VM, do some experiments/coding, fine tune" it doesn't matter. For some other work I am doing dealing wi…
There is quite a big difference in that systemd was never designed to boot fast - it was designed first and foremost to boot correctly, and the much increased performance was mostly a happy accident of the design they came up with.
Earlier quoted context omitted.
Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?
Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.
I'm looking forward to 2 or 3 years from now when we can look back and laugh at all the fear and apprehension about systemd. That said though, I did just recently upgrade to Ubuntu 15.04 (which is all systemd now) and it is noticeably slower to boot up compared to my old upstart-based 14.04 LTS install. Hopefully there's some more optimization that needs to be done to bring the boot-up speed to parity with the previo…
I really like that you can now use systemd-cat with logfiles because regular cat doesn't fit anymore.
Earlier quoted context omitted.
> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. > However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind…
> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. Ahh, there's the talking point I mentioned in my earlier post[1]. What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do t…
What you're not understanding is that these other binaries do not run as PID 1, which is what nextos wrongly claimed.
> This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).
Which is the exact opposite of what has happened during the sysvinit times.