[-] SpaceCadet@feddit.nl 1 points 9 hours ago* (last edited 9 hours ago)

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@feddit.nl 24 points 5 days ago* (last edited 5 days ago)

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@feddit.nl 51 points 1 month ago

I’ve honestly never understood why someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.

[-] SpaceCadet@feddit.nl 51 points 3 months ago* (last edited 3 months ago)

They're just going to do a classical boil-the-frog operation:

  • Step 1: Make it opt-in and present it as the new cool thing.
  • Step 2: Make it opt-out, and if the users opts out, show a scary warning about how the cool thing won't work anymore.
  • Step 3: Silently opt-in, and hide the opt-out option deeply in a settings menu.
  • Step 4: Silently opt-in, remove opt-out, but it still works with a registry hack. Microsoft apologists will still thinks it's cool because "just use this simple registry hack bro".
  • Step 5: Remove opt-out alltogether, and silently opt-in everyone who had previously opted out.
  • Step 6: Enjoy their boiled frog!
1046
submitted 3 months ago* (last edited 3 months ago) by SpaceCadet@feddit.nl to c/fediverse@lemmy.world

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 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.

[-] SpaceCadet@feddit.nl 53 points 3 months ago

Yeah god forbid people have some interesting discussion on this platform, right?

[-] SpaceCadet@feddit.nl 110 points 4 months ago

Good news ... it's a suppository!

[-] SpaceCadet@feddit.nl 58 points 5 months ago* (last edited 5 months ago)

I've found that the silliest desktop problems are usually the hardest to solve, and the "serious" linux system errors are the easiest.

System doesn't boot? Look at error message, boot from a rescue disk, mount root filesystem and fix what you did wrong.

Wrong mouse cursor theme in some Plasma applications, ignoring your settings? Some weird font rendering issue? Bang your head against a wall exploring various dotfiles and rc files in your home directory for two weeks, and eventually give up and nuke your profile and reconfigure your whole desktop from scratch.

[-] SpaceCadet@feddit.nl 49 points 6 months ago

Depends. Is it GNU tar, BSD tar or some old school Unix tar?

Double hyphen "long options" are a typical GNU thing.

[-] SpaceCadet@feddit.nl 74 points 7 months ago

People be like:

7
submitted 9 months ago* (last edited 9 months ago) by SpaceCadet@feddit.nl to c/debian@lemmy.ml

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 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.

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 
[-] SpaceCadet@feddit.nl 71 points 11 months ago* (last edited 11 months ago)

This is not a chrome vs firefox issue. People using an adblocker on firefox are getting blocked just the same.

See:

source (sorry for the reddit link)

[-] SpaceCadet@feddit.nl 50 points 1 year ago* (last edited 1 year ago)

Trim support is standard. Any kernel released in the past 15 years or so will have trim support built in. So that's not something you should worry about.

How trimming is triggered is another matter, and is distro dependent. On Arch and Debian at least there is a weekly systemd timer that runs the fstrim command on all trimmable filesystems. You can check it if's enabled with: systemctl list-unit-files fstrim.timer. I can't tell how other distributions handle that. On Debian derived ones, I imagine it's similar, on something like Slackware, which is systemd-less and more hands-off in its approach, you may have to schedule fstrim yourself, or run it manually occasionally.

There is also the discard mount option that you can add in /etc/fstab, which enables automatic synchronous trimming every time blocks are deleted, but its use is discouraged because it carries a performance penalty.

Hope that answers your question.

view more: next ›

SpaceCadet

joined 1 year ago