6 ms·
really unix philosophy, isn't it?
by blackle 11y ago
really unix philosophy, isn't it?
- andrewstuart2 11y agoI'm not sure the systemd guys want to build with the unix philosophy. I don't have a definitive source (maybe SE radio podcast?) but I seem to remember one of the authors saying as much. They're more interested in what Linux can become than what unix was. Not that I agree, but I believe that's what they said.
- agumonkey 11y agoLennart Poettering has a different view on Unix philosophy, it's more 'make it interesting and do what you need to'. I think nobody is right or wrong. This is all growing pain and, as I often say, at the right time I'm sure there will be tinier systemd-like built to be more Unixy (as in 'small set of smaller composable tools').
- blueflow 11y agoSomething like systemd except being ONLY an init system would be really great.
- rascul 11y agohttp://uselessd.darknedgy.net http://uselessd.darknedgy.net
- mercurial 11y agoThis looks surprisingly tempting. I agree with a lot of the ideas behind systemd, but at the rate it is growing, I'm going to type this in systemd-firefox in systemd-xmonad in six months. How stable is it in practice?
- chris_wot 11y agoI can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm. What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
- mercurial 11y agoI like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.
- chris_wot 11y agoI challenge you to show me what part of systemd isn't directly related to inititialization of services.
- agumonkey 11y agoMaybe the parameters and interface will simplify over time. Patterns emerge with use.
- chris_wot 11y agoYeah, that doesn't answer my question. What isn't necessary?
- agumonkey 11y agoI don't know all of systemd but : - journal - networkd - console Are already far from generic system config/init parts. These components are very nice and cleaner than older alternatives but it feels like unnecessary coupling. Also every release added magic variables to handle corner cases. They're proficient but complexity is increasing.
- blueflow 11y agojournald, logind. chrooting (nspawn). tty-ask-password-agent.
- chris_wot 11y agonspawn inits. journald - fair point. logind inits. systemd-tty-ask-password-agent is a password agent that handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime.
- andor 11y agoThat's just not their plan. They want to modernize and standardize (to reduce fragmentation) the whole userspace. Replacing init is a big, but far from the only part of the process.
- pdkl95 11y agoMost of the systemd people arguing about the unix philosophy have no idea what that philosophy is[1]. A common argument is to insist that breaking up systemd into a separate binaries made "not monolithic", while ignoring that the design is still totally interdependent. Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it. Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3]. /Sigh/ "Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer) [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html [2] Slackware was already on version 3.0! [3] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf
- vezzy-fnord 11y agoIn all honesty, people who want a working Unix would have went to a BSD or Solaris variant a while ago. GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier. The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
- rpcope1 11y ago>The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then. This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
- chris_wot 11y agoSounds 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 Unix philosophy but rather the design decisions of systemd.
- mveety 11y agoThat'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.
- chris_wot 11y agoNot sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.
- mbrubeck 11y agoDoug 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 devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools. (And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
- danieldk 11y agoWell, I guess you are also against SQL databases, aren't you ;). grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.