@BKeyport @KristjanESPERANTO Turns out I owe you some thanks, if only because you got me thinking and questioning my assumptions.

I had previously assumed the anchor process of an X server needed to be an X application, but that turned out to be not the case, so the whole blackpixel executable could be removed entirely, eliminating a major contributor to the script size and a maintenance headache for me.

It does make the script even more obscure and alien though. That’s easily the strangest X config I’ve ever created.

Code is updated.

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

@KristjanESPERANTO What are you talking about, the listing of those config files is right there in the comments, and the purpose of that binary is quite obvious if you have a basic knowledge of Linux and Xorg. Also the file name the binary gets stored under is a dead giveaway. Don’t expect me to spoon-feed you obvious information.

Actually, there’s two more things I’d like to point out, now that I think about it.

First, I specifically put in the readme that the script is written for people with a basic understanding of Linux and X. That’s not saying it can’t be used by people who don’t have that, but everything we’ve been discussing so far boils down to “It’s obscure to people who lack a basic understanding of Linux and X”. Well, yes it is, and I won’t apologize for that.

Second, what sparked the whole controversy was originally the presence of the blackpixel executable in the script. Funny thing is, nobody even asked me about the purpose or the source code of the blackpixel executable when it was still in there. I would have gladly shown it off and explained it, but instead of asking, all anyone ever did was basically criticize me for it being there because they didn’t understand it just by looking at it.

Everybody should remember that IT isn’t easy. If it is easy, that’s because people who have the skills and knowledge put in the work to make it easy for those who don’t. I’m very grateful to all the great people who put in the hard work so I can have Linux, X, MagicMirror or a ridiculously cheap versatile computer like the Raspberry Pi. I just wish the world would reciprocate just this once.

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

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

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

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

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

@sdetweil I most certainly can and will. Where would you like it to live? I’d suggest the README in the repo.

In a nutshell, if you want a reduced footprint in cpu, ram and memory usage and/or want your magic mirror system to be more of an embedded-appliance style rather than a general use computer running an application, then my script is right for you.

By the way, I just thought I should probably add the option to enable automatic system updates via apt as a logical extension of that concept.

What do you think? Should I include it now or when I get around to re-creating automatic updates for MagicMirror and its modules?

@mumblebaj Thank you for your kind words. You can’t imagine how much I needed that right now - for at least one person to actually say “thank you”.

On the subject of the “standard user’s” reaction, I guess this is another occasion to break out my favorite corollary to a corollary to the famous statement of Arthur C. Clarke: “Everything looks like magic to those who don’t understand it”. Whether you condemn it as evil magic or marvel at the wonderful magic however depends entirely on your own personal disposition.

Personally I tend towards the opinion that these days users are totally used to making use of tools they don’t understand but know how to work. If you for instance went into a dark room and asked “How’s the light work?” you would much more likely get pointed to the light switch than an explanation of the function of the power grid. There would certainly be a few die-hard sceptics who refuse to use it on the grounds of “I don’t understand it, hell no” - to then complain about it on the forums they don’t understand either using their smartphone they understand even less, the irony - but most users would probably not look at it at all, or if they did, just shrug and run it anyways.

That however goes for end users, it certainly does not go for reviewers. Someone should definitely understand the code, and I would never hold it against anyone who doesn’t if they decided to wait until those who understand it better give their blessing.

What I will hold against people though is the attitude to condemn a thing merely because they don’t understand it and can’t be bothered to learn. That sort of thing gets right up my nose.

@karsten13 Sorry, that didn’t come out right. I meant the first paragraph for you and the rest for everyone. Should have made that clearer, my apologies.

Actually, there’s two more things I’d like to point out, now that I think about it.

First, I specifically put in the readme that the script is written for people with a basic understanding of Linux and X. That’s not saying it can’t be used by people who don’t have that, but everything we’ve been discussing so far boils down to “It’s obscure to people who lack a basic understanding of Linux and X”. Well, yes it is, and I won’t apologize for that.

Second, what sparked the whole controversy was originally the presence of the blackpixel executable in the script. Funny thing is, nobody even asked me about the purpose or the source code of the blackpixel executable when it was still in there. I would have gladly shown it off and explained it, but instead of asking, all anyone ever did was basically criticize me for it being there because they didn’t understand it just by looking at it.

Everybody should remember that IT isn’t easy. If it is easy, that’s because people who have the skills and knowledge put in the work to make it easy for those who don’t. I’m very grateful to all the great people who put in the hard work so I can have Linux, X, MagicMirror or a ridiculously cheap versatile computer like the Raspberry Pi. I just wish the world would reciprocate just this once.

@karsten13 I tried here-docs initially, and it caused all kinds of problems, from missing newlines to empty files, although at least some of that probably was due to me writing the string to variables instead of directly to files and causing problems with the shell’s variable space.

Using base64 may not strictly necessary, but it’s robust and portable, and not in the least harmful. It’s also relatively easy to fact-check if you have a basic working knowledge of Linux. If you don’t, well then any software is a total black box to you and you just have to trust the person providing it. See the recent kerfuffle around obscured malicious code in ssh. I wouldn’t have been able to find it.

The way it works is, people who have the knowing fact-check and give the thumbs-up for those who don’t.

I’d also like to point out that

a) the contents of the files are listed as comments
b) if you were looking at a binary instead of a script, you’d be no wiser if you had it in binary rather than base64,
c) if I had made the pivot to makeself instead of encoding the files in b64, you’d see even less of the script before you executed it
d) most of the software you have on your system right now was provided in binary form, and
e) unless you are a closet uber-geek, you probably wouldn’t understand half of it if you had the source code, and
f) even if you are, a single human lifetime wouldn’t be nearly enough to fact-check the software on even a basic Linux install.

I feel you are blowing the fact that I’m using base64 to encode those files WAY out of proportion. As it is, it’s working as intended, and I’m not going running that gauntlet of trying to get here-docs to work again without better reason than people getting queasy over seeing base64 strings in a file.

If you want to modify it, you’re welcome to do so and provide a well-tested pull request. If on the other hand you wish to reject my work on a technicality like that, that’s a shame, but it hurts the community WAY more than it hurts me.