1. 3

    asciidoc and rst are both popular and capable languages for writing documentation, I’m not sure why the author seems to dismiss them so readily.

    1. 3

      Where do I dismiss them? I think asciidoc is really nice. It’s a much better choice than md.

      1.  

        Hmm, re-reading that I just got that kind of impression. They both just seemed to me like options you had looked at and dismissed. I think that FreeRADIUS does all it’s documentation as inline asciidoc, which means it’s really easy to change the documentation as you change the code.

        That’s the main problem I’m having with my documentation for terminator which lives in a separate repo so I don’t always remember to change it when I update the code, but I haven’t had any trouble with the RST formatting, though it did take me a while to get used to.

    1. 17

      Unfortunately, OpenRC maintenance has stagnated: the last release was over a year ago.

      I don’t really see this as a bad thing.

      1. 12

        Also, wouldn’t the obvious choice be to pick up maintenance of OpenRC rather than writing something brand new that will need to be maintained?

        1. 10

          There is nothing really desirable about openrc and it simply does not support the required features like supervision. Sometimes its better to start fresh, or in this case with the already existing s6/s6-rc which is build on a better design.

          1. 3

            There is nothing really desirable about openrc

            I’d say this is a matter of opinion, because there’s inherent value in simplicity and systemd isn’t simple.

            1. 5

              But why compare the “simplicity” to systemd instead of something actually simple, openrcs design choices with its shell wrapping instead of a simple supervision design and a way to express dependencies outside of the shell script is a lot simpler. The daemontool like supervision systems simply have no boilerplate in shell scripts and provide good features like tracking pids without pid files and therefor reliably signaling the right processes, they are able to restart services if they get down and they provide a nice and reliable way to collect stdout/stderr logs of those services.

              Edit: this is really what the post is about, taking the better design and making it more user friendly and implementing the missing parts.

          2. 3

            the 4th paragraph

            This work will also build on the work we’ve done with ifupdown-ng, as ifupdown-ng will be able to reflect its own state into the service manager allowing it to start services or stop them as the network state changes. OpenRC does not support reacting to arbitrary events, which is why this functionality is not yet available.

            also, the second to last graf

            Alpine has gotten a lot of mileage out of OpenRC, and we are open to contributing to its future maintenance while Alpine releases still include it as part of the base system, but our long-term goal is to adopt the s6-based solution.

            so, they are continuing to maintain OpenRC while alpine still requires it, but it doesn’t meet their needs, hence they are designing something new

          3. 3

            I was thinking the same thing.

            I have no sources, but when was the last time OpenBSD or FreeBSD had a substantial change to their init systems?

            I don’t know enough to know why there’s a need to iterate so I won’t comment on the quality of the changes or existing system.

            1. 12

              To my knowledge, there’s serious discussion in the FreeBSD community about replacing their init system (for example, see this talk from FreeBSD contributor and previous Core Team member Benno Rice: The Tragedy of systemd).

              And then there’s the FreeBSD-based Darwin, whose launchd is much more similar to systemd than to either BSD init or SysVinit to my knowledge.

              1. 4

                this talk from FreeBSD Core Team member Benno Rice: The Tragedy of systemd).

                This was well worth the watch/listen. Thanks for the link.

              2. 8

                I believe the last major change on FreeBSD was adding the rc-order stuff (from NetBSD?) that allowed expressing dependencies between services and sorting their launch order so that dependencies were fulfilled.

                That said, writing a replacement for the FreeBSD service manager infrastructure is something I’d really, really like to do. Currently devd, inetd, and cron are completely separate things and so you have different (but similar) infrastructure for running a service:

                • At system start / shutdown
                • At a specific time
                • In response to a kernel-generated event
                • In response to a network connection

                I really like the way that Launchd unifies these (though I hate the fact that it uses XML property lists, which are fine as a human-readable serialisation of a machine format, but are not very human-writeable). I’d love to have something that uses libucl to provide a nice composable configuration for all of these. I’d also like an init system that plays nicely with the sandboxing infrastructure on FreeBSD. In particular, I’d like to be able to manage services that run inside a jail, without needing to run a service manager inside the jail. I’d also like something that can set up services in Capsicum sandboxes with libpreopen-style behaviour.

                1. 1

                  I believe the last major change on FreeBSD was adding the rc-order stuff (from NetBSD?) that allowed expressing dependencies between services and sorting their launch order so that dependencies were fulfilled.

                  Yep, The Design and Implementation of the NetBSD rc.d system, Luke Mewburn, 2000. One of the earlier designs of a post-sysvinit dependency based init for Unix.

                  1. 1

                    I’ve been able to manage standalone services to run inside a jail, but it’s more than a little hacky. For fun a while back, I wrote a finger daemon in Go, so I could keep my PGP keys available without needing to run something written in C. This runs inside a bare-jail with a RO mount of the homedirs and not much else and lots of FS restrictions. So jail.conf ended up with this in the stanza:

                    finger {
                            # ip4.addr, ip6.addr go here; also mount and allow overrides
                            exec.start = "";
                            exec.stop = "";
                            persist;
                            exec.poststart = "service fingerd start";
                            exec.prestop = "service fingerd stop";
                    }
                    

                    and then the service file does daemon -c jexec -u ${runtime_user_nonjail} ${jail_name} ${jail_fingerd} ...; the tricky bit was messing inside the internals of rc.subr to make sure that pidfile management worked correctly, with the process finding handling that the jail is not “our” jail:

                    jail_name="finger"
                    jail_root="$(jls -j "${jail_name}" path)"
                    JID=$(jls -j ${jail_name} jid)
                    jailed_pidfile="/log/pids/fingerd.pid"
                    pidfile="${jail_root}${jailed_pidfile}"
                    

                    It works, but I suspect that stuff like $JID can change without notice to me as an implementation detail of rc.subr. Something properly supported would be nice.

                  2. 2

                    I think the core issue is that desktops have very different requirements than servers. Servers generally have fixed hardware, and thus a hard-coded boot order can be sufficient.

                    Modern desktops have to deal with many changes like: USB disks being plugged in (mounting and unmounting), Wi-Fi going in and out, changing networks, multiple networks, Bluetooth audio, etc. It’s a very different problem

                    I do think there should be some “server only” init systems, and I think there are a few meant for containers but I haven’t looked into them. If anyone has pointers I’d be interested. Desktop is a complex space but I don’t think that it needs to infect the design for servers (or maybe I’m wrong).

                    Alpine has a mix of requirements I imagine. I would only use it for servers, and its original use case was routers, but I’m guessing the core devs also use it as their desktops.

                1. 16

                  Yes, yes you can technically use a fairly restricted subset of C++ or whatever and then you can avoid some C-isms at the cost of risking runtime panics on the new operator.

                  If you’re referring to compiling with exceptions disabled, you avoid such crashes by using the nothrow variant of operator new, so an allocation failure just returns a null pointer.

                  There’s really no cost to using “C++ without exceptions and RTTI” relative to using C. Right now I’m working on a project for an embedded ARM32 device with 20KB of RAM and about 200KB ROM, and I’m doing it in C++. I’m using classes, references, and a few templates, but zero heap allocation, not even using the C standard library. Currently it’s about 30K of code and a couple hundred bytes of global data.

                  1. 9

                    Today I learned that was a thing! I’m not up to snuff on C++ (it’s always scared me) but I’ll see about editing that quip in a bit.

                    1. 1

                      C++ is simpler than Rust, if you don’t try to make your own templates. There’s kind of a bunch of features that all add on to C — references, overloading, classes — that you can mix & match. And using the standard templates like vector, optional, map, etc. isn’t too bad, although the design isn’t the greatest. But actually creating templates is kind of a rabbit hole that I’ve never gone very far down.

                      In general, though, I don’t see why anyone would write C anymore. It’s like Middle English.

                      1. 1

                        It’s like Middle English.

                        Muffled sobbing from the corner where J.R.R. Tolkien is quaffing ale

                        1. 1

                          Aye, I was unhappy with that simile but had to finish the comment in a hurry because real life.

                          How about “it’s like a steam engine?”

                        2. 1

                          C++ standards move much faster and tend to break compatibility more, the ABI guarantees are much less useful, compilation times are much worse, etc. Some people just prefer a simpler, more stable language.

                          1. 3

                            For *NIX platforms, the C++ ABI is the Itanium ABI and this has remained backwards compatible for about 20 years. GCC 3.0 was released in 2001 and every version of GCC and clang since then has supported the same ABI for C++.

                            The ABI of any given library is typically weaker, but C++ isn’t worse than C in this regard. If you modify a struct layout between C library versions, you break the ABI. Similarly if you add or remove fields in a C++ class or struct, you change the ABI. If you expose a struct of function pointers in C and change the layout, you break the ABI. If you add or remove vtable methods in a C++ class, exactly the same applies.

                            1. 1
                              1. All I can say is I haven’t had problems going from ’11 to ‘14 to ‘17, but then I always turn on lots of warnings and -Werror and run UBsan, so maybe I don’t leave questionable stuff in my code that hits such edge cases.
                              2. The ABI is unquestionably really poor for things like dynamic libraries, but it’s no worse than C’s since all you have to do is add some extern “C” and you’ve got the C ABI at library boundaries.
                              3. Yes, but unless your codebase is huge they’re not terrible. Even when I worked on Chrome ten+ years ago, on a 2008 Mac Pro with a spinning disk, turnaround times were about 20sec in most cases. In my current project it’s more like 5sec.

                              IMO these things are worth it for a more expressive, safer language where I’m not constantly juggling raw pointers and manual memory management.

                              1. 1

                                All I can say is I haven’t had problems going from ’11 to ‘14 to ‘17, but then I always turn on lots of warnings and -Werror and run UBsan, so maybe I don’t leave questionable stuff in my code that hits such edge cases.

                                I’m speaking from the perspective of a distributor / package maintainer, where I have much more trouble keeping C++ code from a few months ago working (whenever anything is changed, be it boost or the compiler) compared to C code from 20 years ago.

                            2. 1

                              C++ is simpler than Rust, if you don’t try to make your own templates

                              That’s a little bit sad, because for systems-programming tasks templates are exactly where C++’s power comes from. For example, snmalloc’s platform abstraction layer is built using templates and inlines to either nothing or calls to individual platform-specific code. Actually, snmalloc uses templates all through the codebase, making it really easy to plug in different bits of behaviour.

                              It’s much harder in C to create type-safe compile-time specialisation. The C++ template syntax is pretty painful, but once you get comfortable with it then you have a vastly more powerful language. We generally turn off exceptions and RTTI and strongly discourage inheritance in C++, but we get huge benefits from templates.

                              Most recently, I wrote some code that inspects the mcontext in a signal handler for signals that are raised from sandbox violations, pulls out the arguments from the frame, calls a function that does an IPC to emulate the system call in the parent process, and then injects the result back into the signal context. I have absolutely no idea how I’d write this in maintainable C, but in C++ there are Linux and FreeBSD that abstract over the details of the signal frame, a templated function that invokes this with types extracted from the argument types of the function that handles the fallback and then a generic lambda that invokes the template function with inferred type arguments. If you look at the generated code for the release builds, this folds down to a handful of instructions. In C, I can’t imagine this being anything other than either a bunch of scary type casts and incomprehensible macros.

                              1. 1

                                I agree templates are really powerful, but in my experience they’re the sharp knee of the language learning curve. My post was aiming to let C users know they can approach C++ as a set of very useful and tasty condiments they can pick and choose from to add to the vanilla soft-serve that is C. Defining templates doesn’t fit there.

                                1. 1

                                  I’ve seen people take that approach and they tend to write the kind of awful C++ code that makes other people avoid C++. Templates have a steep learning curve, but they (especially in composition with constexpr) also have a huge return on that investment. The big benefit of C++ over C for low-level tasks is the ability to do aggressive compile-time specialisation.

                          2. 1

                            The bigger problem in Linux is that most of the headers are invalid C++. I recently tried writing C++ code in the Linux kernel. In the FreeBSD kernel it’s mostly fine (I needed to undefine a few macros) but with Linux you get huge numbers of compiler errors just from a single #include when the language is set to C++.

                            1. 1

                              Ow! That’s awful. It’s very rare that I run across a C header I can’t use in C++ simply by wrapping extern "C" { ... } around it. I’ve done a bit of Linux coding, but only using the standard C library headers, never kernel stuff.

                          1. 8

                            Looking at this, it’s kind of interesting how many unstable protocols there are compared to core/stable ones, especially for stuff like layer shells that are important for things people take for granted in modern desktops (in layer-shell’s case, notifications that appear above your other windows and the like).

                            1. 9

                              It is the endless cycle of open source: you declare the old thing bloated and obsolete, throw it away and rewrite it, then eventually copy and/or reinvent the whole old thing eventually since it turns out the original authors actually had their reasons. Then the next generation calls your thing bloated and obsolete…

                              1. 3

                                I expect it’s due to a fairly small number of people working on the protocols and implementing them personally. Based on my experience with Sway/wlroots, most of the protocols appear to be defacto Stable Enough.

                                Plus, having made some minimal attempts to read these docs directly, it’s difficult to get a handle on them and understand how they fit together. This site is honestly pretty great.

                                1. 8

                                  Based on my experience writing a compositor, protocols are unstable and applications break compatibility frequently

                              1. 1

                                This is a really interesting article for FVWM3. Not too much seems to be tied to NetBSD other than installing packages and things like the exact volume control commands.

                                Also it’s maybe obvious, but a screenshot of the result is at the very bottom.

                                1. 1

                                  What’s up with the shrunken “mc” and “vi” windows (?) on the left of that screenshot — I’ve long since forgotten anything I ever knew about mwm… does it shrink/dock windows like that?

                                  1. 4

                                    twm-like window managers often minimize windows by putting an icon on the root, I think that’s just a preview of a minimized window.

                                    1. 1

                                      This says a lot about users of the desktop today… goodness me.

                                      1. 1

                                        It says a lot that I haven’t used CDE since the 1990s? There’s a lot I’ve forgotten in the past 25 years :-)

                                  1. 1

                                    There is a person assigned to m68k.

                                    I am hopeful about possibly reinstalling my Amiga 1200’s Debian (currently 10+ years old).

                                    1. 4

                                      Fun Debian installer story: my friend basically got the ia64 port killed because he filed a bug report that it wouldn’t install. All they had to do was add a module to the install kernel, but instead they just killed the port.

                                      1. 4

                                        IA64 is an extremely dead platform though.

                                        1. 8

                                          It’s dead for purposes of running operating systems like Linux. If you have IA64 in 2021 you’re a company that has some application relying on either OpenVMS or HP-UX. The problem was that if you had a critical high-availability OpenVMS application, you had nowhere else to go other than IA64, but now OpenVMS is being ported to x86 and IA64 is going out of production, that situation’s changing.

                                        2. 1

                                          When did that happen?

                                          A person is still listed as assigned ia64 tester: https://wiki.debian.org/DebianInstaller/Tasks

                                          1. 2

                                            About a decade ago, IIRC.

                                      1. 2

                                        the link to the statement is broken, here’s the correct one

                                        1. 3

                                          Switched all links to HTTPS before publishing, and didn’t recheck this one :-) Fixed, thanks!

                                        1. 2

                                          PC Engines apu1 running NetBSD performing standard routery things like DHCP, firewall via NPF, etc, with some PoE WiFi access points.

                                          1. 8

                                            Ugh, another one bites the dust — without giving the BSDs a chance. Try OpenBSD, the out of the box experience is the most pleasant one I’ve had yet, more so than macOS even, because it does exactly what I want it to.

                                            I have to use a MacBook for work, and while the UI is pretty and all, I find its tiny quirks and overall rigidity very annoying. I can’t do things the way I’d like to.

                                            1. 7

                                              without giving the BSDs a chance.

                                              I gave FreeBSD a serious chance for months. I hacked a little on i915 trying to fix some backlight bugs. I contributed to what became the implementation of the utimensat syscall implementation for the Linuxulator. I was even featured on an episode of the original BSDNow in 2015.

                                              I suppose you could argue some value of stability and release engineering still exist in FreeBSD, but they’re even more hostile to older hardware and the desktop experience is even worse as more and more software assumes Linux.

                                              1. 3

                                                One reason I like my OpenBSD Desktop is that it is still running great on my 2012 Toshiba Portege - I’ve upgraded the RAM to 16Gb and the HDD to an SSD - the only draw back is getting decent batteries for portability is now becoming an issue. But I have heard that OpenBSD may be coming to the M1 in the near future :~)

                                                1. 3

                                                  The entire time reading this article I was thinking that NetBSD would be a much better fit for you than Linux

                                                2. 7

                                                  Ugh, another one bites the dust — without giving the BSDs a chance.

                                                  did we read the same article

                                                  1. 5

                                                    The article complains Go’s PowerPC baseline is POWER8. OpenBSD’s PowerPC baseline is POWER9…

                                                    1. 5

                                                      There are two power ports: powerpc64 (POWER9) and macppc (G4/G5 and maybe G3).

                                                      Browser support in macppc was pretty abysmal last I checked though.

                                                      1. 3

                                                        macppc supports all New World models, including the G3.

                                                        I think NetBSD is probably the best of the BSDs for running on PowerPC, if we’re talking about it; in addition to macppc they have ofppc, amigappc, bebox, etc.

                                                    2. 3

                                                      As a Mac user who mostly likes the way it works on the surface, I wish it were as straightforward beneath the surface as a BSD.

                                                    1. 6

                                                      I admire Jason’s commitment and approach to doing things. Given this experience, this makes me wonder about the quality of code in FreeBSD for other protocols.

                                                      1. 6

                                                        I’d just like to understand how the code got committed to the mainline branch/trunk if it was of such low quality?

                                                        I’m certain I’m missing something here but I’m also too busy to go digging around in the repo history + mailing lists to piece together the full story.

                                                        1. 8

                                                          In BSDs the main branch is the development branch. If we’re not sure something is ready to be used in production, but is under active development, it will be committed to the main branch, but is either not hooked up to build or otherwise disabled by default. This is to facilitate testing and review and contributions from others who want to test the system as it evolves (“those who run -CURRENT”).

                                                          I’m a NetBSD developer, not a FreeBSD developer, so I’m not an authoritative source on their development process. Jason has also objected to NetBSD independently developing a “WireGuard compatible VPN interface” (note the name of the specification is a registered trademark) without his oversight, and then not responded when asked to state his exact problem with the code or identify exact bugs for more than 6 months. The implication that the specification is complex or incomplete enough that his involvement in any implementation is required is worrying at best, but definitely good for job security (though it’s also worth noting serious bugs have been found in implementations he did spend a year visiting developers’ homes for).

                                                          1. 6

                                                            For the audience at home, here is the thread. I think Jason looks somewhat suspicious in it, with how he makes vague threads and claims about NetBSD’s implementation, but can’t point out anything concrete.

                                                            1. 5

                                                              If you read the linked thread, as well other *BSDs’ mailing lists, you can clearly see that he doesn’t consider anything he hasn’t personally touched to be worthy. WireGuard is clearly his baby - he’s both the author of the specification as well as reference implementation… problem is, that he doesn’t like any other (competing?) implementations of any sort. He actually makes it quite clear that WireGuard isn’t an RFC-style protocol - and every single implementation seems to need his personal blessing.

                                                              In that particular thread, it very much looks like he barges in both barrels blazing and makes demands such as Revert this code at once, sir! (I’m paraphrasing here) without actually spending some time reading how development is done in NetBSD - even after they, repeatedly(sic!), try to tell him this is the development branch.

                                                              For the record, the right thing to do would be to have sought input from the WireGuard project during those two years, which we would have enthusiastically provided, and maybe NetBSD would have this ready to go years ago. It strikes the project as rude that you’d write some halfbaked code and try to pass it off as “wireguard”, ruining what to date has been a uniform experience for users in using WireGuard across platforms. The fact is, you jumped the gun and didn’t reach out beyond your community.

                                                              […]

                                                              Again, while I’m not happy with this situation and the inflexibility here, […]

                                                              Who’s being rude and inflexible here?

                                                              Beyond the offers of help, time, energy, enthusiasm(!?), etc. all I can read between the lines are ego, grandeur, and the need for benediction.

                                                              1. 3

                                                                That is really bad behavior – it’s full-on micro-management that is really destroying any kind of relationships in the long run. I hope Jason will learn to let go, as this will just erode the trust and fail to create a progressive community around WireGuard.

                                                                1. 1

                                                                  I’ve been talking with him (Jason) in private and can vouch for him. There’s more that’s going on that meets the eye.

                                                              2. 2

                                                                Ah - that makes perfect sense. Thanks for the explanation and additional context.

                                                              3. 5

                                                                A blog post by Netgate now links to the original change request: https://reviews.freebsd.org/D26137 – I think this just proves the maxim: “Make a ten line change and you’ll get 11 comments, make a 1000+ lines change and you’ll get LGTM”. The blog post author boasted that there were 92 comments, which I still think is way way too little for a 40k+ lines change that touches security and networking.

                                                                1. 3

                                                                  Of all the (main? net, open, free) BSDs, I think FreeBSD is most willing to include all sorts of code.

                                                              1. 9

                                                                Adopt evdev in your kernel. Stop trying to get people to use your legacy input API. Resistance is futile. :P

                                                                Seriously, libinput includes years of effort that went into developing full, high-quality support for touchpads and pen tablets. You are not going to reimplement all that. By trying to stick with old input APIs, you’re practically limiting yourself to only supporting basic mouse input, and you’ll need to keep patching everything all the time.

                                                                Legacy APIs like wscons (Linux had one like that too in the old days) are extremely restrictive and prescriptive — “this is a mouse, it has X/Y and scroll and buttons”. evdev is fully open-ended, it’s kinda like passing HID events through to userspace with slight simplification/normalization. This lets userspace (libinput) interpret all the things in the best way possible and support all the awesome new kinds of input.

                                                                So in FreeBSD we can just, say, run RetroArch or Kodi directly on DRM/KMS with full input support including PS4 and Xbox360 gamepads, without patching anything because we have the evdev drivers. The evdev ecosystem is so rich that I could even like, forward said gamepad over the network. I can record multi-touch gestures on my laptop and replay the events on my desktop for testing applications. And so on.

                                                                In pkgsrc we’ve patched the libraries to add kqueue(2) support

                                                                libepoll-shim already supports all the BSDs. It’s been heavily tested by years of daily use on lots of FreeBSD desktops. You can just use it instead of spending time on patching, which inevitably includes developing additional bugs for yourself to debug ;)

                                                                Updating the NetBSD kernel DRM/KMS stack

                                                                Huh, it’s so out of date that it doesn’t have atomic modesetting? OpenBSD is very up to date, with Linux 5.7 code even — I just kind of assumed that NetBSD was keeping up with OpenBSD, guess I was very wrong?

                                                                1. 10

                                                                  “This lets userspace (libinput) interpret all the things in the best way possible and support all the awesome new kinds of input.”

                                                                  It barely supports any of what is actually ‘new’ kinds of input devices (true for both evdev and libinput), the support it has for what little it can do is rigid as all hell and not ‘the best way possible’; if you want to go ‘appeal to authority’ we should just suck it up and port libhardware/inputhub as that is the evdev abstraction with billions of hours of use behind it. Ultimately we’ll hit the same “oh this design permeates everything and irreparably blocks latency and performance work and we can’t hack around it the way windows does” but fdo desktop won’t reach that point in half a decade still, if ever.

                                                                  For the sake of it, I wrote this reply using only my eyes and no evdev.

                                                                  1. 5

                                                                    Multi-touch touchpads, touchscreens, drawing tablets and high-res-wheel mice are very “new” relative to what legacy APIs like wscons support, which is literally only basic mice. I wonder what “even newer” devices you have in mind. (upd: I guess “wrote this reply using only my eyes” is a hint.) You’re always ahead of the whole world and smarter than everyone else :)

                                                                    1. 5

                                                                      Except the “distance” from wscons to those devices is smaller than the over-generic crap evdev provides, ignoring the bits about force-feedback, LEDs and identity (what “is” /dev/input/event0 ? a race condition if you have systemd.) where it entirely fails to capture what the devices can do and settle for a “1999- usb-hid 1.1) model (that’s where evdev design stopped by the way). Extend the structs as time progress, sizeof() for versioning, bump the kernel and be done with it – not this whole ioctl-“EVIOCGUNIQ, EVIOCGBIT, EVIOCGBIT’ 1kloc switch to figure out that a mouse is a mouse but perhaps it is a keyboard in a mouse or it is a mouse that identifies as a keyboard with a scroll wheel schtick. For ’BSD a reasonably simple device model is the least of their struggles.

                                                                      WIth pratical evdev in linux userspace, anyone who actually factually is forced to use the thing ends up with heuristics, databases and tears. Nothing is certain and nothing is stable even if the kernel knows or could know better. “Oh this here device, if it exposes 63 buttons it is a gamepad but 67 it is a keyboard” – that’s in udev somewhere btw.). Don’t take my word for it, why should you, just look at the SDL2 database of “fixups”. That’s still “analog + digital” not even the spectrum of what it tries to expose (force-feedback and LEDs).

                                                                      The grander problem with the ‘model’ is that read(), unpack(), filter(), foward() looks super simple when you write it and post to phoronix about the grand project. Then somewhere along the road comes “this here PS4 controller has 48 analog axes that sample at 1kHz / s. each amounting to a syscall or 4 before it reaches the consumer and now 40% of my CPU is doing nonesense”. As soon as you step out of the ‘simple’ model you are either underperforming and hiding the fact (evdev) or have an actual interface for the purpose.

                                                                      I wonder what “even newer” devices you have in mind. (upd: I guess “wrote this reply using only my eyes” is a hint.)

                                                                      Some examples that you can get today without qualifying for disabilities, dabble in VR, collect arcade hardware or have a 3d-modeller at AAA gamedev tool budget for - 3Dconnextion space-nav, Tobii-5C, Asus ScreenPad, ElGato Stream Deck (all in the big box of toys for the moment).

                                                                      You’re always ahead of the whole world and smarter than everyone else :)

                                                                      Well I’m not - but, I did work on a SONY specialist team with input, graphics and security (they’re connected) from ~2009 into 2015, and I switched to doing work on assistive devices for special needs since then. I had “group” therapy with themaister/squarepusher back when they had the ‘evdev’ struggle for rarch. More importantly, I do have frequent beers with people who actually advance the field and that helps.

                                                                      1. 3

                                                                        Extend the structs as time progress, sizeof() for versioning, bump the kernel and be done with it

                                                                        Okay sure whatever, have fun patching everything that expects evdev. But nobody has done that in practice yet :/ This is what gets me – it’s late 2020 and the evdev-resistant BSDs still haven’t extended their APIs for multi-touch. How can anyone live without multi-touch? Without touchpad gestures?

                                                                        what “is” /dev/input/event0 ? a race condition if you have systemd.

                                                                        I’m not sure when a race condition would matter here (nothing should rely on fixed device numbers), but I always disliked how Linux populates /dev from userspace..

                                                                        1kloc switch to figure out that a mouse is a mouse but perhaps it is a keyboard in a mouse

                                                                        Usually this doesn’t need that many lines, a simple heuristic takes like 150 lines max and works really well if your kernel exposes a “keyboard in a mouse” as a separate device.

                                                                        The kernel has to do heuristics on USB HID anyway, and it’s not guaranteed that it would know better. Certainly in userspace it’s easier and faster to update them?

                                                                        this here PS4 controller has 48 analog axes that sample at 1kHz

                                                                        That sounds ridiculous, I wonder what the device is (VR something..?) Why would it sample so much faster than the system can render? Competitive Counter-Strike players love their 1000Hz mice because they think they can feel the microscopic latency advantage, but that should not matter for a console.

                                                                        1. 1

                                                                          That sounds ridiculous, I wonder what the device is (VR something..?) Why would it sample so much faster than the system can render? Competitive Counter-Strike players love their 1000Hz mice because they think they can feel the microscopic latency advantage, but that should not matter for a console.

                                                                          Even your touch display is typically clocked and dynamically re-clocked at multiples of the display (processing naturally ‘bins’ around display vrefresh clock) so that samples are artificially paced or can be resampled to compensate for poor event processing further down the chain, 1000Hz isn’t much at all. You also sample at much higher rates and then filter later in the chain to account for the hardware degrading over time; fail to provide the right controls at the right layer for that and you have the ‘analog drift’ recall / repair that, for instance, Nintendo Switch suffers.

                                                                          It’s not exactly 48 but it’s not that far off on the dual shock itself* if you start looking at what the thing can do though current firmwares are much better at not fire-hosing the rest of the system - Recall it has multi-touch, a full IMU, an extension bus, builtin- speakers. (Feature set shifted a bit, PS3 version was notoriously loud as even the dpad/square,tri,… buttons were pressure sensitive).

                                                                          1. 1

                                                                            Touch displays on mobile devices were 60 Hz for a long time. IIRC Apple loudly advertised their switch to 120Hz touch, probably as a marketing trick to kind of leverage people’s hype for higher-Hz display :)

                                                                            PS3 version was notoriously loud as even the dpad/square,tri,… buttons were pressure sensitive

                                                                            Hoooooly shit, TIL. I suppose none of the PS3 games leveraged that though? Haven’t heard about this from the RPCS3 emulator devs..

                                                                            can be resampled

                                                                            Heh, rarely has anyone bothered to do that in the freedesktop world.. until I landed a kinetic-scrolling-on-gtk patch in Firefox and one person noticed that it feels kinda jittery on their external trackpad, and eventually patched GTK to interpolate the events.

                                                                            1. 1

                                                                              What the specs or marketing said I don’t really care, you could squeeze it much higher but getting it reliable/accurate is a different story, but now it’s close to NDA territory. Working with the raw “heightmap” is much more interesting than the I2C/SPI aftermath (and there it becomes obvious why some advanced forms of arthritis and similar conditions have problems with multitouch). https://www.youtube.com/watch?v=bW07-iPqaEk is literally a video from parts of a measurement rig on the thing back in ~2014.

                                                                              Hoooooly shit, TIL. I suppose none of the PS3 games leveraged that though? Haven’t heard about this from the RPCS3 emulator devs..

                                                                              AFAIR there were some driving games, some choking gimmick in metal gear solid and probably elsewhere. I would suspect some enterprising fighting games would use it for latency, it’s not like you can easily “stop” when you’ve started. Fun tidbit, same is true for touch - before you make contact with the surface the sensor knows you’re there and what you are about to do, an opportune time to increase some clocks and adjust scheduling ..

                                                                          2. 1

                                                                            kay sure whatever, have fun patching everything that expects evdev. But nobody has done that in practice yet :/ This is what gets me – it’s late 2020 and the evdev-resistant BSDs still haven’t extended their APIs for multi-touch. How can anyone live without multi-touch? Without touchpad gestures?

                                                                            As for Net/Open not doing the work to expand wscons in particular; I don’t think it’s more complicated than having much bigger fish to fry in order to maintain or widen the niche that even reflecting on these things is not really on the map. Should the situation remain the same when I am at that stage of performance tuning I’ll happily write the patches.

                                                                            Personally I don’t know for what case you would want touchpads, much less multi-touch gestures, outside of mobile for anything other than explicit “pointing” - fragile, imprecise and poor haptics. Scroll/zoom/pan are better with 3D mice or, for smaller budgets, rotary controllers.

                                                                            Usually this doesn’t need that many lines, a simple heuristic takes like 150 lines max and works really well if your kernel exposes a “keyboard in a mouse” as a separate device. The kernel has to do heuristics on USB HID anyway, and it’s not guaranteed that it would know better. Certainly in userspace it’s easier and faster to update them?

                                                                            You want the filterchain to be consistent and configurable across every layer so that you can remap, reconfigure increment/decrement sample rates, Kalman-esque sensor fusion and mask / discard at the earliest stage possible or input will remain the same jittery mess. If that would take some BPFy solution so be it. Udev and worse fixup databases are anything but the way to go. Linux is too far along that there really isn’t a choice anymore but to further the ad-hoc hackfest they’ve created for themselves. BSDs can lead by example and not spread the taint.

                                                                            1. 1

                                                                              Scroll/zoom/pan are better with 3D mice

                                                                              You’re not gonna carry a 3D mouse to zoom a PDF on a laptop on the go, right?

                                                                              Have you never used a MacBook? When I got one in 2010, I became instantly used to panning, zooming and rotating images and PDFs, and flicking between desktops with four finger swipes. I don’t even use multiple desktops that much, swiping between them just feels good. I literally reimplemented that feature in Wayfire so I could do that again in my compositor of choice :)

                                                                              increment/decrement sample rates

                                                                              Hmm, but usually HID is interrupt driven, the only sample rate change I know of is that my mouse can do that in its firmware in response to me toggling a physical switch. You could skip every Nth interrupt to reduce rate on the computer side but idk how that would work with relative axes especially..

                                                                              1. 1

                                                                                I have a macbook pro or three in the pile though they are exclusively for doing unsavoury things to iphones.

                                                                                GPD Pocket 2, kobo reader and Surface Go mostly when mobile - still I use the surface dial or modified capto-glove for anything analog.

                                                                                Hmm, but usually HID is interrupt driven, the only sample rate change I know of is that my mouse can do that in its firmware in response to me toggling a physical switch. You could skip every Nth interrupt to reduce rate on the computer side but idk how that would work with relative axes especially..

                                                                                You can still have an accumulator and some filters on interrupt before passing onwards. Although it would surprise me greatly if it is not polling on the wire but appears interrupt driven in software, but with everything-goes when HoG and whatever USB3 has added into the mix I don’t think I know anything about that space anymore. Anyhow, quick linux ref (https://wiki.archlinux.org/index.php/Mouse_polling_rate).

                                                                        2. 5

                                                                          And that’s why the touchscreen on my ThinkPad Yoga was working out of the box in 2018 and Wacom tablets just work on NetBSD as well.
                                                                          Give it a rest.

                                                                            1. 3

                                                                              Be honest, have you been on Github for the last ~ 20 minutes? :) (edited time)

                                                                      2. 7

                                                                        Stop trying to get people to use your legacy input API.

                                                                        Tech is full of people who are convinced that their way is the only correct or “non-legacy” way of doing things. Other fields have mostly matured past this.

                                                                        this is a mouse, it has X/Y and scroll and buttons

                                                                        It’s not the only way of doing things, but it’s a convenient abstraction to program for. If you read a lot of code that does libinput things, this is often all it cares about… Absolute or relative coordinates from one or more pointing device, buttons, and scrolling.

                                                                        libepoll-shim already supports all the BSDs.

                                                                        This is definitely news to me, and to the patches in our tree. Did you only test it on FreeBSD?

                                                                        Huh, it’s so out of date that it doesn’t have atomic modesetting?

                                                                        Yes, we have less funds and less humanpower than your project. And yes, we’re at 4.4.

                                                                        Anything else you’d like to be smug about today?

                                                                        1. 2

                                                                          This is definitely news to me

                                                                          Note that the upstream is https://github.com/jiixyj/epoll-shim – there is an outdated fork on the FreeBSDDesktop organization, ignore that. The readme definitely suggests the author has tested it everywhere.

                                                                          yes, we’re at 4.4

                                                                          Oh, atomic landed in 4.2 so you should have it?..