Read the statement by Michael Teeuw here.
CALL FOR TESTERS: New install script
-
@drdeath we’ve had lots of successful appliances built so far without your approach.
and the user issues are mostly unrelated to the os or MagicMirror runtime.look and feel, consistency of error recovery
and module function/integration are the primary issues. power saving , new monitor hardware are the next most.and user skill is always a critical issue. we have a lot of new users that know nothing without a graphical desktop . cant find help, don’t know file commands, cd? redirects, copy, move, networking
and on and on.what can the user save by using your approach?
note that the older pis are going by the wayside with the os changes. pi4 and 5 class devices are the norm across sll the vendors
can they do without a fan?
functionally nothing else changesi am not in favor of automatic updates in this space, the amount of breaking changes are too high. we still have significant disruption of the existing user base on each release
some OS related (tools used for blanking the screen or video feeds dropped out or function limited), some deprecation limited (remove request and other libs no longer supported), new versions of electron taking new code with bugs not yet discovered which cause fatal errors for the user . new electron requires, new node version, which doesn’t run on this os… oops… but discovered too late
some MM related… the deprecated lib thing… we don’t want to carry dead baggage… oops authors didn’t know, we added checking for things to prevent crashes (good thing) which cause accidental side effects
position: “” used to work, now fails. -
@sdetweil Well if you put it this way, the less software you have installed on a system, the less likely it is going to break during an update. That could actually be a major selling point for doing it my way, because almost all of the tools I’m using have been around for at least 30 years and are going nowhere. Desktop environments have big breaking changes all the time (I’ve been there when they swapped out KDE3 for KDE4 in SuSE Linux over night, boy were people enraged) whereas the basic toolset I rely on has stood the test of time and is virtually unchanged save for the occasional bugfix since the mid 90s.
On the subject of how the users interact, I’ve said so here multiple times and I’ve also put it in the README that this script isn’t written with the wet-behind-the-ears noob at the forefront of the brain. That being said, it’s actually really hands-off and easy to use when you think about it. Download it, start it, answer a couple of questions, bam, you’ve got a working mirror. The major concern I have with the current script is actually that may be too easy to use, prompting people to treat their mirror like a maintenance-free washing machine and let the system rot.
-
@drdeath interesting, but there is no less software.
curl, git, node, MagicMirror and all its dependencies .
whatever window manager is noise, there is one
there are a few users like you that want to be near the bare minimum, i don’t think that’s the right place for 99% of our users. they are still exploring the possibilities.
-
@sdetweil I beg to differ, yes less software, because the whole thing is based on the lite image, not the full image, with all the packages not installed and daemons not running there’s actually a pretty significant reduction in installed software and services. Actually, I consider the possibility to work on the lite image a significant advantage of my script over other installation methods.
curl, git, node and MagicMirror are pretty much a given, since omitting any of these would pretty much defeat the purpose of the whole thing.
About “noise”, you lost me there. There is no package or binary called “noise” installed on my test system, and since I know pretty much all of the common mainstream window managers and quite a few obscure ones at the very least by name, “noise” would either have to be pretty new or a quite obscure one. If you doubt my admittedly boastful claim, kindly research “sithwm”, evilwm and xmonad. I’ve actually used all of those at some point, if only for evaluation purposes
The script in itself neither installs nor sets up any window manager at all. Xserver-xorg-common, which is pretty much the only suspect, doesn’t even contain or depend on any. I can definitely say it’s not a dependency or part of any of the packages my script installs. If you could tell me where you found that information, I might be able to shed some light on the issue.
PS: Found it. /usr/bin/noise is part of the openfoam package. My script definitely didn’t install that one.
-
@drdeath noise in this context meant insignificant to the problem at hand
-
@sdetweil Ok, got it.
But there really isn’t any wm in my setup. The purpose of a wm is to let the user manipulate windows, which he isn’t supposed to do, so having a window manager would actually be detrimental in this use case.
I originally had my blackpixel tool in there as a stand-in, but as I already explained over on discord, it turns out the process that really matters to keep the X server alive is actually the shell process running the init script, not any process that script starts.
-
@drdeath I am sorry that you found my comment offensive. That was not my intention at all. I think it’s a shame if there’s an atmosphere where you can’t express ideas or ask questions. Even if they are stupid, one should remain respectful. I think it’s good when people start new projects and try different approaches. So thanks for that!
Out of technical curiosity: Why are you using X? Wouldn’t it be possible with Wayland?
-
@KristjanESPERANTO Apology accepted, I didn’t really take offense, it really was mostly just irritation on my part at the flat-out dismissal of my work and everybody focusing on what I consider to be minor technicalities.
As for why I don’t use wayland (yet), X is what I know, and it does the business. I’m not saying I’ll never make the switch (I’m quite curious to learn more about it) but for now I’m happy to leave good enough alone. Frankly, I’m not sure switching to wayland wouldn’t break a things, since the ancient tools I rely on might not play well with the new kid on the block.
-
@KristjanESPERANTO since you got me curious, I looked into Wayland a bit.
So to answer your question again:
While Wayland is generally considered more efficient in general use scenarios, in a scenario where you want no window management, no window decoration and certainly no visual effects, that efficiency advantage would not only be negated, but turned into a disadvantage.
Also unlike X11, Wayland apparently cannot be started as a bare-metal service but always requires a compositor like Weston or Sway in the background which would actually not only result in a heavier premium in resource usage but would also require a more complex and error-prone setup.
Last but not least, wayland is far less use-case agnostic compared to X11. Like many modern software suites, it makes a lot of assumptions about how it is going to be used. Since many, if not most of these assumptions wouldn’t hold true in a scenario like the one we’re discussing here, using Wayland would carry a lot of the downsides of running MagicMirror on a full DE, in short, you’d be fighting against your framework instead of working with it.
In conclusion I can say from what I learned about Wayland so far, I definitely made the right choice with X11.
N.B. that are only the conclusions of a very brief look into Wayland on my part, so there may very well be ways to make it behave the way I want it to, but if they exist, they seem to be a lot less trivial and well-documented.
