Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)NY
Posts
0
Comments
150
Joined
1 yr. ago

  • Rolling-release Linux distros such as Arch, Gentoo, and OpenSUSE Tumbleweed constantly release the latest updates, but they’re not used in businesses.

    So some businesses decided that monolithic releases were more important than being able to get the latest upstream vanilla kernel version, and somehow that's the fault of "all Linux kernel vendors" (including rolling-release distros, since there was no attempt to qualify "all") and not the businesses' decisions about tradeoffs?

  • To echo others here, you really need to kill the driver. There are a couple of different kernel modules that might be involved, depending on exactly how your touch panel is connected to the rest of the system. Software that has no specific touch support will likely treat your renegade hardware as a mouse, rather than ignoring it.

    You may be able to unbind the driver from the device, see this discussion on stackexchange.

  • Dude. I actually have sources for most of my installed packages lying around, because Gentoo. Do you know how much space that source code takes up?

    Just under 70GB. And pretty much everything but maybe the 10GB of direct git pulls is compressed, one way or another.

    That means that even if your distro is big and has 100 people on development, they would each have to read 1GB or more of decompressed source just to cover the subset of packages installed on my system.

    How fast do you read?

  • The only thing I miss about fusion 360 is an easy way to add fillets to parts, that can be tricky in openscad. I use chamfers for the most part though, so I don’t miss it much.

    There's an OpenSCAD add-on lib called BOSL that offers primitives with built-in fillet options (plus a wide array of other stuff, like premodeled metric bolts). Admittedly it spends a lot of time reinventing the wheel, but I've found it useful from time to time.

  • Granted, in a true multiuser environment with an admin who's carefully tailoring /etc/sudoers to make sure everyone has the least possible privileges that will allow them to still do what they need, sudo is more secure. There's no doubt of that.

    On a machine that has only one human user who's also the admin, and retains the default sudo-with-user-passwords configuration, su vs sudo is pretty much a wash, security-wise. su requires a second password to get root access, but sudo times out and requires the password to be re-entered while a shell created by su can stay open indefinitely. Which is more easily broken will depend on other details of your situation.

    (If you're running an incorrectly configured ssh server that allows direct root login with only password authentification, having a root password could contribute to problems, but the correct fix there is to reconfigure the ssh server not to do something so stupid. I hope there's no distro that still ships that way out of the box.)

  • The problem is that those modules are packaged by the developers as opt-out rather than opt-in. It's a variation on Microsoft's old embrace-extend-extinguish playbook, only the "extinguish" part hasn't worked so well because there are some stubborn distros whose needs don't align with what systemd provides and have maintainers that go out of their way to provide alternatives.

    (By contrast, although we may joke about emacs, it's the myriad of third-party extensions that cause it to just about be its own operating system—it doesn't all ship with the core.)

  • sudo is already an optional component (yes, really—I don't have it installed). Don't want its attack surface? You can stick with su and its attack surface instead. Either is going to be smaller than systemd's.

    systemd's feature creep is only surpassed by that of emacs.

  • Early true BIOSen were stored on EPROM, which couldn't be rewritten while on the board, so those were read-only.

    Later BIOSen were often on EEPROM or other chips that could be reflashed while on the board. According to Wikipedia, that started in the mid-1990s. However, you usually needed physical access and/or special software tools to do an overwrite—you couldn't mount these as a filesystem.

    UEFI is quite different from legacy BIOSen and can be mounted as a filesystem, but how much it can be tampered with varies between implementations and devices.

    So you would have been correct up until about 30 years ago, but not for modern systems.

  • Gentoo specifically switches off the telemetry (-Daudacity_has_sentry_reporting=off,-Daudacity_has_crashreports=off). The cloud saving facility is also off by default, but can be added to the build by enabling the audiocom USE flag.

  • You sometimes can build software that will work with more than one version of a C library, but less and less software is being written that binds only to C libraries. The key topic you want to look up is probably "ABI stability".