• 1 Post
  • 33 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
  • wouldn’t changing it just end up performative

    Exactly. Sidereal time does get rid of time zones and leap years, but it’s still referenced to a single physical object and relies on a arbitrary choice of start point. So it doesn’t create some perfect cosmic time standard.

    The international date line doesn’t help since that’s just 180° offset from Greenwich itself.

    The point of standards is that they can be followed by everyone. The AD/BC epoch is fine. The Greenwich meridian is fine. UTC is fine. Changing them would cause so much disruption that it cannot be worth it.

    Daylight savings can go die in a ditch though.














  • I’m using ATmega micros, on my Lily58. If I remember correctly, the default QMK behaviour was to use the USB to select which half was the master and what side it was on. That would work on RP2040 boards just as well so that may be what the provided firmware does.

    I would suggest you just flash them both then see what they do. If they are swapped, try connecting the USB to the other half. If that works then you don’t have a problem. There’s no risk of damaging them and the RP2040 is pretty easy to reflash.

    I wasn’t satisfied with that method and set QMK to store the sides in eeprom so I could use the same firmware but connect to either one. I’m not sure if the 2040 has a separate non-volatile memory so you’ll likely need a different method. I think a GPIO can be grounded to set the side but the Lily58 doesn’t do this. You could add a bodge wire if you want this but you have to customise QMK to use that method.


  • Is there any reason to keep the existing set-up? If it’s just one drive, you could replace it with another and install Alma or something fresh. Then you could copy over whatever config the old system had to get up and running again. You could swap to the old drive if you needed to revert. If you have a spare machine, you could stand up the fresh setup side-by-side with the old one before swapping over.






  • Ah, that’s the misunderstanding. The original comment was talking about “watching something on another pc”. Like playing a video from a desktop PC on a laptop in another room. So it’s the samba server we want to prevent from sleeping, not the client. Yes it’d be nice to have a 24/7 media server set up, but for the simple case of sharing a file from one PC to another, it’d be nice for the server not to sleep in the middle of it by default.


  • For sure, I don’t know the internals of Samba, but surely the server knows that it’s serving a file no matter how the client accesses it. I don’t think a few dbus messages would cause issues.

    I have my own service that looks at the network traffic via /proc and a few other things. That sends the system to sleep itself if everything looks truly idle.

    I do think it would be nice for a file server like samba to inhibit sleep using the standard interface for it. But yeah, I appreciate there are complications, like video playback is presumably pulling a small extent of a file at a time, so there would have to be some kind of timer before releasing the inhibition or the system would sleep between transfers.

    EDIT: I just took a look; with loglevel set to 3 for smb and smb2 I see log messages like:

    smbd_smb2_read: fnum 1712966762, file my_video.mkv, length=262144 offset=82366464 read=262144
    

    These occur at most 10 seconds apart when playing a video over a share from another host. I don’t see why the smbd daemon couldn’t inhibit sleep untill smbd_smb2_read hasn’t run for a minute or so. You could have a script that monitors that log output and does this externally but it’d be nice to have built in.