• 0 Posts
  • 28 Comments
Joined 1 year ago
cake
Cake day: July 26th, 2023

help-circle


  • I was in an EMN relationship when we met on a hookup subreddit. My partner was at the time struggling with an addiction, and forgot our first conversation when I messaged the next day, but I was patient and went back over it with them. My EMN relationship combusted a few months later when my ex forgot the ethical part, and after a few more months of seeing each other more casually, my partner and I became an item. Its been six years now and I still can’t believe how lucky I was to be scrolling just the right reddit at just the right time to meet the love of my life.



  • Interesting thought, I did do some work with DSRC systems for Vehicle-to-Vehicle communication, but DSRC is still pretty rare. Back during Obama’s presidency the OEMs seemed to just be exploring a bit and waiting to see if it became a mandated safety system, but that never materialized.

    These days the market seems to be moving towards Cellular Vehicle to Vehicle on 5G ( peer-to-peer), but once these techs have more adoption I think it’s more likely that the car would connect to a dedicated piece of infrastructure that would relay with the cloud. Despite there being movement towards having more computing power in vehicle, I.M.O. the OEMS are too conservative on spending for computing power, so I don’t see a future where the cloud is other cars. If cars still exist in 20 years, I would be amazed if vehicle networks weren’t ubiquitous for safety though.



  • I’m honest enough I worry about people finding me online, but I will occasionally shift the dates of things happening to me if I’m worried it will be too revealing and I’ve told some other white lies before as well. The only one that is coming to mind at the moment is I told a dead by daylight streamer I had used Zanshin Tactics to help learn Artist, when in fact I hadn’t got the perk yet. I had heard a few times that it was a good offbeat pick for her to learn to predict shots though so it was a lie to make the anecdote more personal to me.







  • One of the main draw of NixOs is the reproducibility of builds, meaning that redoing the build will provide the exact same output each time, so Nix encourages you to make configuration changes through the package manager. I’ve mostly overcome my theming woes with home-manager now, but this comment was speaking to a little wrinkle I had when I was trying to learn and take advantage of the OS’s features as best I could.



  • Malware sadly is a problem everywhere, but it is arguably less so on Linux. First, Linux is less popular so less malware is written for it to some degree. That doesn’t mean no malware, but if you’re trying to pwn people hitting a website you’ll get more targetting windows, android, or iOS than Linux so it’s a little less prevalent.

    Second, it could be argued the security model of Linux is more secure than windows. This is a far more contentious point, but I think that simply from having more eyes on the code Linux has a more secure model. Windows relies on security through obscurity a great deal, and if you talk to cybersecurity experts they will often tell you this is no security at all.

    Lastly, because software on Linux is typically installed through centralized repositories of binaries or sandboxed app images, you have to go more out of your way to get dodgy software on Linux. The tradeoff there is that a lot of proprietary apps and helper programs that come with some tech will never be available in the repos and that can send some new users to try finding them elsewhere with all the risks that entails. Some distros go for a middle ground with access to things like the Arch User Repositories, but Ubuntu’s solution is using things like PPA’s to add extra software repositories.



  • Just as an addendum to your answer. In the command writing to mullvad.list the | sudo tee /etc/apt/sources.list.d/mullvad.list is using two helpful linux utilities to modify the command. The first is the | which is called a pipe and connects the text output of one program to the text input of another. The pipe is connecting the output of echo which simply prints a string, in this case composed of the outputs of several other commands to the program tee. Tee which is given admin privileges by the sudo takes an input stream and splits it between two files. In this case those are mullvad.list and since no other was provided stdout the output pipeline of the terminal running the command.

    EDIT:

    In the interest of further completeness. Another utility used in those commands is the command substitution operator of sh. So when the terminal is interpretting text $(some command) gets substituted out for the text output by the command in the parentheses. It is another common way of connecting commands on the shell to allow for more flexible and powerful commands.


  • I understand what you mean. If you are on the fence and not super interested in init systems, you can pretty easily get by with systemd without thinking about it. Most desktop environments have tools to manage user services in easy GUI’s, and you can find guides for anything more advanced you want to accomplish with them usually.

    If you want to dive in though, systemd is a great init system to learn. Nowadays learning systemd is a lot less of a moving target, and it’s in use virtually everywhere so the knowledge is valuable. It’s also fairly well documented at this point, which is great for learning how it works.

    My personal advice if you want to go that path is to just open up some service files. There are lots of interesting examples in /lib/systemd/system Systemd service files are just plain text, and pretty straightforward to read. Its divided into nice sections, and naming is pretty straightforward (Or the systemd brainworms are really in deep). Look for names you recognize or programs you use. Especially ones you are familiar with on the command line. I don’t recommend changing them to start, especially in the system directory, just open a couple and you should quickly start seeing the connections between what they are trying to accomplish and whats in each file. Then if you see anything you don’t understand or peaks your curiousity check the documentation. Once you’re ready try writing one of your own for something in the usr service directory. No pressure though, its not necessarily essential knowledge


  • I think it would not actually be easy to test this. The massive combinations of hardware and software configurations in use out in the world make it nearly impossible to conclusively say one way or the other.

    For instance consider the hypothetical of a service with a bug that increases its startup in certain circumstances. If Systemd triggered this bug and OpenRC didn’t because of some default setting in each, perhaps a timeout setting, would you say OpenRC is conclusively better at start up time? Not really, they just got lucky that their default bypassed someone elses bug. Just off the top of my head other things that would probably cause hell in comparisons are disk access speeds, RAM bottlenecks, network load, CPU and GPU temp and performance etc.

    You can perhaps test for specific use cases and sets of services, but I think this is more useful for improving each init system than it is as a comparison between them.


  • You can look up Lennart Poettering yourself, but he was also involved in PulseAudio which if you learned Linux in the 00’s might give you pause, and has had some minor beef with Linus Torvalds before. His Wikipedia page has something like 5 paragraphs for controversies and 2 for his actual career.

    I think focusing on him is a mistake, but I also understand people who were still mad about PulseAudio latching on to him if they also had issues with Systemd. This article goes into some of it, but I can’t vouch fully for its accuracy. I will say that the dates of 2008 for PulseAudio’s release and 2012ish for when it became actually fairly functional lines up pretty roughly with my own memory, and systemd was released in 2010 and adopted by Arch and Debian in early 2012, so PulseAudio was barely fixed before the same developer started pushing Systemd, and succeeded in getting the normally very conservative Debian developers on board.

    https://linuxreviews.org/Lennart_Poettering#So_Much_Drama