• 2 Posts
  • 494 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)?])
    }
    









  • What do you mean by “more powerful” wrt CMake?

    CMake is a turing-complete language with some APIs that Meson either doesn’t have an equivalent yet because it’s comparatively new (for example, until 2023, there was no built in way to get a relative path from two paths, and if you wanted that you had to shell out to an external program), or they aren’t going to add because it doesn’t fit their design.

    Meson is (intentionally) limited in terms of extensibility, instead it tries to come with everything built in that you need, even down to specific library support like Qt, from what it seems like to me. For example, you cannot define your own functions, it ships builtin modules but does not allow other packages to provide their own (for example like KDE’s Extra CMake Modules), to name a few that I’m familiar with and why I was put off using it so far.

    I have yet to see how actually limiting that is, going to try to move the project I’ve been working on for years that relies on some of these CMake features to Meson soon and see how it fares. But considering that big projects like GNOME use it all over the place it’s probably workable in practice, I’ll just have to rethink the existing approach a bit.

    Is that considered bait?

    Wasn’t it? Go’s build system is very much not what I would call an example of good design (exhibit A: load-bearing comments and file names).