On 4/26/21 3:58 PM, Alberto Bursi wrote:
On 26/04/21 16:01, Daniel Golle wrote:
On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
... I know you won't like this. But in the end, I guess D-Bus, glib2
and in the end all of MM dependencies will have to be incorporated in
the core.
A stac, of big big software, I know. But supporting 4G/5G in the end
will required that.
ModemManager is not the only way to use 4G/5G modems. You can use
umbim or uqmi for most tasks.
In my experience their ability to handle device-specific bugs or "perks"
is limited, unless your modem is 100% perfect and never crashes ever and
can actually handle the autoreconnect on its own, you will end up in
situations where you need to just set up a script that pings Google and
reboots the router if network fails.
They also don's support a lot of new LTE features like band lock, band
aggregation and more, they are way too simple. I have bought a consumer
modem/router that is like 3 times faster while using the same type of
CAT6 modem due to band aggregation and the reconnect sequence if the
connection drops is very fast because I have set the only 2 LTE bands it
can use.
MM is so much better than that. But my main issue with MM is that both
maintainers (package and upstream MM maintainers) have not found a way
to integrate it well enough with OpenWrt's internals so that when the
modem disconnects there is nothing that notices this issue and nothing
that reacts to it. So I had to cobble together a script to do this
missing link, but it's far from a decent solution. (see the issue thread
I opened about this)
Hence why I eventually bought an actual self-contained modem with web
interface and all, it's just so much better speed and is less painful to
use.
-Alberto
Both projects are straight forward, well
documented code, easy to extend in case you miss anything.
Depending on half of the Freedesktop universe in order to initialize
a network interface or receive an SMS in a very complicated way doesn't
feel justified to me.
On Mon, 26 Apr 2021, Bjørn Mork wrote:
Date: Mon, 26 Apr 2021 07:51:51
From: Bjørn Mork <bj...@mork.no>
To: Etienne Champetier <champetier.etie...@gmail.com>
Cc: Rosen Penev <ros...@gmail.com>,
OpenWrt Development List <openwrt-devel@lists.openwrt.org>
Subject: Re: Brokenness of the OpenWrt "packages" repo
Etienne Champetier <champetier.etie...@gmail.com> writes:
Are you trying at the same time to complain about not run-tested
updates and possibly having packages not up to date ?
No. The package was fine before the version was changed. In fact, it
was in much better shape before it was changed to a development version
by the very same non-maintainer.
If you don't care enough to even install the package, then please don't
touch the package.
I would personally mark it as broken or remove it instead of making it
work again, but it means removing some other packages.
I'd be all for that, if you apply that rule to all the unmaintained
packages in the repo. It's a much better solution than having the repo
full of arbitrary untested changes to unmaintained packages.
Wrt dbus I'm pretty sure it would provoke an adoption. There are
multiple packages depending on it, and as the immediate reports tell
you: This particualr umaintained package is in active use.
Bjørn
I feel this with a lighter tone, but I philosophically agree with Bjorn.
Here is an example of enforcement concerns. I am an active maintainer. I
have a day job and all, but I do get to at least commenting on PR once a
week. Here committer and merger where separate individuals. The
maintainer wasn't contacted. Neither participant is even a user of
Unbound, self-stated in PR, or tested the work. I realize the change was
trivial, and that is not my point. An automated test-hook could have
checked if the maintainer commented or the maintainer was AWOL before
marking the PR ready. Trivial or complex, maintainers need to be in the
loop or we lose continuity in quality and we discourage their "feeling
of ownership" when we bypass them.
SEE: https://github.com/openwrt/packages/pull/15511
- Eric
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
