From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8737C1580B9 for ; Mon, 23 Aug 2021 19:51:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4BCADE0ACA; Mon, 23 Aug 2021 19:51:34 +0000 (UTC) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8EFFDE0A82 for ; Mon, 23 Aug 2021 19:51:33 +0000 (UTC) Received: by mail-il1-x133.google.com with SMTP id j15so18238461ila.1 for ; Mon, 23 Aug 2021 12:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GstL+oTnPtc8FX8Z0+z2d/Y0PBrhafg6SRIrV9WmkqY=; b=GMsZNYH53KzZRIAwtvV3/LCD5qAL8dHkLlncbKI9Dmbz00dzpwxSvb7awMn8LaK9oX P/jo9OCbhujC4SEJweMwREHsPeIu5xZdEeiXUTOX1nNFXgGmr7GbmqBFc3j+HOCVIZva vyfHj9Uy8TbYnQ5spilVXpl88aeWTyD+eQt8dp3icvZl63Mj+HZZEvWCJPLsgvTUkW2p a79cdNzxpsJp47qwW4Qjn7eByLlFCdjYifIrH9g1dGH2RLeOOs6nfIUgohO9DgW4IqVr ltaGFMDbu2SWc5sGwyfwFXvGE3rAgu7NF9mwL3L/oKsGRwy4R11oDpXX1qknUOdPJFkf eDgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GstL+oTnPtc8FX8Z0+z2d/Y0PBrhafg6SRIrV9WmkqY=; b=oCBiG37wbQUk1FzutBz4DR44AFzLFqJd35VVUgxNEXQKwMm/ZNiMrfWZoxFwg+54Ut ygmmbI0MX7aR/D61xlbdpArh5plniSR6yg1YR0r53FgUjw7xyB1JbMcXFeU2KvAGlWYV c8kDS6ftslYZ8rPZG+9/fc04M1h8vbKUa2faojHBVKGWJI5qpeQtt3Irqh/lCCSHVSGu byl8z6LAgWYcf+TUK0PNzlaFF1vgk+jSYAb0rCCQ3pkcEmV2iRIU/BNpxFbQP8eG79QE QWDOc98HX8xFpkp7qmA1ntpbjsqwoTrfv2gFA59jme5DnXPbdGV+aB7qJBl77Tt1+WK3 ctHg== X-Gm-Message-State: AOAM5313kadfCj67Wv0nQ2wZdTJFkvwb14mYf8Y2URPT2UbZwKUJ730t XkAdXSPqG/3AyVKnJCvzqx5XfH9CGP/tsdkOALUobkQU98IG+tIT X-Google-Smtp-Source: ABdhPJwB76Yu+pjcIkwoTYHrUDISbxzfbK+qIebjZ6Y5YZFLR4fVB3wcs85J2J56xDGqDfbzvESc0D6E/ZzTwQAJiIg= X-Received: by 2002:a92:d7c1:: with SMTP id g1mr24408661ilq.24.1629748292531; Mon, 23 Aug 2021 12:51:32 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20210821201720.13F158517F49@turkos.aspodata.se> <20210822203110.5C6BB8517F53@turkos.aspodata.se> <18ae899b-a172-75ce-b7e5-b998fb672f46@youngman.org.uk> <20210823160738.208C58517F54@turkos.aspodata.se> In-Reply-To: <20210823160738.208C58517F54@turkos.aspodata.se> From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= Date: Mon, 23 Aug 2021 14:51:21 -0500 Message-ID: Subject: Re: [gentoo-user] X11 without udev/eudev To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000000cba1705ca3f582b" X-Archives-Salt: 050831e4-d920-48d0-88b9-31dbf104c9d1 X-Archives-Hash: 70b729a026f1f47e6a4d59399df4be70 --0000000000000cba1705ca3f582b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2021 at 11:07 AM wrote: [...] > It is inconvenient that thoose two goes away. Regarding udev, it has neve= r > supported serial mice, so it doesn't help me. > What are you talking about? Udev doesn't "support" any hardware; as the manual page states[1], it: "supplies the system software with device events, manages permissions of device nodes and may create additional symlinks in the /dev/ directory, or renames network interfaces". If the kernel supports the hardware, udev will supply the corresponding event, so udev will generate the corresponding event for serial mice also (probably close to boot time). [...] > Poeple write whatever software they want to or are paid to do. It is my > call if I want to use that software or not. > Well, yeah; but if you want to use software X, and X depends on Y, then you either use software Y or don't use software X. The dependency chain can and will grow depending on several factors, and it's the situation here if I'm not mistaken: you want to keep using keyboard and mice, those depend on libinput, and libinput depends on udev. There are alternatives, of course; some members have posted several working ones; but the fact is that either you accept the dependencies dictated by the software you want to use, or you need an alternative that *someone* has to write/debug/maintain, etc. You said: "[u]dev should be an optional daemon, utilized when the local administrator decides to do so," and that is simply not true: if a software you use decides to depend on udev, then you either use udev, or need to change to a different software. > As I wrote before, udev does not handle serial mice, so udev does not > solve anything for me nor does it help me in any way to run my systems. > You are saying it wrong, you mean to say: "to handle serial mice, I don't need udev". And that is 100% completely true; you can keep a static /dev, don't use udev and create the device nodes by hand. But serial mice work great under udev also. The thing is, the *GREAT* majority of users need support for dynamic hardware, so the developers of most of the software in Linux solve the general problem: dynamic hardware (which includes static hardware also). So they do that, and you complain about daemons that are needed for other people other than you. But you didn't write the software that depends on udev; someone else (worrying about the general problem) did. So either you write your own version, or find someone else who does (again, check the alternatives). > Udev is just something pushed on me for no gain except possible to satisf= y > some dependancy touted to be beneficial. For no gain *TO YOU*. You want software that someone else wrote to cater to *ONLY* your needs. That's not how it works; *MOST* developers will cater to the needs of the *MAJORITY* of users, and that includes the dynamic hardware scenario (which has been the case for all of the XXI century, by the way). > So in this very specific case it can be considered "bloat" if you wish to > use that kind of words. > > My guess is that it is more useful on laptop than on a desktop box or an > industrial computer. > Of course not; desktop and servers ("industrial computers") need dynamic hardware (hot swappable storage, anyone?, disconnect the webcam after the Zoom meeting?) Just because you in particular don't find it useful doesn't mean it isn't: the truth is, dynamic hardware users surpass static hardware users, and it has been the case for several decades now. > As a side note, from what I understand, udev today is mostly > about usb-devices because that is where the dynamic hardware comes > from today (at least when we are not talking about hotplugging cpus, memo= ry > cards, io-cards and such (but that is more of a enterprise problem than a > small system problem. > It's not only USB; it's Bluetooth, Thunderbolt, eSATA and eSATAp, etc. The computing world is dominated by dynamic hardware; it has been so for at least the last two decades. > Serial ports are darn easy to implement in hardware and softwere. > Yes: but the software that *uses* mice doesn't care *ONLY* about serial port mice. They care about USB mice (which is the majority) and Bluetooth mice (which has the second place). Right now, serial mice have to be a distant third place, if at all. So the developers of software that deals with mice don't need to worry *ONLY* about your case; they need to worry about the general case. Which includes USB and Bluetooth (and whatever they invent in the future). E.g. if I have a program connecting to a device using a serial > and it is disconnected, I can just reconnect it and nothing > special happens, noting to be done in software except logging. > The same device via usb, the dis-/reconnect will close the > port and make it vanish forcing med to find out find out where the > new /dev file is and reopen and reinitialize it. > That is what udev+libinput solves, *exactly*. You answered yourself why it is needed *IN GENERAL* (not in your particular case). What you say about complexity etc., is true; but most developers care about servicing the *majority* of users (in this case, USB and Bluetooth users included), so if you want to use their software, that means accepting udev. If you don't like it, you need to stop using their software and either write your own or find someone else who does it (again, check the alternatives). In any case, complaining is useless: most sane developers always want to cover the majority of users. That's why udev is mandatory in most major and medium distros; in Gentoo it is used by default (BTW, they are preparing the deprecation of eudev in Gentoo[2]). Regards. [1] https://man7.org/linux/man-pages/man7/udev.7.html [2] https://archives.gentoo.org/gentoo-dev/message/dff4bf35636efef95f6d7926823b= 4e8d --=20 Dr. Canek Pel=C3=A1ez Vald=C3=A9s Profesor de Carrera Asociado C Departamento de Matem=C3=A1ticas Facultad de Ciencias Universidad Nacional Aut=C3=B3noma de M=C3=A9xico --0000000000000cba1705ca3f582b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 23, 2021 at 11:07 AM <karl@aspodata.se> wrote:
[...]
It is inconvenient that thoose two goes away.=C2=A0Regarding udev, it has n= ever supported serial mice, so it doesn't help=C2=A0me.

What are you talking about? Udev doesn't "sup= port" any hardware; as the manual page states[1], it: "supplies t= he system software with device events, manages permissions of device nodes = and may create additional symlinks in the /dev/ directory, or renames netwo= rk interfaces".

If the kernel supports the ha= rdware, udev will supply the corresponding event, so udev will generate the= corresponding event for serial mice also (probably close to boot time).
=C2=A0
[...]
Poeple write whatever software they want to or are paid to do.= =C2=A0It is my call if I want to use that software or not.
=

Well, yeah; but if you want to use software X, and X de= pends=C2=A0on Y, then you either use software Y or don't use software X= . The dependency chain can and will grow depending on several=C2=A0factors,= and it's the situation here if I'm not=C2=A0mistaken: you want to = keep using keyboard and mice, those depend on libinput, and libinput depend= s on udev.

There are alternatives, of course; some= members have posted several working ones; but the fact is that either you = accept the dependencies dictated by the software you want to use, or you ne= ed an alternative that *someone* has to write/debug/maintain, etc. You said= : "[u]dev should be an optional daemon, utilized when the local admini= strator decides to do so," and that is simply not true: if a software = you use decides to depend on udev, then you either use udev, or need to cha= nge to a different software.
=C2=A0
As I wrote before, udev does not handle serial mice, so udev does not solve= anything for me nor does it help me in any way to run my systems.

You are saying it wrong, you mean to say:=C2=A0= "to handle serial mice, I don't need udev". And that is 100%= completely true; you can keep a static /dev, don't use udev and create= the device nodes by hand. But serial mice work=C2=A0great under udev also.=

The thing is, the *GREAT* majority of users need = support for dynamic hardware, so the developers of most of the software in = Linux solve the general problem: dynamic hardware (which includes static ha= rdware also). So they do that, and you complain about daemons that are need= ed for other people other than you.

But you didn&#= 39;t write the software that depends on udev; someone else (worrying about = the general problem) did. So either you write your own version, or find som= eone else who does (again, check the alternatives).
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Udev is just something pushed on me for no gain except possible to=C2=A0sat= isfy some dependancy touted to be beneficial.

<= div>For no gain *TO YOU*. You want software that someone else wrote to cate= r to *ONLY* your needs. That's not how it works; *MOST* developers will= cater to the needs of the *MAJORITY* of users, and that includes the dynam= ic hardware scenario (which has been the case for all of the XXI century, b= y the way).
=C2=A0
So in this very=C2=A0specific case it can be considered "bl= oat" if you wish to use that=C2=A0kind of words.

My guess is that it is more useful on laptop than on a desktop box=C2=A0or = an industrial computer.

Of course not; = desktop and servers ("industrial computers") need dynamic hardwar= e (hot swappable storage, anyone?, disconnect the webcam after the Zoom mee= ting?) Just because you in particular don't find it useful doesn't = mean it isn't: the truth is, dynamic hardware users surpass static hard= ware users, and it has been the case for several decades now.
=C2= =A0
As a side note, from what I understand, udev today is mostly about=C2=A0usb= -devices because that is where the dynamic hardware comes from=C2=A0today (= at least when we are not talking about hotplugging cpus,=C2=A0memory cards,= io-cards and such (but that is more of a enterprise=C2=A0problem than a sm= all system problem.

It's not only U= SB; it's Bluetooth, Thunderbolt, eSATA and eSATAp, etc. The computing w= orld is dominated by dynamic hardware; it has been so for at least the last= two decades.
=C2=A0
Serial ports are darn easy to implement in hardware and=C2=A0softwere.
<= /blockquote>

Yes: but the software that *uses* mice does= n't care *ONLY* about serial port mice. They care about USB mice (which= is the majority) and Bluetooth mice (which has the second place). Right no= w, serial mice have to be a distant third place, if at all.

<= /div>
So the developers of software that deals with mice don't need= to worry *ONLY* about your case; they need to worry about the general case= . Which includes USB and Bluetooth (and whatever they invent in the future)= .

E.g. if I have a program connecting to a device using a serial
and it is disconnected, I can just reconnect it and nothing
special happens, noting to be done in software except logging.
=C2=A0The same device via usb, the dis-/reconnect will close the
port and make it vanish forcing med to find out find out where the
new /dev file is and reopen and reinitialize it.

<= /div>
That is what udev+libinput solves, *exactly*. You answered yourse= lf why it is needed *IN GENERAL* (not in your particular case).
<= br>
What you say about complexity etc., is true; but most develop= ers care about servicing the *majority* of users (in this case, USB and Blu= etooth users included), so if you want to use their software, that means ac= cepting udev. If you don't like it, you need to stop using their softwa= re and either write your own or find someone else who does it (again, check= the alternatives).

In any case, complaining is us= eless: most sane developers always want to cover the majority of users. Tha= t's why udev is mandatory in most major and medium distros; in Gentoo i= t is=C2=A0used by default (BTW, they are preparing the deprecation of eudev= in Gentoo[2]).

Regards.

--
Dr. Canek Pel=C3=A1ez Vald=C3=A9s
Profesor de Carr= era Asociado C
Departamento de Matem=C3=A1ticas
Facultad de Ciencias<= br>Universidad Nacional Aut=C3=B3noma de M=C3=A9xico
--0000000000000cba1705ca3f582b--