~alpine/devel

10 4

[alpine-devel] smdev

Cág
Details
Message ID
<c0880cc02818948a5b400087209c80d0@riseup.net>
Sender timestamp
1467387412
DKIM signature
missing
Download raw message
Hi there,

I was politely asked to report it to here, so there it is.

On my systemd-less experimental Debian installation I got rid of udev
(almost completely, some programmes still require libudev1) to use 
smdev.
It works and I think tis stable enough. Hotplugging works with USB
(haven't tried with PCI though, it's a laptop!), I can even mount 
without root
using udevil like it was with udev. I heard Alpine is going to adopt 
some of
the suckless software and smdev is one of them.

The fact is though, you can't just "make install" and run it; for me
it required working with xorg.conf and rc.local; also there is a need 
for writing
an init script (I use sysvinit right now but have plans for sinit). 
Anyway,
these are details.

If you have any questions and/or experiments I could do with it, please 
ask.
I'm subscribed to the lists (alpine-user also).

Cheers and have a good weekend,
Cág


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jakub Jirutka
Details
Message ID
<AA21151C-A9BB-4FD9-9199-0F57434B8047@jirutka.cz>
In-Reply-To
<c0880cc02818948a5b400087209c80d0@riseup.net> (view parent)
Sender timestamp
1467459936
DKIM signature
missing
Download raw message
Hi Cág,

I wonder, what are the differences between mdev and smdev? What are the benefits of smdev for end users?

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.

Jakub

On 1 July 2016 17:36:52 CEST, "Cág" <caoc@riseup.net> wrote:
>Hi there,
>
>I was politely asked to report it to here, so there it is.
>
>On my systemd-less experimental Debian installation I got rid of udev
>(almost completely, some programmes still require libudev1) to use 
>smdev.
>It works and I think tis stable enough. Hotplugging works with USB
>(haven't tried with PCI though, it's a laptop!), I can even mount 
>without root
>using udevil like it was with udev. I heard Alpine is going to adopt 
>some of
>the suckless software and smdev is one of them.
>
>The fact is though, you can't just "make install" and run it; for me
>it required working with xorg.conf and rc.local; also there is a need 
>for writing
>an init script (I use sysvinit right now but have plans for sinit). 
>Anyway,
>these are details.
>
>If you have any questions and/or experiments I could do with it, please
>
>ask.
>I'm subscribed to the lists (alpine-user also).
>
>Cheers and have a good weekend,
>Cág
>
>
>---
>Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
>Help:         alpine-devel+help@lists.alpinelinux.org
>---
Alba Pompeo
Details
Message ID
<CAJDAfTD9+q3fbYMJp05sLLhHVSdKCzNU-diEtjCyzKXUED4iiA@mail.gmail.com>
In-Reply-To
<174bbc5214754cfa31d9156ec1e78660@riseup.net> (view parent)
Sender timestamp
1467553869
DKIM signature
missing
Download raw message
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@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@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Alba Pompeo
Details
Message ID
<CAJDAfTDJbu7GiQxcw0a-o9_3nWMJk_woW51mqBzmppp1YyQFew@mail.gmail.com>
In-Reply-To
<B4C204D8-C445-4347-9DDA-FFA89CB8A287@jirutka.cz> (view parent)
Sender timestamp
1467556607
DKIM signature
missing
Download raw message
> 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@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@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@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@lists.alpinelinux.org
>>> Help:         alpine-devel+help@lists.alpinelinux.org
>>> ---
>>>
>>
>>
>> ---
>> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
>> Help:         alpine-devel+help@lists.alpinelinux.org
>> ---
>>
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jakub Jirutka
Details
Message ID
<B4C204D8-C445-4347-9DDA-FFA89CB8A287@jirutka.cz>
In-Reply-To
<CAJDAfTD9+q3fbYMJp05sLLhHVSdKCzNU-diEtjCyzKXUED4iiA@mail.gmail.com> (view parent)
Sender timestamp
1467555221
DKIM signature
missing
Download raw message
>> …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@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@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@lists.alpinelinux.org
>> Help:         alpine-devel+help@lists.alpinelinux.org
>> ---
>> 
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 
Cág
Details
Message ID
<174bbc5214754cfa31d9156ec1e78660@riseup.net>
In-Reply-To
<AA21151C-A9BB-4FD9-9199-0F57434B8047@jirutka.cz> (view parent)
Sender timestamp
1467552901
DKIM signature
missing
Download raw message
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@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Shiz
Details
Message ID
<778EACCE-B12B-4643-B7AC-B8992053EA95@shiz.me>
In-Reply-To
<B4C204D8-C445-4347-9DDA-FFA89CB8A287@jirutka.cz> (view parent)
Sender timestamp
1467556867
DKIM signature
missing
Download raw message
> On 03 Jul 2016, at 16:13, Jakub Jirutka <jakub@jirutka.cz> wrote:
> 
>> 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 agree with this. I’m hardly an Alpine power user and had to change mdev.conf
a few times as well. User recompilation of package manager-provided binaries,
which also requires the ton of dependencies a compiler brings in and any
dependencies smdev itself has, on a binary distro is simply a not done for me.

- Shiz

---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Shiz
Details
Message ID
<9AD95974-D6F1-40B1-B3CA-8AA46FE9512B@shiz.me>
In-Reply-To
<20160703145233.5845075.93120.404@riseup.net> (view parent)
Sender timestamp
1467558290
DKIM signature
missing
Download raw message
> On 03 Jul 2016, at 16:52, Cág <caoc@riseup.net> wrote:
> 
>> 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...
> 
> The average user also doesn't use Alpine, isn't it for "power users"?‎ [0]

That should be no reason to make things annoying on purpose.

> I also don't think that smdev should be provided by the package manager.
> (just like the base system)
> Why would you remove it, and if you need, go to /usr/src and make uninstall.
> Luckily, suckless has always provided uninstall rule for all its software.

I frequently keep a fully static /dev on my servers, in which I don’t need
a device manager at all. So yes, I’d like to remove it.

I don’t think a distro with a package manager is right for you judging from
this comment. Maybe something like BSD’s ports is more up your ally?

- Shiz

---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jakub Jirutka
Details
Message ID
<DB5F686E-4915-4A0E-BA83-9078EDEC5C5D@jirutka.cz>
In-Reply-To
<9AD95974-D6F1-40B1-B3CA-8AA46FE9512B@shiz.me> (view parent)
Sender timestamp
1467558752
DKIM signature
missing
Download raw message
>> I was talking about foreseeable future, like sbase/ubase were already adopted.

Well, but you didn’t write it, this is quite important circumstance. ;)

>> The average user also doesn't use Alpine, isn't it for "power users"?‎ [0]

(Un)fortunately (polarity depends on PoV) this isn’t true anymore, since Docker started using Alpine for their images. Docker users usually aren’t “power users.” They often don’t even understand what is libc and that Oracle JDK, that is distributed just as a strange BLOB compiled against glibc, really can’t work on Alpine (I’m not kidding, this is really very common issue).

>> All I can say is to compare the code. I’ve never used mdev before and am not aware of all its features.

Okay, so we don’t even know what will not work on smdev, because there isn’t even proper documentation… I still see more drawbacks than advantages.

>> I also don’t think that smdev should be provided by the package manager. (just like the base system)

The base system actually *is* provided by package manager. Everything in Alpine is provided as a package (aport). You can easily install fully functional base Alpine system in chroot just using `apk.static install alpine-base` in ~2 seconds (see [1], [2], or [3] for example; apk.static is a statically linked binary). BTW, this is really awesome.

>> Why would you remove it, and if you need, go to /usr/src and make uninstall.

Once again, Alpine is not Linux From Scratch…

Jakub

[1]: https://github.com/jirutka/aports/blob/edge/.travis/install-alpine
[2]: https://github.com/alpinelinux/aports/blob/master/.travis/install-alpine
[3]: https://github.com/lxc/lxc/blob/master/templates/lxc-alpine.in

On 3. Jul 2016, at 17:04, Shiz <hi@shiz.me> wrote:

> 
>> On 03 Jul 2016, at 16:52, Cág <caoc@riseup.net> wrote:
>> 
>>> 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...
>> 
>> The average user also doesn't use Alpine, isn't it for "power users"?‎ [0]
> 
> That should be no reason to make things annoying on purpose.
> 
>> I also don't think that smdev should be provided by the package manager.
>> (just like the base system)
>> Why would you remove it, and if you need, go to /usr/src and make uninstall.
>> Luckily, suckless has always provided uninstall rule for all its software.
> 
> I frequently keep a fully static /dev on my servers, in which I don’t need
> a device manager at all. So yes, I’d like to remove it.
> 
> I don’t think a distro with a package manager is right for you judging from
> this comment. Maybe something like BSD’s ports is more up your ally?
> 
> - Shiz
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 
Cág
Details
Message ID
<20160703145233.5845075.93120.404@riseup.net>
In-Reply-To
<CAJDAfTDJbu7GiQxcw0a-o9_3nWMJk_woW51mqBzmppp1YyQFew@mail.gmail.com> (view parent)
Sender timestamp
1467557553
DKIM signature
missing
Download raw message
> 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).

I was just going to write everything you did, but you were first :)

Yes, certainly, there is absolutely no need to have multiple udevs in one system,
I was talking about foreseeable future, like sbase/ubase were already
adopted.

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

Mmm, BSD :3

> 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...

The average user also doesn't use Alpine, isn't it for "power users"?‎ [0]

> What features does it miss exactly? I can’t find in on the provided page or inside the smdev’s repository.

All I can say is to compare the code. I've never used mdev before and am not aware of all its
features.

I also don't think that smdev should be provided by the package manager.
(just like the base system)
Why would you remove it, and if you need, go to /usr/src and make uninstall.
Luckily, suckless has always provided uninstall rule for all its software.

Cág

[0]: http://alpinelinux.org/about/

PS Lads, there is no need to send me a copy, I'm subscribed.



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Cág
Details
Message ID
<10265a62ebbc034becdf8e87cb4cb9f0@riseup.net>
In-Reply-To
<9AD95974-D6F1-40B1-B3CA-8AA46FE9512B@shiz.me> (view parent)
Sender timestamp
1467725460
DKIM signature
missing
Download raw message
Shiz wrote:

> I frequently keep a fully static /dev on my servers, in which I don’t 
> need
> a device manager at all. So yes, I’d like to remove it.

Okay, so in this case yes, it is better to be provided by a package 
manager.

> I don’t think a distro with a package manager is right for you judging 
> from
> this comment. Maybe something like BSD’s ports is more up your ally?

I had one particular problem with source-based distributions: crappy 
software
I depend on. When software like Firefox, gcc, WebKit and LibreOffice 
exist
we can't give up our binary-based package managers. That's why I think 
that
they should be provided as binaries, while something small and useful
(just like suckless software) could be present in a source form, in my 
opinion.
Now in Debian I like things like dpkg and debconf, but BSD is often
is on my another partition. And yeah, I wrote it previously, I love 
pkgsrc.

Peace,
Cág


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---