• 1 Post
  • 29 Comments
Joined 9 months ago
cake
Cake day: December 17th, 2023

help-circle

  • In my book WSL and VM share the same downside in that you’re only abstracting Linux functionality in relation to the hardware.

    Linux really shines when it has full access to the actual hardware as opposed to asking it’s environment nicely if it’s allowed to do something.

    For example, I routinely need to change my IP address to talk to specific networks and network hosts, but having to step over the virtualisation or interpretation layer to do so is just another step, thus removing the advantage of running linux in the first place.

    Sure, VMs and dual booting have their uses, but the same uses can be serviced by an actual linux install while also being infinitely more powerful.

    I played around with WSL for a while, but you notice really quickly that it is not the real thing. I’ve used virtual box for some use cases, but that too feels limiting ad all of the hardware you want to fully control is only abstracted.

    I would say that unless he has a really good reason why he wouldn’t want to go for dual boot, then he should do just that.




  • Pretty much when you posted that, I found this in my dmesg:

    [  715.744332] e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
    [  715.965683] e1000e 0000:00:1f.6: The NVM Checksum Is Not Valid
    [  716.008541] e1000e: probe of 0000:00:1f.6 failed with error -5
    

    Just for the record, I compared modinfo up against lspci, and the PCI ID matches, so the driver should work. Is it possible to ignore the NVM checksum and try anyway? Because any tool I can find that communicates with the EEPROM on a hardware level is made for msdos.








  • I don’t remember how many files, but typically these geophysical recordings clock in at 10-30 GB. What I do remember, though, was the total transfer size: 4TB. It was kind of like a bunch of .segd, and they were stored in this server cluster that was mounted in a shipping container for easy transport and lifting onboard survey ships. Some geophysics processors needed it on the other side of the world. There were nobody physically heading in the same direction as the transfer, so we figured it would just be easier to rsync it over 4G. It took a little over a week to transfer.

    Normally when we have transfers of a substantial size going far, we ship it on LTO. For short distance transfers we usually run a fiber, and I have no idea how big the largest transfer job has been that way. Must be in the hundreds of TB. The entire cluster is 1.2PB, bit I can’t recall ever having to transfer everything in one go, as the receiving end usually has a lot less space.