Aussie living in the San Francisco Bay Area.
Coding since 1998.
.NET Foundation member. C# fan
https://d.sb/
Mastodon: @[email protected]

  • 11 Posts
  • 4.55K Comments
Joined 3 years ago
cake
Cake day: June 14th, 2023

help-circle

  • Yes, unstructured. Every script is its own special snowflake that does things a bit differently.

    There’s no guarantee of the verbs that the script implements. start, stop and restart are common, but the implementation is up to each individual script. I’m most familiar with Debian where some service (but not all) implemented it with start-stop-daemon, but other distros and OSes handled it differently.

    Basic, commonly needed functionality, like restarting a crashed service after waiting for some delay, need to be implemented per app.

    When sysvinit was widespread, there was a reason a lot of people used systems line supervisord to deploy services, rather than dealing with sysvinit scripts. It was a pain.

    Systemd units were a logical progression from supervisord services.






  • Do you have any actual problems with systemd, or do you just want SysV init scripts to stick around forever?

    Maybe systemd isn’t the best, but it’s way better than a bunch of mostly unstructured shell scripts, and more secure (it’s pretty easy to reduce privileges, sandbox the filesystem, restrict syscalls, etc per service just by editing the unit file)






  • you need at least two NICs to properly setup a firewall.

    I’m not sure I’d recommend it, but two (or more) VLANs on a single NIC would work fine too. This setup is usually referred to as “router on a stick”

    I’m not sure about other OSes or Linux distros, but it’s easy to add multiple VLANs on Debian. You load the 8021q kernel module, then add interfaces suffixed with the VLAN ID (e.g. if your NIC is ens3, you’d add ens3.10 to /etc/network/interfaces for VLAN 10). You’d also need to make sure the switch port is configured to allow VLAN10.

    Older NICs lead to regular crashes and/or slow network speeds.

    but the ones you’re suggesting (I350-T2 and -T4) are 12 years old.



  • not dependent on the server

    It doesn’t have to be - a developer could also provide a HTML file that the user can download and open locally.

    And to be honest, if someone had to build a user-friendly cross-platform GUI app for connecting to some sort of serial device, they’d probably just end up using web technologies (Electron or Tauri) anyways. May as well avoid the extra overhead of Electron.



  • IMO it’s fine since you need to explicitly grant permission for the site to use it, and also explicitly choose a device to allow it to communicate with. You can also configure your browser to always reject requests to use the API, if you never want to use it.

    WebSerial is useful for the developer as they can build their webapp once and it’ll work consistently across platforms, and it’s useful for the user since the same interface will work across all OSes.

    I prefer it over the other common approach for communicating with serial devices, which is often to only make a Windows app and to have some convoluted setup process involving sketchy-looking drivers, which then breaks when you have different devices that require different versions of the flashing software or drivers.

















Moderates