I disagree. It is more than just a nitpick. Saying black holes suck things in implies that they are doing something different than any other mass. Which they are not. Would you say a star sucks in stuff around it? Or a planet? Or moon? No. That sounds absurd. It makes it sound like blackholes are doing something different to everything else - which is miss-leading at best. They way things are described matter as it paints a very different picture to the layman.
Protip: Don’t write 600 lines of code without ever testing it at all. And by testing I mean anything, manual testing included or even just compiling it or running a linter over it. Do things incrementally and verify things at each step to make sure you are not drifting off course by some faulty assumption you made near the start.
On quite a few terminals, alacritty is one, you can hold SHIFT while dragging to select things on the screen to copy from. This suppresses sending mouse events so works when you have editors, tmux or other things that can interpret mouse clicks. It does mean that it is just copying chars from the terminal so ends up copying everything on the screen. Unlike the copying baked into things like tmux of editors.
I do use scripts for more complex things. But even then I have a few very frequent one liners in my history that are 3-4 commands chained together that I have not bothered to convert. It tends to only be when they start to have logic in them that I will write a script for. Or more one off commands that are easier to edit in a multi line editor then trying to get everything right in the shells prompt.
I used to know a guy that would put everything into aliases or scripts in order to avoid remembering them. It worked well most of the time but when something went wrong or was not covered by his scripts he would struggle a lot. He avoided learning the underlying commands and what they did and so could not adapt to things when circumstances changed even a little - which does happen quite a lot.
Which is probably another reason I don’t use them. I don’t like to set them up straight away while I am learning the tool and once I am comfortable with it a reverse history search is good just as good/quick as a true alias anyway and means I never forget what I am doing and can edit it on the fly easily when needed.
TBH, not quite the same. You have to know which one you want. If you don’t quite or get it wrong you need to clear the line and start again. I quite like that I can reverse search and keep typing, or undo what I had typed and still see a list of the most recent things and can select from that list once I see what I want. This works for any command I have previously typed and dont need to setup specific key sequences for it - just any part of that command will find it again. Also works for complex chains of commands or pipes which I do not think aliases do work for.
And how did you, advanced Linux user, get to the stage your at now?
Incrementally over time by reading the documentation and/or manuals of the commands I need to run and looking up how others solve the problems that I need to get other ideas about things (even, periodically, for things that I already know how to do to see if anyone has found a better way to do it or if a new tool has come out that helps). And trying things out/experimenting with different ways of doing things to find out what works well or not.
I seem to be one of very few people that does not use shell aliases. I much prefer just using the reverse history search for previous commands instead. That way I don’t have to remember what letter I picked for different things, just ctrl+r then partially type out the command and I can see what it will execute. Bonus that I don’t need to set them up before hand and that I can edit them before executing them for those times when I need to do something slightly different.
Huh? You seem to be arguing both ways? If the system drive is full you have problems well before you risk losing data and if the home drive is full you have problems saving data? Both of these things can happen in a split partition or single partition setup. The split partition just means you have to get the space correct or end up with long resizing options for juggling the size around. And with a single partition it gives you more places to free up space when you do run out.
Need to save a file but the disk is full? Clean out the package manager cache. You cannot do that if the partitions are separate. An update does not have enough space? Delete a steam game or clear out your downloads folder.
Ext also has a reserved space option which when there is less free space than that option it refuses writes to anything but the root user - which is meant to solve the issue of a user trying to use up to much space, there is always a reserved bit that the system can do what it needs to. Though I have never seen this configured correctly for a running system and root can blast past the default 5% on smaller drives with a simple update. Or some other process is running as root is already consuming that space.
Other partition types like btrfs have proper quotas that can be set per directory or user to prevent this type of issue as well and gives you a lot more control over the allocated space without needing to reboot into a live USB to resize the partitions.
People seem to think a split partition helps but I have generally found it just causes more problems then it solves and there are now better tools that actually solve these problems in more elegant ways.
You don’t actually require a separate partition - you just need to not reformat the current one when reinstalling. Most distros I have seen will delete system folders if you don’t format but will always leave the home folder intact. Manually deleting the system folders is also an option if the installer does not.
TBH I am not sure a separate partition actually buys you anything but false confidence (which we do sometimes need ;) ). During the partitioning phase you can easily delete or format the wrong one (hell, if you only have one then it is less error prone to skip it all together). And after that step the drives are mounted and there is nothing protecting your files from the installer deleting them. It is just installers don’t touch the home folder or anything other then the system ones if it is on one partition or 50 different ones - it just sees the files in the directory it wants to install to. The only way a separate partition would add protection is if it were mounted after the install - which I do not know of any installer that actually does that.
As with anything. ALWAYS backup the data you care about before installing a new OS. The separate partition does NOT protect your data from deletion in any way. Leaving your home folder is simply a convenience option so you don’t need to restore all your files after the installation - not a replacement for a backup.
helps with issues like running out of diskspace
Or causes that problem if you don’t manage to predict your usage patterns correctly. I have seen many people run out of space on one or the other but have plenty overall and would not have had a problem with a single partition.
Sounds like a stuck button. Personally I would disassembly the device and have a look at the button and surrounding parts for any damage or liquid or debris at all. If there is any physical damage then an RMA or maybe replacement parts can be ordered (like you can buy replacement rubber if that feels worn at all). Otherwise I would ensure everything is clean and free of and liquids, stickiness or debris then reassemble the device. Even if nothing looked wrong I would test it again and see if the act of disassembly did something to solve the issue which it sometimes does for things.
IFixit has guides for the LCD and OLED versions and overall the steam deck is not very hard to disassemble compared to other small electronics. Though if you are unsure about this you may just want to talk to valve support first. If you accidentally damage something that could affect your ability to get an RMA.
It is quicker to list everything that has not been linked to causing cancer:
There, I think I got everything.
For reproductive outcomes (sperm quality) and digestive outcomes (immunosuppresion) we rated overall body evidence as “high” quality and concluded microplastic exposure is “suspected” to adversely impact them.
For reproductive outcomes (female follicles and reproductive hormones), digestive outcomes (gross or microanatomic colon/small intestine effects, alters cell proliferation and cell death, and chronic inflammation), and respiratory outcomes (pulmonary function, lung injury, chronic inflammation, and oxidative stress) we rated the overall body of evidence as “moderate” quality and concluded microplastic exposure is “suspected” to adversely impact them.
We concluded that exposure to microplastics is “unclassifiable” for birth outcomes and gestational age in humans on the basis of the “low” and “very low” quality of the evidence. We concluded that microplastics are “suspected” to harm human reproductive, digestive, and respiratory health, with a suggested link to colon and lung cancer.
Future research on microplastics should investigate additional health outcomes impacted by microplastic exposure and identify strategies to reduce exposure.
None of that is very definitive or quantitative at all - even the high quality data only gives a suspected adverse impact. Overall not really very actionable. It is probably not very good for us and something we should be working to reduce. If for no other reason than all the other problems we know excessive plastic production is causing.
Linux From Scratch (aka LFS) is a set of documentation and resources that describe one way in which to build everything on a Linux system yourself. It is not the only way though. Embedded systems is one place you might build every image from scratch but if you go down that route you are typically using something like yocto or buildroot which are designed to compile simple embedded distros for specific projects using an existing system for the build process. These are useful as embedded systems are often resource constraint and you don’t want to include things that are not required and often on different architectures from the host systems (such as ARM CPUs).
These days there is very little commercial purpose to creating your own distro from scratch that are not for embedded systems. It is a lot of work and generally not worth the effort unless building a distro is the point of your business - but even then you better have a good reason that using an existing one as a base is not a good idea. Packaging everything for a general purpose distro is a lot of work with very little benefit for a company to do. It is vastly easier to use what others have done as the base until you can justify the expense of managing everything your self (if it ever makes sense to do that).
So the only real place that you would go down building a distro from scratch is if you have a new or different idea about package management. Arch Linux did this with pacman, Gentoo with emerge, Alpine with apk, and Nixos with nix. These types of things typically start out as hobbyist projects and grow from there rather than with a commercial intent in mind.
The only other thing that makes sense is from a very high threat model for security reasons - thinking nation state level actors not your every day home user. You may want to build everything from scratch if you want to absolutely trust everything on your system and have the time and resources to do this.
SIGINT is sent when you press Ctrl+C. SIGTERM is sent in just about every other situation - basically when the system wants the program to end. For instance when systemd wants to stop the service or the default signal with programs like kill pkill htop etc. You should catch both of these signals.
Oh, misses that bit… Seems there is a third party plugin that does something similar.
It does exist with docker debug.
Generally speaking you shouldn’t be poking around running containers. It is rare that I have ever needed to do that. If you want to inspect the contents of an image then tools like dive are helpful. If the container produces some useful output that you might need then put that into a volume, you can then mount that volume to a debug/inspect container to read the files without messing around with the rest of the container.
Shell-less containers are a great security feature - it is extremely hard to get a reverse shell on something that does not have any shell. And if you must have a shell to debug something docker already has a feature for that docker debug which works for shell-less containers as well.
The article calls that out explicitly:
When installing on unsupported hardware, Microsoft will push a small disclaimer that effectively cancels your warranty in case of compatibility-related mishaps. Likewise, you won’t be entitled to receiving updates - including security updates - so we’re back to square one.
What is the point in upgrading if you wont get security upgrades either way. Just more spyware and ads in the newer version.
Realtime is important on fully fledged workstations where timing is very important. Which is the case for a lot of professional audio workloads. Linux is now another option for people in that space.
Not sure Linux can run on microcontrollers. Those tend to not be so powerful and run simple OSs if they have any OS at all. Though this might help the embedded world a bit increasing the number of things you can do with things that have full system on chips (like the Raspberry pi).