As someone who’s written pipelines who do exactly that on Windows, macOS, Linux across x86_64, aarch64, and MIPS, with optimized, unoptimized, instrumented for ASAN, instrumented for TSAN, and instrumented for coverage, and does it all in a distributed containerized workflow… It’s not as easy as it sounds. Honestly macOS is way more of a hassle to deal with than Linux.

Unless you need ROS. ROS is utter garbage. ROS is popular in robots. ROS is, unlike its name, not actually an operating system but rather a system of tools and utilities which do not follow any standards and certainly not the OS standards. I literally hate ROS. I would burn that shit to the ground and rebuild-the-world if I had the time to.

Yes, you’re right.

And so non-competes should indeed be banned.

I’ll quote my current boss’s boss’s boss when he asked a question of me:

@inetknght, can you please not write a book? I need a quick answer

https://en.wikipedia.org/wiki/Serial_console

tl;dr:

Serial ports are (for example) commonly RS-232, although other types of ports exist. Imagine it to be a very slow Ethernet device. Because it’s so slow (and the technology predates Ethernet and also has different requirements), it’s usually attached directly to a device instead of to a network. But you could connect a modem to it and it becomes connected to a network device.

It could also be connected to a system console device. These are commonly called terminals. Such devices are often monochrome (especially older ones) because a serial connection is often bandwidth limited (eg, measured in kilobits per second instead of megabits or gigabits). Since it’s so slow, it’s not practical for video, so it’s generally just text-only.

Note that your GPU might also output a system console but rendered on your display at very high resolution and with graphics-drawing capabilities. So a system console would be any console that connects to the system.

What is a console? Well, Wikipedia presents several valid articles and the common theme as far as computers go is that a “console” is typically something that a human and a computer use to interact with each other.

For serial consoles, you might find device files for them at /dev/tty*. But for general serial devices, it could be any of several different types of device files.

Wikipedia’s article on /dev devices has a pretty decent listing of what kinds of devices you might find and several of them might be classified as a serial port. Any serial port might be connected to a serial console.

So in my case, a serial console is:

1. 2x USB-to-RS-232 (USB is a serial protocol and is basically “just” another (Universal) (and perhaps high speed) Serial port (Bus), so conversion is super cheap)
2. 1x RS-232 null modem cable

That’s pretty much it in a nutshell. Then

3. System 1 (the failing system) UEFI boots into repair system partition on a separately attached disk (eg, boot from CD or live USB) to get a local system console
4. System 1 repair system mounts the failing system partition
5. System 1 modifies failing system grub configuration to enable a serial console on the attached USB-to-serial device file and saves changes, then unmounts failing system partition
6. Power off System 1
7. Remove repair partition device
8. Open terminal window on System 2 (recovery system)
9. Connect System 2 terminal to the attached USB-to-serial device file using screen (oh wow those were some old days)
10. Power on System 1
11. System 1 boot enters grub recovery menu which allows fixing the system remotely

To be fair, a lot of that complexity could have been done by either reinstalling, or removing the hard drive and attaching it to another computer. But doing it this way allowed me to poke around and try different ways of solving the issue, rebooting, etc. It was a learning experience worth exploring.

It was years ago though and I think there was some complication with trying to understand what device file (or device number or something) needed to be to work on the correct serial device (there are often multiple)

1. have an nvidia GPU

2. have Fedora

3. download RPM package of drivers for Red Hat (after all, Fedora and Red Hat are… compatible, right?)

4. Everything goes fine

5. Six months later, upgrade to a new version of Fedora

6. oops, kernel panic at boot after the upgrade, and no video to troubleshoot after UEFI boot

7. figure out how to boot into a recovery partition from UEFI

8. figure out how to enable a serial console over a USB device

9. figure out how to connect to the serial console from another computer using another USB device

10. figure out what the kernel panic is from (not the upgrade, but the driver which wasn’t upgraded)

11. figure out how to uninstall the incorrectly installed driver

12. figure out how to install the correct driver

That was a fun three week OS upgrade.

There’s less regulation in a developing country. So… if you get them hooked on it then, at least, you’ve got easy (albeit low) income. During the developing country maturity they will then be hooked on sugar and less likely to ban it or curb it.

It’s just as any addiction.

I’m honestly on Torvalds’ side here.

Tabs are a necessary part of the tooling and configuration files. Any tool which doesn’t properly handle files that are correctly formatted for other tools is… a broken tool.

grep -oP ' *' oops no tabs

cut -d ' ' -f 3 oops no tabs

I have had to un-teach dumb things that people learn from Windows.

A menu item to run a GUI program as root it is indeed a rather absurd scenario. It suggests that you want to violate the admin/user barrier which is intended to be difficult to surpass except in certain circumstances.

There can be a lot of things under the hood that are necessary to run a GUI program as root depending on whether you’re using X11 or Wayland or something more esoteric. It’s doable though.

But instead of doing that, why not just learn how to use the command line? Every administrative task can be done via the command line, but not every administrative task has a GUI counterpart. So you’re going to need to learn to use the command line sooner or later.

and would not include it in the main repo

Tests that verify behavior at run time belong elsewhere

The test blobs belong in whatever repository they’re used.

It’s comically dumb to think that a repository won’t include tests. So binary blobs like this absolutely do belong in the repository.

Disabling a systemd service won’t prevent it from starting. For example, if another service depends on it then it will start anyway.

You have to mask the service which redirects the service files to /dev/null so that the service effectively has zero directives.

systemctl mask --now snapd

It also means that anything which depends on snapd will likely fail. That is absolutely an improvement since we obviously don’t want anything that depends on snaps.

Don’t worry, apps are so slow that we don’t risk repeating the same problem of double-clicking causing the first click to open the app and the second click to do something in the app that you didn’t want to do.

I was running Fedora. Something like 27 or so. I needed drivers. I don’t remember if it was AMD or Nvidia, but they were only available on RedHat.

So I downloaded the RedHat drivers for the GPU and forced it to install. It worked! It was great.

Then when I updated the distro to the next release… everything failed. It was dropping into grub, but no video was output. Ooof.

So I ended up enabling a terminal console and connecting to it via a serial port to debug. I had to completely uninstall that RPM and I was never happy that it was properly gone. So a few months later I ended up reinstalling the whole OS.

On the plus side, I learned a lot about grub and serial consoles. Worth it.

iterators are invalidated when you push/pop a vector