PowerShell is interesting, and I don't consider it evil. I know some people swear by it, and I am not one of those people - I'll take my AWK with a side of Ruby/Python, and a helping of SCSH, thank you very much.
It does seem a bit out of place in a UNIX system, though. In Windows, PowerShell ties to a ton of strongly typed databases (SysReg, &c) and windows APIs together into a nice package. But on UNIXes, those APIs are already well exposed elsewhere, and that data doesn't exist. UNIX data is typically stored as text, or can be extracted as such easily. We don't tend to do a lot of binary object munging. I mean, maybe if it integrated with databases, it could at least be handly for dealing with RDBMS scripting, but those bindings are available elsewhere - ruby, perl, python, etc. And MS could build bindings to POSIX, so you'd get a PowerShell version of tools like PS that returned objects, but what are you going to do if you want to munge /etc/fstab, and, say, generate user accounts for all your boot filesystems? I could do that with a line of bash and a few lines of AWK. I don't know why I'd want to, but I could.
So to conclude, PowerShell seems like a neat tool, but it was designed for an ecosystem that doesn't exist on the *nixes.
> But on UNIXes, those APIs are already well exposed elsewhere, and that data doesn't exist.
I'd go with exposed, but not necessarily well. Examples I run into all the time: get an IP from an interface, change iptables entries, even change fstab options. Sure, if you write enough regex, it will probably work most of the time. But it's never going to be as reliable as get_ips('eth0'), or get_filesystem('/tmp').options.add('nosuid').
It's unreliable, because you don't know where you'll find 'inet ' or what's the specific spacing of the output. Also, that's not the ip, because you've still got the cidr attached.
And no, fstab is not easy either. For example it fails for:
# /tmp has option_blah in order to ...
changing it to:
# /tmp has option_blah,nosuid in order to ...
Confusing the next person to look at the well intended comment.
It's no impossible to implement fairly reliably, it's not going to take days to do, but you're likely make mistakes. And in both cases you're spawning extra processes instead of just getting the information you need.
PS. also slightly annoying is that everyone is so concerned about the text processing part that barely anyone checks what the tool itself can do. (ip -4 -o a s dev eno1 | awk '{print $4}')
>PS. also slightly annoying is that everyone is so concerned about the text processing part that barely anyone checks what the tool itself can do. (ip -4 -o a s dev eno1 | awk '{print $4}')
Actually, I spend a while digging through the manpage to try and find this. ip has awful docs.
Yes it will. If you mean the $2 part, the comment character takes the place of $1. Or did you mean something else? (either way, I tested it before posting)
...Which is why I said it was ugly. The grep probably won't break, the cut is more likely to. This is in part because the 'ip' command isn't very well designed. A better solution I found is
ip addr show wlan0 | grep -Po 'inet \K[\d.]+'
Which is less likely to break. If your system supports it,
hostname -I
Works great. However, this seems to be an ubuntuism, and it doesn't work on my system.
Are you out of your mind? Or do you just not understand what you're saying? Adding an interface to PS to get this info natively is good. But Lennart has a magic ability to get everything wrong, and he's NOT messing with my fstab any more than he already has.
>Then which audio system is simple to set up AND allows per-program volume, effects, etc?
JACK
>Which init system "just works" without requiring me to copy and modify a hacky init script from stackoverflow?
s6, runit, bsdinit (yes, really).
>Lennarts products are controversial, but they’re the classical "least worst" options.
No, they're ugly, broken messes that look nice. Systemd is a monster. If it was an init system, I wouldn't complain, but it's not. It's an init system that's also a cron replacement, a syslog replacement, an automount replacement, a docker replacement, a consolekit replacement, steadily gaining a tight integration with udev, overcomplicates everything it touches (we need a hostname daemon now?), provides libraries to high-level userland that are DELIBERATELY POSIX incompatible, promotes binary formats for no reason, flies in the face of tradition for no reason and breaking code (screen sessions die now), overcomplicates PID1, increasing the chances of a kernel panic, and that's just the tip of the iceberg.
Systemd is a tiny step forward, followed by a massive step back, and of you can't see that, you haven't been paying attention.
Try getting it to run with basically anything, seriously. Pulseaudio is plug-and-play.
> Which init system "just works"
Neither of the ones you mention fit that description
> It's an init system that's also a cron replacement
Wrong.
SystemD is a project with a similar branding issue that KDE has.
Systemd is a project.
It develops a set of libraries.
And, on top of that, an init system.
And a cron replacement.
And a syslog replacement.
You do not need to use them together – just like you can use Gtk apps in a KDE environment – but together everything works best.
> for no reason and breaking code (screen sessions die now)
For the reason that shutting down my PC means it spends 10 minutes waiting for screen sessions to kill themselves, and I can not stop that without either doing a killall, alt-print-reisub, or just pulling the plug? It also provides a way to keep things running still.
> increasing the chances of a kernel panic
Never had one, and I’m running bleeding-edge arch
> Systemd is a tiny step forward, followed by a massive step back, and of you can't see that, you haven't been paying attention.
Systemd is the least worst option.
There is not much of an alternative for such a kind of project, that properly handles things in a more modern way.
I want a userland that works plug-and-play, I want syslog as a daemon with database, not as a fucking flat file. I want more dbus, and, ideally, I’d have all config files in a database or registry for easier administration and sync.
I want proper udev and containerization, I want programs of my user to be killed upon logout unless specified otherwise.
Lennarts projects don’t provide what the old crowd of nerds want.
But they provide what the average user want, and what’s required to make Linux actually usable for your sister, your grandmother, and your retarded neighbor that can’t even turn on a PC.
It also reduces the workload for server admins, like me, again.
I can write systemd unit files in a few minutes, can easily stream syslog over the network from multiple servers and aggregate, I can easily handle namespacing of software.
>I can write systemd unit files in a few minutes, can easily stream syslog over the network from multiple servers and aggregate, I can easily handle namespacing of software.
You could do 2 of those three things already (syslog and namespacing), and bsdinit init files aren't hard to right.
>Systemd is a project.
>It develops a set of libraries.
>And, on top of that, an init system.
>And a cron replacement.
>And a syslog replacement.
>You do not need to use them together – just like you can use Gtk apps in a KDE environment – but together everything works best.
That's BS. A lot of it's all one executable.
>I want a userland that works plug-and-play, I want syslog as a daemon with database, not as a fucking flat file. I want more dbus, and, ideally, I’d have all config files in a database or registry for easier administration and sync.
Well, if you want Windows, you know where to find it. But stop trying to turn my UNIX into it.
>I want programs of my user to be killed upon logout unless specified otherwise.
Well, you're in an EXTREME minority.
>But they provide what the average user want, and what’s required to make Linux actually usable for your sister, your grandmother, and your retarded neighbor that can’t even turn on a PC.
...and if you think "the year of linux on the desktop" is ever coming, you're delusional. Besides, Ubuntu had a reasonable UX for that audience long before systemd came around.
>I can write systemd unit files in a few minutes, can easily stream syslog over the network from multiple servers and aggregate, I can easily handle namespacing of software.
Software namespacing doesn't require systemd. Syslog streaming has been a thing for a long time. And BSDinit, s6-rc, runit, openrc, sheperd, nosh, systemXVI, perp, watchman, and a variety of other init systems exist that make writing unit files easy. Many of them predate systemd.
That’s not even true if you use the packages for debian or redhat. In both cases, it’s over a dozen packages for systemds independent projects, and you can replace each of them seperately, if you wish to.
I’ve done so in the past on a server where I couldn’t update everything because it was an old-style containerized VPS with shared kernel.
> Well, if you want Windows, you know where to find it. But stop trying to turn my UNIX into it.
> Well, you're in an EXTREME minority.
Then go and use UNIX, aka BSD. This is the linux world, and most people want it – as seen in the countless times when distro maintainers held a vote pro or con systemd.
> ...and if you think "the year of linux on the desktop" is ever coming, you're delusional. Besides, Ubuntu had a reasonable UX for that audience long before systemd came around.
Does Ubuntu allow me to configure all services and systems via a neat UI? No? Why? Because it still uses a flawed file-based approach, which is useless in the 21st century.
Ubuntu replaced user-facing UX, but even there not everything could be properly done yet.
Despite that, Ubuntu also created their own init system, display server, syslog daemon, and a registry for configs.
So, they had the same stuff systemd now provides, and more.
> You could do 2 of those three things already (syslog and namespacing), and bsdinit init files aren't hard to right.
> Software namespacing doesn't require systemd. Syslog streaming has been a thing for a long time. And BSDinit, s6-rc, runit, openrc, sheperd, nosh, systemXVI, perp, watchman, and a variety of other init systems exist that make writing unit files easy. Many of them predate systemd.
I’ve tried unit files for other init systems, it was a pain in the ass.
Systemd is the first where every software provides matching unit files, I can easily write my own, and it just works.
Again, the entire point is that it just works and is still easily configurable and modularized.
It's not modular, it's a mess. Systemd may be organized into separte components, but make no mistake - it's a monolith in sheep's clothing.
As for unit files, nosh, at least, provides the same format as systemd. s6 "unit files" are just the command to daemonize the process, in most cases. BSDinit and OpenRC are pretty simple as well.
>Then go and use UNIX, aka BSD. This is the linux world, and most people want it – as seen in the countless times when distro maintainers held a vote pro or con systemd.
Linux is a UNIX too, and most of the people who know and care about init systems don't want it, judging by the massive protests that show up constantly from people who understand the technical aspects.
>Again, the entire point is that it just works and is still easily configurable and modularized.
It "just works," but it's a technically deficient mess that goes against everything unix is about, is a monolithic beast in disguise, and is trying to force everyone to use it.
If it weren't for that last bit, I really wouldn't care.
>Systemd is to sysvinit what Linux was to Hurd and other microkernels
That's just not true. Linux was a return to a simple, tried-and-true model from a more complicated and theoretically beneficial one. Systemd is a devergance from a simple, tried-and-true model to a more complicated one, that really doesn't have many benefits.
>And "s6 "unit files" are just the command to daemonize the process, in most cases" is a horrible solution, too.
>The reason systemd unit files are so awesome is because they’re simple configuration, not having to string complicated commands together.
So are S6 unit files. So are a lot of config formats, actually. Sysvinit was really bad, but other inits had moved on. The complicated commands are only required when the app had complex requirements, or when init is stuck using fragile pid handling, which S6 and the like don't need, because they implement proper process monitoring.
>You fundamentalists had 2 decades to make a working system
BSDinit, OpenRC, s6, hell, even upstart, and countless others are all working systems.
Anyways, I'm not a fundamentalist. I don't think that systemd's unit files are broken. What I think IS broken is systemd itself.
Init has a few jobs: managing startup, managing shutdown, reaping processes, and handling daemons, etc. By this point, init's job is well defined. How it should do them has been argued, but the jobs are well defined. That is what init should do. NOTHING ELSE.
Systemd tries to do everything. Thus, it's overly complex, AND it's a single point of failure.
>It’s time to end this.
I quite agree: When Lennart stops making me try to use his piece of trash disguised as software, I'll stop complaining about it.
It does seem a bit out of place in a UNIX system, though. In Windows, PowerShell ties to a ton of strongly typed databases (SysReg, &c) and windows APIs together into a nice package. But on UNIXes, those APIs are already well exposed elsewhere, and that data doesn't exist. UNIX data is typically stored as text, or can be extracted as such easily. We don't tend to do a lot of binary object munging. I mean, maybe if it integrated with databases, it could at least be handly for dealing with RDBMS scripting, but those bindings are available elsewhere - ruby, perl, python, etc. And MS could build bindings to POSIX, so you'd get a PowerShell version of tools like PS that returned objects, but what are you going to do if you want to munge /etc/fstab, and, say, generate user accounts for all your boot filesystems? I could do that with a line of bash and a few lines of AWK. I don't know why I'd want to, but I could.
So to conclude, PowerShell seems like a neat tool, but it was designed for an ecosystem that doesn't exist on the *nixes.