Thanks! I have to admit that I wasn't able to make heads nor tails of Resterm. It may be above my pay grade.
I'm all for more text-based API docs tools, though, and from the README, Resterm does look well thought out and certainly capable! But it gave me flashbacks to my first days trying to learn Emacs.
I've build something similar [0] but lives in the terminal and is fully open source if anyone prefer terminal based app but still wants to work with .http/rest files.
I don’t personally use Postman, but at work we use .http files, which are easy to version and manage with Git. The downside is that you’re almost entirely tied to VS Code and the REST Client extension. I’m not a big fan of VS Code myself (I use Vim), so if anyone interested, I created resterm [0] - a terminal client that works with .http or .rest files and adds some extra "nice-to-have" features. I’m currently working on adding OpenAPI spec importing.
- Some Linux users really like modularity and composability ("do one thing") to the point of considering it a core tenet of unix-alikes overall.
- Systemd is perceived as being a super-project that is not practically modular and composable (though it may hypothetically be so)
- Some see systemd and related activity in Gnome and elsewhere as Red Hat bullying their way into excessive control over the direction of Linux.
- Mistrust of Poettering and the general attitude and competence of developers on the project—some of this hostility dates back to pulse audio, another Poettering/Red-Hat project that was seen by many as technically deficient, led by people with excessive hubris without the know-how or taste to back it up, and excessively/unjustifiably promoted by Red Hat and Poettering through political maneuvering.
- Concern that due to all of the above it represents: a power-grab by a single actor over Linux; a risk to Linux security and stability; and a risk to the future maintainability of, and practical transparency to the user of, Linux due to the scope, complexity, and architecture of the project, coupled with its heavy dependence on a single benefactor.
> - Some Linux users aren't fans of super-projects.
> - Some Linux users really like like modularity and composability ("do one thing") to the point of considering it a core tenet of unix-alikes overall.
That’s why Linux itself is a micro kernel. Oh wait… ;)
First, systemd came in and replaced a lot of the base OS, happily changing things to be... either "modern and designed with hindsight" or "breaking compatibility because they could", depending on your viewpoint. As an end user it was mostly invisible, but anyone mucking around under the hood got half the engine replaced on them, and it was not appreciated. (A major example would be the journal; for 40 years logs went into nice flat text files that could be watched with tail(1) or searched with grep(1), and then systemd came along and moved logs into a binary format that forced you to go through journalctl to access anything.)
Second, systemd can be viewed as "playing dirty" in the way that it was pushed through the ecosystem. It was viewed as Red Hat pushing their preferred solution by leveraging what should have been unrelated packages - udev went from an init-agnostic database of hardware and rules engine to being part of systemd and everyone else had to factor it back out, GNOME made systemd a dependency, that kind of thing. Further, the developers tend to take a... "our way is right and anyone who disagrees is out of touch" view, while being remarkably blind to other systems; my favorite was https://github.com/tmux/tmux/issues/428 , wherein they wanted tmux (a portable program hailing from the BSD side of the ecosystem) to abandon existing daemonization code and go with a systemd-specific approach. They even came out and said that they were happy to try and make things harder for people who didn't accept their way - why try convincing someone to adopt your approach when you can just modify the ecosystem to progressively make it harder for them to do things their way (https://lists.freedesktop.org/archives/systemd-devel/2010-Se...)?
These are my main reasons to avoid systemd as much as possible. And a bug in systemd-udev on 32-bit Linux systems that periodically halted the performance of the system into unusable state for long times that is probably never going to get fixed.
Broadly, systemd was trying to do two things at once:
- be "opinionated" software
- supersede all other software in its category
Very few other free software projects have tried that combination.
I think it might have been be possible to do without angering large numbers of people if the developers had been significantly above average in both technical judgement and the social aspects of developing free software.
But the systemd developers weren't either of those things.
For those of you who downvote this because you think I'm being disingenuous, I speak from personal experience of working closely with Red Hat in a number of projects where their code were an integral part of the solution.
Red Hat really do reinvent the wheel, for the purpose of making money selling popular kinds of software. And they're shamelessly declaring themselves superior to the product they're mimicking. And the projects are ran like side projects of the lead developers.
Lennart came down from heaven (or, depending on your perspective, up from hell)
and looked at the state of linux distributions.
He said, "This sucks. Boot times are slow. Distros have a mish-mash of init
systems and shell scripts, all subtlety different. Linux features like cgroups,
which are the bee's knees, are left as an exercise to the sysadmin. Why aren't
user processes manageable? etc."
Thus systemd decided it was going to standardize a new layer between the linux
kernel and userspace using a declarative model for configuration for... like
everything. This was a huge change in the linux world. A huge change was going
to be controversial. Systemd is still controversial.
If only they paid equal attention to shutdown as well. It is relatively easy to inadvertently break a systemd install in such a way that reboot/shutdown would go through a number of grotesque "tasks" with very generous time-outs:
- Unmounting filesystem /mnt/nfs (X seconds out of 1:30)
- Waiting for D-Bus to terminate (Y seconds out of 4:00)
...and so forth. It's so bad, there is a special "C+A+D, 7 times in two seconds" key combination to deal with those. Which, I've seen fail as well.
+10 on this. The first thing I noticed years ago from running a systemd-based distro, is that shutdown (thus reboot) got stuck in "...waiting for xxx to terminate" for multiple minutes. This had never happened before, and there were never consequences from it not happening. So it was (and remains, in many hard-to-debug cases) strictly a drawback for systemd-based systems.
It could be a bug in a third party service that didn't shut down properly or wasn't integrated with systemd properly. You should not put a blame on systemd without investagating first.
> declarative model for configuration for... like everything.
Here I find that many people look for the wrong thing. Their idea is 'do $stuff at boot'.
However, systemd does 'do $stuff at $event', where 'boot' is one of the events in the set. They are not wrong though, we are used to cron is not a valid reason why it should not get unified.
… but you can still just run your favorite crond, and keep doing exactly what you were before? I've still never run a cron job under systemd, and I've never hit trouble doing that. I.e., Systemd doesn't force you to use it for cron.
Although, now that I'm looking at ArchWiki's "list of reasons you might want to do this" … it checks off basically every problem with traditional cron. I might need to start using this.
I really like systemd, but from what I understand, the folks who don’t like it have a number of gripes. The one that most resonates with me is that systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose.
I'm not super familiar with systemd or any of the lower level stuff like init systems in general, but I was under the impression that it's just an umbrella for many individual modules/binaries, like journald, etc, and not actually monolithic.
I get the argument against hard dependencies, which the individual modules seem to be dependent on each other, but is that really that abnormal with Linux programs? I more understand the criticism against higher level programs, like GNOME, having hard dependency on systemd specifically.
With all that said, I'm not doubting there's valid criticism as I'm sure that I'm missing for fundamental points of the "monolithic" argument as it relates to systemd. The above is just my sort-of layman impression.
> but I was under the impression that it's just an umbrella for many individual modules/binaries, like journald, etc, and not actually monolithic.
If you can't use journald without systemd, and you can't use systemd without journald, or they really modular in any meaningful sense? I can take a Void Linux system and drop in rsyslog and chronyd and maybe dnsmasq (for DNS caching); I can't take a Void system and add journald and timesyncd and resolved.
What would you use as an example of modularity? The closest that most of it gets is that you can disable features and put back the non-systemd alternatives, but I'm not aware of any systemd components that play nice on non-systemd systems except for maybe systemd-boot nee gummiboot (which benefits from running before systemd and therefore is less inclined to depend on it).
> systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose
Isn't the typical Unix kernel that most users interact with a giant monolithic program with some runtime modules but mostly compile time configurability? I think this goes all the way back to the original Unix kernels.
Most users don't interact with the kernel. They interact with a posix (or posix-like) environment. And that is definitely a kalidescope of independent utilities. Most of which are at least somewhat portable across *nix/bsds.
To the haters credit, previously the init system itself was also authored with posix-compatible tools. And could be hacked upon easily, readily, without compiling. By compare, you'd kind of need to attach gdb or what not to systemd's pid1 to see what's happening, and it'd be much more complex, and you'd need to be compiling your own systemd to make changes. I'm a huge systemd proponent, but to be honest, it's shocking to me that there's not a bunch of guides to running gdb, to watching systemd do it's thing: we largely are all consumers, accepting systemd's activities/behaviors on faith.
Yes, and as kernels grew this is where the arguments for/against micro-kernels began. Modular monoliths seem most common ATM, but micro-kernel architectures haven't entirely lost the game yet.
The kernel being largely monolithic is an annoyance that people do keep trying to fix where possible, but it's easier to sweep that under the rug than to deal with monoliths in userspace.
> Just read the thread rather than trying to conjure meaning from a single comment
My comments are half of the thread, and I don't think I'm missing context; yes, the kernel is often a monolith, but 1. nobody really likes that, it's just hard to fix[0], and 2. the kernel can mostly be ignored because it presents a clean enough ABI and doesn't really affect userspace[1], whereas systemd is a monolith in userspace that very much does affect the rest of the system. I'm not seeing any "cognitive dissonance".
> rather than trying to conjure meaning from a single comment like a rtard
Insulting people is both against the site guidelines[2] and an excellent people to get people to disagree with you even if they might have been otherwise convinced.
[0] Because context switching in and out of ring 0 murders performance.
[1] Seriously, you can swap out the kernel completely like Debian kFreeBSD and it's basically invisible to the user.
[2] "When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to '1 + 1 is 2, not 3.'" (https://news.ycombinator.com/newsguidelines.html)
the systemd suite had replaced tools that didn't need to be replaced, often does a worse job than they did and introduces measurable overhead, all for the sake of "standardization" no one had asked for
besides that, it is a significant part of ongoing corporate embrace/extend/extinguish of OSS
Any change to Linux will set off some very small, very vocal number of very entitled complainers.
The short is that all operating systems face various problems of synchronization and they have all roughly converged to a very similar design to manage it. And I really mean all--Windows, OS X/macOS, Linux, Solaris, AIX, ...
The long is that there was a window where this problem needed to be solved and there were a bunch of half-baked solutions. Pottering sat down, wrote code, came up with a 3/4 baked solution, and RedHat adopted it. After that, RedHat continued funding and improving it and other distributions realized that systemd made things better and slowly adopted it as well.
And throughout it all, a bunch of people continued to bitch like hell. But at no time did anyone else put in enough work--technical, social AND political--to solve the problem.
Yeah, the social and political work seemed to be "It works. We're adopting it. Pound sand and get lost." However, even in the face of that, still lots of people just pissed and moaned but failed to come up with a decent alternative.
> However, even in the face of that, still lots of people just pissed and moaned but failed to come up with a decent alternative.
Which is, alas, typical. Sources of truth in free software are, of course, not very coordinated, but one does learn, eventually, how to work with that.
So I find it very unfortunate that noise from these sorts of unhelpful reactionaries keeps getting amplified on Hacker News, while actual good and constructive stuff (hey, have you seen those lovely progress posts on GNOME Builder's GTK4 update? Did you know there's a KDE version of Fedora Silverblue? How about that interestingly modern OS image for Steam OS? Did you know people are actually making cool new things with this platform instead of clinging to the past?) barely appears at all.
Old cars are finicky and you need to keep maintaining it. But people know how every part of the system works, and they can repair it with a duct tape and a piece of bent wire.
Modern cars are full of electronics and don't break as much.. until the do. And then you need all new tools to repair them, and those tools are much harder to use, especially if you are used to old cars.
(I myself spent plenty of time on pre-systemd systems. I can tell you wonderful stories about apache children cleanup, and debugging failed startup at scale. I use systemd all the time now, and don't miss rc.d a bit)
There are many arguments, but the one that I identify with best is that systemd is unnecessarily complex, and it's components are tied closely together, breaking the "single function" paradigm of original Unix.
But really, it's more about un-learning the "old way" and re-learning an entirely new way. Is the new way better? It depends on what you need. In my case, I have never had an occasion where it was either simpler or "better" to change a configuration with systemd, so it required learning the "new way" with no benefit. I think many people are in this camp.
But the the main reason I dislike systemd is that it has resulted in broken boots on servers, sometimes randomly, and sometimes for un-debuggable reasons (something you get when you mess with init). "Failed to start X", and system hangs kinds of things.
But I have other reasons. For example, in olden times, /etc/resolv.conf is where your resolver addresses went. But if you're running systemd, then you're probably running systemd-resolved, which means /etc/resolv.conf points to localhost -- because systemd-resolved is a resolver itself. So where do you actually configure the IP addresses of an external resolver, which must be set somewhere? Go ahead and look it up, I'll wait.
/etc/systemd/resolved.conf? Maybe, depends on other systemd configuration files. Want to know what it's set to now? Sure just type "resolvedctl status", so obvious! Unless your distro doesn't have that binary, it's fairly new. In systems without systemd, updating /etc/resolv.conf was dynamic; the network stack recognized the change instantly and you were done. I don't actually know what you have to do after changing /etc/systemd/resolved.conf; I end up just rebooting. So time-saving.
Is systemd-resolved better? Well, it caches DNS for all processes (even the ones that already cache them), so that's something. Do I care? I haven't yet, but this nebulous benefit (for me) results in me having to re-learn how DNS works on my machines regardless.
I have a few servers running Devuan, and it's great.
Less sarcastically: because it does too much, in ways that sometimes are impractical (networkd comes to mind). Expect better answers by more knowledgeable people.
Personally, I like it. But I’m a simple person with simple needs.
This is what it boils down to. Systemd has been solving problems that all distros have been facing.
Unlike most Linux development, they haven’t focused on what their devs want to do (which for much of Linux is repackaging Ubuntu with uglier skins, and Ubuntu itself is a repackaging of Debian/Gnome), but rather, are solving problems that distros are actually facing.
The consequence of that is that nearly every distro goes with the systemd solution, and it’s this popularity that leads to people complaining that it’s being forced upon them.
It brings Linux closer to Windows in philosophy. Systemd is building a coherent large codebase (albeit modular) that solves all the problems, as opposed to Linux userspaces old philosophy of having a collection of "expert" tools, where each tool or project did one thing, one thing only, and did it really well. Then the system was a collection of such expert tools.
The collection of expert tools naturally aren't as well-integrated with each other, so on a system level the solution might look a bit spotty. But every function is thought through and works really well. Plus, each tool is useful on its own, which makes the system very configurable, introspectable, and hackable.
The "one big codebase that solves all problems" approach might appear more stable all-in-all, but it's a fundamentally different approach where you no longer have a bunch of expert tools, but rather a large collection of mediocre software components who's only real purpose is to be integrated with each other.
That "do one thing well" ship sailed decades ago, when ls added sorting. I don't recall the date, but I believe ls has had sorting for more years than it hadn't, possibly a lot more.
ls is not Unixy, find is not Unixy, wget/curl are not Unixy, the list is infinite.
Anyways, those breakages aren't nearly as big of a deviation from the modular design as something like systemd. I'm sorry, but that comparison just cannot be made.
I'm denying the actual utility of the "do one thing and do it well" in practice. It's an awesome soundbite and you can't really argue with it (who would want tools that do "it" badly?), but it practice it wasn't ever respected.
i dunno-- i grew up playing around with every distro of linux and unix i could get my hands on, and my first was Slackware/LILO. a lot of the so-called "expert" tools _work_ in some fashion, but could definitely use a UI/UX improvement.
all of the binutils and basic stuff is pretty antiquated and has an old-school and specific perspective and lot of the modern work we do as developers and operators has use-cases which fall behind due to such a rigid way of thinking.
i think systemd is great, and maybe it's overkill for certain applications, but there are also smaller containers and distros one can use for this. i'm all for modernising linux and the tooling around it, it's sorely needed.
I'm not opposed to the idea of a more intelligent init system, but systemd is doing waaaay to much. One example; it messed up hostname resolution on my lan by blackholing DNS traffic for single-name queries. And you cannot turn their dns component off.
Of course you can turn it off. Fedora didn't even use resolved until 2 or 3 releases ago and they were one of the first major (non rolling) distro to adopt systemd.
Maybe nowadays, but when it came to Ubuntu back in the day it was enabled by default and couldn't be turned off because it was being used early in the boot cycle when other resolvers hadn't booted yet. Talk about bad design decisions...
Speaking of which, there are some other things that Ubuntu does that get my blood pressure up, such as not having a reliable way to do truly unattended upgrades.
Frankly because of the extreme arrogance originally displayed by Poettering and his cronies, in the vein of Apple-style "you're holding it wrong" when people would raise valid criticisms of some early systemd warts.
Nowadays systemd is pretty good and not deserving of the hate it gets, but early on the opposite was true.
Because for basically every new thing it replaces, it causes problems that the thing it replaced didn't have, and Lennart Poettering often pushes back against fixing these problems.
My personal relationship is a necessary-evil one. Without it, I'd have more problems with concurrency and service/session management, but I'd lose a lot of "systemd messed up resolv/nsswitch/hosts" scenarios.
Also, for most basic set-ups, even server ones, a classic BSD or SysV init works, as do simpler and more lightweight options, as proven by Alpine, FreeBSD and derivatives (FreeNAS, PFsense) and OpenBSD based solutions. And when stuff goes wrong, those are infinitely easier to decipher.
That doesn't mean, however, that systemd is hard to write config for, often when you need a service or script ran at bootup or login it's easier to make it work right than with a SysV-style init script. The problem is the growing config- and codebase, coupled with the binary logging system, which makes it even harder (AND NO, I REFUSE TO LEARN ANOTHER HIGHLY SPECIFIC TOOL TO READ THE BINARY FILES).
The logging system is one of those things that are just done right by systemd. I usually force everything to log to syslog and let journald handle it.
Just being able to see all potential new issues all over the system with a single command after system update + reboot is extremely time saving. Viewing only logs from the last boot, filtering, interleaving of all log messages from everything on the system, so you can easily see the timeline of things in one place, sane log rotation that doesn't make it harder to query logs, etc.
If I had to not use systemd, this is the first thing I'd rewrite or find some alternative that takes the same approach. :)
Lots of people complain about its complexity and how many lines of code it is, making it very difficult to audit; it "goes against the UNIX philosophy" because it tries to do too much.
No dog in this race, so if someone wants to correct me, feel free to.
My experience is that it broadly falls into two categories.
The first is comprised of people who never actually had to wrangle sysvinit/upstart (openrc is relatively sane), and have never seen the ridiculous amount of engineering time which went into hacky stuff like supervisord and bizarro, bespoke hacks to try to do things which systemd makes trivial: socket activation, optional service dependencies, file-based service activation/restart, "failing fast", timing various parts of the boot chain, etc. This class of people, broadly, probably never actually understood how `init` worked anyway (or how booting worked once dracut came into the picture), but they now feel like it's an opaque, unobservable system. They would have felt like that anyway if they had tried to work with pre-systemd tooling.
The second mostly thinks that systemd is against the "UNIX philosophy". This class of people, broadly, has never touched a "real" UNIX other than MacOS (and they probably never had to deal with netinfo) or BSDs (which are great). There was absolutely no sanity or consistency between, say, AIX, Solaris, IRIX, and Tru64, and all of them had various classes of "god" tools.
This is indicative of the problem. Ninety-nine percent of users don't WANT to configure 40 different baroque things with their own configuration files (rsyslog/syslog-ng, dhcpcd, resolv.conf, ntp.conf, /etc/hosts|/etc/hostname, etc). They want Linux to work. They want systemd-networkd to get them an address in 1/10th of the time, and they have absolutely no need to start a daemon which can set every DHCP option ever when ACKing. They to fuss with nameserver rotation to deal with flaky stuff for split-horizon DNS -- they want systemd-resolved to handle "this server can't be reached right now, so I'll put it in timeout, keep returning cached results, and send new queries to a nameserver which is responding."
If you still WANT to do the other stuff, nobody is stopping you. Yes, you probably need dbus and udev and udisks, and all of those things are light years better than the tools we used to have before, but systemd itself can be trimmed down to almost nothing if you want to. The alternative, building up a stack which can sort of approximate systemd, would take a very competent admin at LEAST a week to build deployment tooling for, and that's assuming they already knew all the stuff they needed to plug in.
because it's a comprehensive suite of software that largely gets the job done while ignoring various 'unix philosophies', which some people in the linux world really do not like. To me it resembles programming language debates a lot where highly popular, pragmatic languages get attacked by people with strong philosophical ideas about how software ought to be built.
It's a Dunning-Krugerish non-solution, sold as an init system trojan that is replacing more and more of the OS with less and less understanding of how it would need to work in order to do so effectively. It's a monolith that is almost pure attack surface, which requires the rest of the OS to change to work with it, thereby making it part of that monolith and extending the attack surface.
Every admin issue I've had over the last decade save two has been due to SystemD. I'm not opposed to change, but I'm also not going to embrace change for its own sake, particularly incompetently designed and implemented change.
Then we get to the project's social problems. But people get very defensive about that, so I'll just point out that if change is such an unalloyed good we certainly can't argue against changing away from using SystemD, can we?
> Every admin issue I've had over the last decade save two has been due to SystemD.
Do you administer systems with SysVinit as well? If not, please consider that of course the system which manages startup and background services is going to be responsible for admin issues. It is exactly the area you are responsible for administering! If yes, I'm curious how those are going in comparison. Are they less trouble?
https://github.com/unkn0wn-root/resterm
reply