Mail archive
alpine-devel

Re: [alpine-devel] smdev

From: Alba Pompeo <albapompeo_at_gmail.com>
Date: Sun, 3 Jul 2016 11:36:47 -0300

> Busybox is a base of the Alpine’s userland, so we have it anyway.

ncopa said he would welcome sbase [0] and ubase [1] once they are
stable, because of its advantages (such as correct handling of UTF-8).
For example, try the following on Busybox and see how it fails. echo
"õã" | tr -d "õ". On sbase it works.

> (e)udev’s monster complexity is needed maybe just for desktops if at all (not sure, I don’t use Linux on desktop).

That's why Alpine hasn't adopted smdev yet, because there are problems
to be fixed (like hotplugging, bluetooth, etc). I'm not sure the exact
issues.

> Yes, but just until you need to change something…
> Maybe I’m biased here because I’ve already needed to modify the Alpine’s mdev.conf several times.

Most users rarely if ever need to change something in such low-level
system programs.

> This means to recompile the smdev binary

Will people really need to recompile it? Alpine should provide a
default config.h that works for 99.9% of users.

> We need BusyBox anyway

Not forever.

> smdev package would not replace mdev for all use cases

What's missing on smdev? Developers said in the past they want to help
with anything Alpine needs.

> imagine how you tell average user to recompile smdev himself/herself instead of just modify simple config file

The average user doesn't know what's mdev/smdev/etc and won't need to
change the Alpine sane defaults. That's how I see it...


[0] http://git.suckless.org/sbase
[1] http://git.suckless.org/ubase

On Sun, Jul 3, 2016 at 11:13 AM, Jakub Jirutka <jakub_at_jirutka.cz> wrote:
>>> …it doesn’t have all its features.
>
> What features does it miss exactly? I can’t find in on the provided page or inside the smdev’s repository.
>
>>> The benefits are: you don’t need BusyBox for it…
>
> Busybox is a base of the Alpine’s userland, so we have it anyway.
>
>>> By the way, I don’t know why Alpine doesn't use mdev, to me it seems to be the most appropriate variant…
>
> Alpine does use mdev by default (at least in alpine-virt variant, not sure about full-fledged).
>
> I personally use mdev on all my servers, VMs and bear metal, Alpine and Gentoo. I believe that mdev is fully sufficient for most of the server and embedded use cases. (e)udev’s monster complexity is needed maybe just for desktops if at all (not sure, I don’t use Linux on desktop).
>
>> I agree with Cág about the absence of textual configuration files. It’s an advantage because it keeps complexity down.
>
> Yes, but just until you need to change something…
>
>> Almost no user will change their smdev config options…
>
> Maybe I’m biased here because I’ve already needed to modify the Alpine’s mdev.conf several times.
>
>> But if the user really wants to, I see no problem with config.def.h
>
> This means to recompile the smdev binary (note: you need gcc). Then you can install it directly from the sources and it’ll be the same, i.e. you will not benefit from aport. Overwriting binaries managed by apk is really not a good practice IMO.
>
>
> I really don’t see any *practical* benefit for Alpine. We need BusyBox anyway, so why to replace BusyBox’s mdev with smdev that is just less flexible (no config file)? Also it will mean supporting three instead of two (mdev, eudev) udev packages, because smdev package would not replace mdev for all use cases (imagine how you tell average user to recompile smdev himself/herself instead of just modify simple config file; Alpine is not LFS or Gentoo).
>
> Jakub
>
>
> On 3. Jul 2016, at 15:51, Alba Pompeo <albapompeo_at_gmail.com> wrote:
>
>> I agree with Cág about the absence of textual configuration files.
>> It's an advantage because it keeps complexity down.
>> Almost no user will change their smdev config options, that's
>> something Alpine will have sane defaults for.
>> But if the user really wants to, I see no problem with config.def.h
>> [0]. /usr/src to the rescue.
>> I remember smdev developers talked about wanting to integrate it on
>> Alpine in the past, here on the mailing list.
>> I think ncopa wants it too, but had problems with hotplugging (?) I think.
>> But it looks like Cág has solved that problem. Let's wait and see if
>> ncopa thinks now smdev is ready (for 3.5 alpine release?).
>>
>> Ciao!
>>
>> [0] http://git.suckless.org/smdev/tree/config.def.h
>>
>> On Sun, Jul 3, 2016 at 10:35 AM, Cág <caoc_at_riseup.net> wrote:
>>> Jakub Jirutka wrote:
>>>
>>>> I wonder, what are the differences between mdev and smdev? What are
>>>> the benefits of smdev for end users?
>>>
>>>
>>> smdev is IIRC a fork of mdev (or maybe was, probably it was rewritten)
>>> that is compatible with it [0], though it doesn't have all its features.
>>> The benefits are: you don't need BusyBox for it and it is smaller
>>> (almost thrice as short in terms of LOC). It does what it says -
>>> manages device nodes, and does it well.
>>>
>>>> I currently see one significant drawback - smdev (and all other
>>>> suckless projects) doesn't support textual configuration files. This
>>>> approach doesn't go well with binary distributions; users can't simply
>>>> change any settings. I understand the reasons behind using header
>>>> files for config, but the fact is that it's not very convenient for
>>>> users.
>>>
>>>
>>> For me, it's rather an advantage. Once configured you go with it. Actually
>>> I've never modified my udev rules, they always worked for me and with smdev
>>> I use
>>> the default config.h because it works just fine. Anyway, if users need to
>>> modify the rules, I'd put the source inside /usr/src and let them do it :)
>>>
>>> By the way, I don't know why Alpine doesn't use mdev, to me it seems to be
>>> the
>>> most appropriate variant (or does it? I heard it uses eudev. I currently
>>> have
>>> no chance to check it out).
>>>
>>> If ye need more info about smdev, please consult the link down below and the
>>> code.
>>> Also, write to dev at suckless dot org, since I am not an smdev developer.
>>>
>>> Sláinte,
>>> Cág
>>>
>>> [0]:http://core.suckless.org/smdev
>>>
>>>
>>>
>>> ---
>>> Unsubscribe: alpine-devel+unsubscribe_at_lists.alpinelinux.org
>>> Help: alpine-devel+help_at_lists.alpinelinux.org
>>> ---
>>>
>>
>>
>> ---
>> Unsubscribe: alpine-devel+unsubscribe_at_lists.alpinelinux.org
>> Help: alpine-devel+help_at_lists.alpinelinux.org
>> ---
>>
>


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Sun Jul 03 2016 - 11:36:47 GMT