You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...or something of the sort, rather than doing group tests and assigning uaccess directly. udev ships with rules like these:
# software-defined radio communication devices
ENV{ID_SOFTWARE_RADIO}=="?*", TAG+="uaccess"
# 3D printers, CNC machines, laser cutters, 3D scanners, etc.
ENV{ID_MAKER_TOOL}=="?*", TAG+="uaccess"
The text was updated successfully, but these errors were encountered:
hmm, I'm not so sure if Glasgow fits their idea of a "maker tool". The examples they give hint more in the direction of making physical stuff than being used for electronics debugging and rev engineering.
Also this would tighten the dependencies for Glasgow: this ID_MAKER_TOOL was introduced with systemd 230, released 2016-05-21.
I'm not sure we gain anything by declaring being a maker tool. systemd will just give us the same uaccess. I actually like the GROUP="plugdev", TAG+="uaccess" approach, as it gives maximum compatibility with older and newer systems, be they systemd-based or something else.
I'm not sure we gain anything by declaring being a maker tool. systemd will just give us the same uaccess. I actually like the GROUP="plugdev", TAG+="uaccess" approach, as it gives maximum compatibility with older and newer systems, be they systemd-based or something else.
I agree with this. I also don't find "maker tool" a convincing classification.
...or something of the sort, rather than doing group tests and assigning uaccess directly. udev ships with rules like these:
The text was updated successfully, but these errors were encountered: