• 4 Posts
  • 657 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle
  • The disks are the most uggo part. They’re a bunch of old disks of varying sizes with a RAID+LVM setup to make the most use of them while still being redundant.

    lsblk output of the whole thing
    saiko@vineta ~ % lsblk
    NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
    sda                       8:0    0 111.8G  0 disk  
    ├─sda1                    8:1    0   512M  0 part  /Volumes/Boot
    └─sda2                    8:2    0 111.3G  0 part  /nix/store
                                                       /
    sdb                       8:16   1 372.6G  0 disk  
    └─sdb1                    8:17   1 372.6G  0 part  
      └─md1                   9:1    0   1.5T  0 raid5 
        └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    sdc                       8:32   1 465.8G  0 disk  
    ├─sdc1                    8:33   1 372.6G  0 part  
     └─md1                   9:1    0   1.5T  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    └─sdc2                    8:34   1  93.1G  0 part  
      └─md2                   9:2    0 279.3G  0 raid5 
        └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    sdd                       8:48   1   4.5T  0 disk  
    ├─sdd1                    8:49   1 372.6G  0 part  
     └─md1                   9:1    0   1.5T  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    ├─sdd2                    8:50   1  93.1G  0 part  
     └─md2                   9:2    0 279.3G  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    ├─sdd3                    8:51   1 465.8G  0 part  
     └─md3                   9:3    0 931.3G  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    └─sdd4                    8:52   1   3.6T  0 part  
      └─md4                   9:4    0   3.6T  0 raid1 
        └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    sde                       8:64   1   7.3T  0 disk  
    ├─sde1                    8:65   1 372.6G  0 part  
     └─md1                   9:1    0   1.5T  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    ├─sde2                    8:66   1  93.1G  0 part  
     └─md2                   9:2    0 279.3G  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    ├─sde3                    8:67   1 465.8G  0 part  
     └─md3                   9:3    0 931.3G  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    └─sde4                    8:68   1   3.6T  0 part  
      └─md4                   9:4    0   3.6T  0 raid1 
        └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    sdf                       8:80   1 931.5G  0 disk  
    ├─sdf1                    8:81   1 372.6G  0 part  
     └─md1                   9:1    0   1.5T  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    ├─sdf2                    8:82   1  93.1G  0 part  
     └─md2                   9:2    0 279.3G  0 raid5 
       └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    └─sdf3                    8:83   1 465.8G  0 part  
      └─md3                   9:3    0 931.3G  0 raid5 
        └─storagevg-storage 254:0    0   6.3T  0 lvm   /Volumes/storage
    sr0                      11:0    1  1024M  0 rom   
    





  • The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

    I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… https://dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

    Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

    So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

    struct Channels {
      data: Vec<Channel>,
      by_number: BTreeMap<u32 /* or whatever */, usize>,
      by_name: BTreeMap<String, usize>,
    }
    
    // untested but I think it should compile
    fn get_channel_by_name(ch: &Channels, name: &str) -> Option<&Channel> {
      Some(&self.data[*ch.by_name.get(name)?])
    }
    





  • Yep. Lack of format support is usually to blame on the one who doesn’t support the format. You can absolutely blame Apple for this too though, their apps can’t open e.g. Matroska video or FLAC.

    And perplexingly, they don’t support uploading HEIC, their own image format of choice, on the web iCloud Photos. So there’s that too.

    (At this point my music library is stored as ALAC because it’s well supported in both Linux and Apple’s OSes. Really wish it wouldn’t have to be that way though. Someone needs to tell them about ffmpeg.)

    For example they used to have their own video container .mov

    It’s always very very funny every time someone mentions MOV, because while it’s very similar to MP4, it’s actually an open format while MP4 isn’t (!). You actually have to pay for the MP4 standard document while Apple just gives you the MOV documentation.

    Also at least taking a screen capture on macOS still gives you a MOV container, actually.