SpaceCadet
Now
•
100%
The thing is, you can't really engineer against anti-social behavior. For every better made apartment you will find that there is an even bigger anti-social idiot who still manages to make life hell for their neighbors.
I'm pretty blessed with my mostly boomer neighbors (🤞) who don't make a peep after 10PM, but my girlfriend has had some shitty neighbors even though her apartment is pretty well made. Sound insulation between apartments is no match for cigarette and marijuana smoke wafting in from the balcony below any time you want to open the window to air out, or if, heavens forbid, you want to sleep with the window open in the summer, nor does it help much if they are partying and speaking loudly on their balcony until 4AM on weekdays. And then I'm not even getting into how they're treating shared spaces.
The proximity makes everything so much worse than it would be with a house, at some point only adding distance helps.
SpaceCadet
Now
•
100%
A core memory of mine is getting flung off of one of these things because of the centrifugal force, falling on my back, and being unable to breathe for like 20-30 seconds ... until I screamed at the top of my lungs, and things slowly returned to normal, while the teacher just went: oh you're fine, don't be a baby. I was 6.
SpaceCadet
Now
•
100%
All true, yet it has nothing to do with what we are discussing, so why are you muddying the water with it?
SpaceCadet
Now
•
100%
We're explicitly talking about a situation where the donor is suitable. So I don't know what kind of information you're trying to add here.
SpaceCadet
Now
•
75%
The past year or two I've found several stores where they are abandoning it. I presume because people carrying cash, especially coins, is becoming rarer and they don't want to inconvenience their customers?
Strangely enough, carts still get returned even at these stores.
SpaceCadet
Now
•
100%
Even if her partner could donate his own liver, it should still go to a better recipient
That's nonsense, because the partner would not donate his liver if it went to someone else.
SpaceCadet
Now
•
100%
The flag is called --no-preserve-root, but the flag wouldn't do anything here because you're not deleting root (/), you're deleting all non-hidden files and directories under root (/*), and rm will just let you do it.
SpaceCadet
Now
•
100%
It’s apparently a hobby and to be competitive, you need to be able to spew bullshit at amazing rates. Personally I’ve maxed out at 140 wpm
I'm limited by the rate at which I can think of bullshit.
SpaceCadet
Now
•
100%
yet all I needed is a "this side up" symbol ...
SpaceCadet
Now
•
100%
Since you forgot to add - - preserve-root It won’t go too far
Go on then ... try it.
Or don't because you will erase your system. (Hint: it's in the asterisk)
SpaceCadet
Now
•
100%
as the binary is already loaded into memory
That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.
SpaceCadet
Now
•
100%
That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.
SpaceCadet
Now
•
100%
In Unix/Linux, a removed file only disappears when the last file descriptor to it is gone. As long as the file /usr/bin/rm is still opened by a process (and it is, because it is running) it will not actually be deleted from disk from the perspective of that process.
This also why removing a log file that's actively being written to doesn't clear up filesystem space, and why it's more effective to truncate it instead. ( e.g. Run > /var/log/myhugeactivelogfile.log instead of rm /var/log/myhugeactivelogfile.log), or why Linux can upgrade a package that's currently running and the running process will just keep chugging along as the old version, until restarted.
Sometimes you can even use this to recover an accidentally deleted file, if it's still held open in a process. You can go to /proc/$PID/fd, where $PID is the process ID of the process holding the file open, and find all the file descriptors it has in use, and then copy the lost content from there.
SpaceCadet
Now
•
100%
Leave the poor kernel out of it, it has nothing to do with this. It's Lennart, not Linus.
SpaceCadet
Now
•
100%
No can do, you just pressed Z after the UNDOs
Like a time traveller who accidentally steps on a butterfly and erases the whole future that he came from
SpaceCadet
Now
•
100%
I don't think it's intended as a "solution", it just lets the clobbering that is caused by the case insensitiveness happen.
So git just goes:
- checkout content of README.md to README.md (OS creates README.md)
- checkout content of README.MD to README.MD (OS overwrites README.md)
If you add a third or fourth file ... it would just continue, and file gets checked out first gets the filename and whichever file gets checked out last, gets the content.
SpaceCadet
Now
•
75%
Depending upon their genre and your city’s size, they may never come nearby you
The joy of living in a central, densely populated area of Europe ... I've been able to see almost all niche bands that I'm into live.
I feel like we need to talk about Lemmy's massive tankie censorship problem. A lot of popular lemmy communities are hosted on lemmy.ml. It's been well known for a while that the admins/mods of that instance have, let's say, rather extremist and onesided political views. In short, they're what's colloquially referred to as tankies. This wouldn't be much of an issue if they didn't regularly abuse their admin/mod status to censor and silence people who dissent with their political beliefs and for example, post things critical of China, Russia, the USSR, socialism, ... As an example, there was a thread today about the anniversary of the Tiananmen Massacre. When I was reading it, there were mostly posts critical of China in the thread and some whataboutist/denialist replies critical of the USA and the west. In terms of votes, the posts critical of China were definitely getting the most support. I posted a comment in this thread linking to "https://archive.ph/2020.07.12-074312/https://imgur.com/a/AIIbbPs" (WARNING: graphical content), which describes aspects of the atrocities that aren't widely known even in the West, and supporting evidence. My comment was promptly removed for violating the "Be nice and civil" rule. When I looked back at the thread, I noticed that all posts critical of China had been removed while the whataboutist and denialist comments were left in place. This is what the [modlog](https://lemmy.ml/modlog) of the instance looks like:  Definitely a trend there wouldn't you say? When I called them out on their one sided censorship, with a screenshot of the modlog above, I promptly received a community ban on all communities on lemmy.ml that I had ever participated in. Proof:  So many of you will now probably think something like: "So what, it's the fediverse, you can use another instance." The problem with this reasoning is that many of the popular communities are actually on lemmy.ml, and they're not so easy to replace. I mean, in terms of content and engagement lemmy is already a pretty small place as it is. So it's rather pointless sitting for example in /c/linux@some.random.other.instance.world where there's nobody to discuss anything with. I'm not sure if there's a solution here, but I'd like to urge people to avoid lemmy.ml hosted communities in favor of communities on more reasonable instances.
I have a small server in my closet which is running 4 Debian 12 virtual machines under kvm/libvirt. The virtual machines have been running fine for months. They have unattended-upgrades enabled, and I generally leave them alone. I only reboot them periodically, so that the latest kernel upgrades get applied. All the machines have an LVM configuration. Generally it's a `debian-vg` volume group on `/dev/vda` for the operating system, which has been configured automatically by the installer, and a `vgdata` volume group on `/dev/vdb` for everything else. All file systems are simple ext4, so nothing fancy. (*) A couple of days ago, one of the virtual machines didn't come up after a routine reboot and dumped me into a maintenance shell. It complained that it couldn't mount filesystems that were on `vgdata`. First I tried simply rebooting the machine, but it kept dumping me into maintenance. Investigating a bit deeper, I noticed that `vgdata` and the block device `/dev/vdb` were detected but the volume group was inactive, and none of the logical volumes were found. I ran `vgchange -a y vgdata` and that brought it back online. After several test reboots, the problem didn't reoccur, so it seemed to be fixed permanently. I was willing to write it off as a glitch, but then a day later I rebooted one of the *other* virtual machines, and it also dumped me into maintenance with the same error on its `vgdata`. Again, running `vgchange -y vgdata` fixed the problem. I think two times in two days the same error with different virtual machines is not a coincidence, so something is going on here, but I can't figure out what. I looked at the host logs, but I didn't find anything suspicious that could indicate a hardware error for example. I should also mention that the virtual disks of both machines live on entirely different physical disks: VM1 is on an HDD and VM2 on an SSD. I also checked if these VMs had been running kernel 6.1.64-1 with the recent [ext4 corruption bug](https://www.debian.org/News/2023/2023120902) at any point, but this does not appear to be the case. Below is an excerpt of the systemd journal on the failed boot of the second VM, with what I think are the relevant parts. Full pastebin of the log can be found [here](https://pastebin.com/27KbitLe). ```` Dec 16 14:40:35 omega lvm[307]: PV /dev/vdb online, VG vgdata is complete. Dec 16 14:40:35 omega lvm[307]: VG vgdata finished ... Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvbinaries.device: Job dev-vgdata-lvbinaries.device/start timed out. Dec 16 14:42:05 omega systemd[1]: Timed out waiting for device dev-vgdata-lvbinaries.device - /dev/vgdata/lvbinaries. Dec 16 14:42:05 omega systemd[1]: Dependency failed for binaries.mount - /binaries. Dec 16 14:42:05 omega systemd[1]: Dependency failed for local-fs.target - Local File Systems. Dec 16 14:42:05 omega systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. Dec 16 14:42:05 omega systemd[1]: local-fs.target: Triggering OnFailure= dependencies. Dec 16 14:42:05 omega systemd[1]: binaries.mount: Job binaries.mount/start failed with result 'dependency'. Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvbinaries.device: Job dev-vgdata-lvbinaries.device/start failed with result 'timeout'. Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvdata.device: Job dev-vgdata-lvdata.device/start timed out. Dec 16 14:42:05 omega systemd[1]: Timed out waiting for device dev-vgdata-lvdata.device - /dev/vgdata/lvdata. Dec 16 14:42:05 omega systemd[1]: Dependency failed for data.mount - /data. Dec 16 14:42:05 omega systemd[1]: data.mount: Job data.mount/start failed with result 'dependency'. Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvdata.device: Job dev-vgdata-lvdata.device/start failed with result 'timeout'. ```` (*) For reference, the disk layout on the affected machine is as follows: ```` # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vda 254:0 0 20G 0 disk ├─vda1 254:1 0 487M 0 part /boot ├─vda2 254:2 0 1K 0 part └─vda5 254:5 0 19.5G 0 part ├─debian--vg-root 253:2 0 18.6G 0 lvm / └─debian--vg-swap_1 253:3 0 980M 0 lvm [SWAP] vdb 254:16 0 50G 0 disk ├─vgdata-lvbinaries 253:0 0 20G 0 lvm /binaries └─vgdata-lvdata 253:1 0 30G 0 lvm /data # vgs VG #PV #LV #SN Attr VSize VFree debian-vg 1 2 0 wz--n- <19.52g 0 vgdata 1 2 0 wz--n- <50.00g 0 # pvs PV VG Fmt Attr PSize PFree /dev/vda5 debian-vg lvm2 a-- <19.52g 0 /dev/vdb vgdata lvm2 a-- <50.00g 0 # lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root debian-vg -wi-ao---- 18.56g swap_1 debian-vg -wi-ao---- 980.00m lvbinaries vgdata -wi-ao---- 20.00g lvdata vgdata -wi-ao---- <30.00g ````
Now
DefederateLemmyMl
SpaceCadet@ feddit.nl- Gen𝕏
- Engineer ⚙
- Techie 💻
- Linux user 🐧
- Ukraine supporter 🇺🇦
- Pro science 💉
- Dutch speaker
