chroot was introduced in 1979 for Unix. arch-chroot is a wrapper around chroot that provides additional functionality and a tighter integration between the system and the new root.

Oh, you use pacstrap and arch-chroot, do you? Back in my day all we had was cp and install and we liked it that way! Kids these days wouldn’t know how to install SLS without their Yays and Pac-men.

The reason is that we want it to fail. My original comment was more emotive than descriptive. The system is horribly designed and a fucking menace on the best day, so short of direct sabotage, we’re doing what we can to force the bossmang to replace it.

It’s surprisingly easy to get from the main hall to the server room. There are two doors between the entry hall and the server room, one can be bypassed by yanking it real hard, and that gives access to the breaker box for the electromagnets among others. The building is not particularly well-designed.

One of our servers is a rotting carcass being kept alive by our collective prayers. It runs Windows 7 and custom software whose developer is dead and the source is missing, nothing has been updated for over a decade, and it has its own independent UPS because once it goes down, it has an extremely slim chance of recovering, and we’re afraid to test it. It controls the card entry system into the building, including the server room. Boss doesn’t want to replace it because we’d have to replace all of the terminals and controllers too, and it hasn’t catastrophically failed yet.

You’re right. It’s not a pet. It’s like one of the Saw movies: if it dies, we’re all fucked.

Context: https://lemmy.world/comment/17894908

The lead maintainer is an anti-vaxxer, conspiracy theorist, historical revisionist, and general nutjob. Links in the comments: https://discuss.tchncs.de/post/38376251

The entire “non-ideological” thing is just him not wanting to be challenged for being a shitter.

One day the Year of the Linux Desktop will arrive.

And some people will want to pound the ecosystem back into the 80s because their obsolete, bug-ridden pile of technical debt isn’t the most popular (insert system component here) in the world, and the best alternative has some issues.

Is | (...) | { ... } a lambda expression then?

I’ve been learning Rust by going through The Book… there’s some wack-ass syntax in that language. I’ve mostly used C# and Python so most of it just looks weird… I can more or less understand what while let Some((_, top)) = iter.next() { ... } is doing, but .for_each(|((_, _, t), (_, _, b))| { ... } just looks like an abomination. And I mean the syntax in general, not this code in particular.

You could double the vertical resolution by using half-height blocks (U+2584) and using the background color for the upper half.

I’ll just copy my comment from the other day.

Some people think it handles too many low-level systems. It’s a valid concern because if systemd itself were to become compromised (like Xz Utils was) or a serious bug was introduced, all of the userland processes would be affected. People who are stuck in the 90s and think that the Unix philosophy is still relevant will also point out that it’s a needlessly complex software suite and we should all go back to writing initscripts in bash. The truth is, it’s complex because it needs to solve a complex problem.

Red Hat, the owner of systemd, has also had its fair share of controversies. It’s a company that many distrust.

Ultimately, those whose opinion mattered the most decided that systemd’s benefits outweigh the risks and drawbacks. Debian held a vote to determine the project’s future regarding init systems. Arch Linux replaced initscripts because systemd was simply better, and replicating and maintaining its features (like starting services once their dependencies are running) with initscripts would’ve been unjustifiably complicated.

Some people think it handles too many low-level systems. It’s a valid concern because if systemd itself were to become compromised (like Xz Utils was) or a serious bug was introduced, all of the userland processes would be affected. People who are stuck in the 90s and think that the Unix philosophy is still relevant will also point out that it’s a needlessly complex software suite and we should all go back to writing initscripts in bash.

Red Hat, the owner of systemd, has also had its fair share of controversies. It’s a company that many distrust.

Ultimately, those whose opinion mattered the most decided that systemd’s benefits outweigh the risks and drawbacks. Debian held a vote to determine the project’s future regarding init systems. Arch Linux replaced initscripts because systemd was simply better, and replicating and maintaining its features (like starting services once their dependencies are running) with initscripts would’ve been unjustifiably complicated.

They were not space tourists.

They were cargo. Marketing material for Jeff’s rocket-powered overcompensation that just happened to need oxygen to stay fresh.

“Meet me in the middle” says the unjust man.
You take a step towards him, he takes a step back.
“Meet me in the middle” says the unjust man.

You can’t engage such people in good faith, and it’s impossible to convince them to adopt a different viewpoint. People much smarter than you have tried and failed.

I’ve been watching a lot of Miniminuteman lately. Weigelt sounds exactly like the crackpot conspiracy theorists whose “facts” are being “silenced” by “the Establishment” of “mainstream science” because “they don’t want you to know this”.

Please tag as NSFW.

Systemd, through the systemctl command, only manages the services. The service itself is defined in a unit file, and it can come from any source, even written manually. The unit file is a text file that describes what the service is, what commands or programs should be executed when it starts or stops (for sshd it’s /usr/bin/sshd -D), what other services or conditions are required (e.g. multi-user.target after the OS has entered multi-user mode), and much more.

When a package installs a unit file, it will be installed to a subdirectory in /usr/lib/systemd, typically user or system, and when it is enabled, it will be symlinked to a subdirectory in /etc/systemd.

OpenSSH itself, which provides sshd on most systems, is developed by the OpenBSD team and ported to other OSes by the OpenSSH Portability Team.

Systemd is a collection of low-level system utilities. Its primary responsibility is managing services and serving as the init process (PID 1, the first userspace process started by the kernel), but it also has other components, like systemd-boot (a boot loader and GRUB alternative), journald (system logging), networkd (network interface management), resolved (DNS resolver), or udevd (manages device files in /dev).

People tend to vilify systemd because it is maintained by Red Hat, a company with many controversies, and a pariah among the more extreme FOSS enthusiasts; and because it’s seen as bad practice to have a single entity be responsible for so many low-level system components.

Note: the -d suffix is not exclusive to systemd things. It simply marks the program as a daemon, a long-running background process that provides some kind of service. For example, sshd (SSH server) or httpd (Apache server on some distros) are not parts of systemd.

To answer your question: not really. As far as I know, the network interface won’t have an IP address unless the computer is turned on. If you use a timer (or any other method for that matter) to power on the computer, it will request an address from DHCP as soon as the interface is brought up (unless it has a static address).

A more practical application would be scheduling long, unattended tasks, like updates or making backups.