Why not use a package manager?

[aberu]

It is painfully obvious that some of you just want to play video games, and don't care about the linux underpinnings at all with regard to best practices. That is unfortunate.

Best practices are not determined by whether or not a device is running Linux. Best practices are determined upon the context of the use-case scenario of the product/device/etc... Then a cost/benefit analysis should be applied to determine the best practices for that particular context.

Could you describe the most important best practice that isn't being followed, and how adding a package manager solves that problem?

[Solskogen]

It is painfully obvious that some of you just want to play video games, and don't care about the linux underpinnings at all with regard to best practices. That is unfortunate.

That's not true.
I'd like to know how the userland and kernel are compiled and packaged, but I didn't get a reply. I'd love to see a newer and more up to date kernel, and with a newer userland. If I knew how that process is done, I could help keep it updated.

[ARCADEAGES]

It is painfully obvious that some of you just want to play video games, and don't care about the linux underpinnings at all with regard to best practices. That is unfortunate.

That's not true.
I'd like to know how the userland and kernel are compiled and packaged, but I didn't get a reply. I'd love to see a newer and more up to date kernel, and with a newer userland. If I knew how that process is done, I could help keep it updated.

What will an updated linux kernel do for us gamers?

[Bas]

Not much for the MiSTer's primary use case. A properly maintained OS keeps your appliance from becoming a potential springboard for attackers who are intent on abusing your home network. Of course the SSH root shell with a fixed default password that simply keeps reverting is a bigger bullseye on MiSTer's back, but running proper maintenance should be a priority for the owner of any networked device. If nothing else, it's good citizenship and the decent thing to do on the internet we all share.

[hostile]

Not much for the MiSTer's primary use case. A properly maintained OS keeps your appliance from becoming a potential springboard for attackers who are intent on abusing your home network. Of course the SSH root shell with a fixed default password that simply keeps reverting is a bigger bullseye on MiSTer's back, but running proper maintenance should be a priority for the owner of any networked device. If nothing else, it's good citizenship and the decent thing to do on the internet we all share.

@solskogen you are the minority, I appreciate your desire to get to the linux compilation bits. You will quickly find GPL "open source", isn't done properly, and some folks here on the dev team refuse to let the buildroot from their clutches.

Simple examples from the project creator "There is no benefits to upgrade the kernel, as MiSTer is not a Linux computer."
https://www.atari-forum.com/viewtopic.p ... df#p399952

"There is no package manager as MiSTer is not a computer and doesn't expect any servicing from user."
https://www.atari-forum.com/viewtopic.p ... df#p399973

This mentality will NOT change, and is propagated on to some end users with less dev / linux experience.

"What will an updated linux kernel do for us gamers?" says it all IMHO.
viewtopic.php?p=23131#p23131

[hostile]

I'm gonna guess none of the folks that use Bluetooth Keyboards & keep MiSTer connected to their home LAN care that CVE-2020-12351 is remotely exploitable on kernel 4.19 over the air. In essence making MiSTer a backdoor into their home LAN that someone outside their home can use to compromise their network.

https://security-tracker.debian.org/tra ... 2020-12351
https://security-tracker.debian.org/tracker/DSA-4774-1 (fixed version 4.19.152-1)

/root# uname -a
Linux MiSTer 4.19.0-socfpga-r1 #1 SMP Mon Mar 15 01:16:44 CST 2021 armv7l GNU/Linux

What benefit would fixing BleedingTooth Bluez exploits do for gamers that use bluetooth keyboards?
https://access.redhat.com/security/vuln ... edingTooth

We get it, no one cares. It is just unfortunate as I said before. The excuses on what you THINK makes a best practice need not apply.

Linux Bluetooth Zero-Click Remote Code Execution over Bluetooth on your MiSTer is certainly nothing to worry about!
https://www.youtube.com/watch?v=qPYrLRausSw
https://www.exploit-db.com/exploits/49754

[RascalUK]

Do they not have to be within BT range for that? As in, pretty much sat next to me?

I know what you are saying, and I don't disagree as such, but nobody is hacking into my home network via BT and my Mister in the real world.

[hostile]

Bluetooth has been proven exploitable from miles away with amplified gear, and an antenna.
https://www.npr.org/templates/story/sto ... Id=4599106

So actually yes. I know a few mates in the UK if you want me to have one stop by and test with you how far away you could be easily exploited.

[rhester72]

If someone implicitly owns your entire infrastructure because they compromise a single weak device, you probably shouldn't own any hobby or IoT devices. Put it on a DMZ network and done. Seriously, we're talking about a piece of lab kit intended for student research in a school setting. It's never going to be a GP compute device (or managed as one), no matter how much that may gall anyone.

[hostile]

I'm beating a dead horse at this point, many of you clearly have no background in embedded devices, security, or linux, never mind threat modeling.
"NASA hacked because of unauthorized Raspberry Pi connected to its network"
https://www.zdnet.com/article/nasa-hack ... s-network/

These excuses and attempts to reason literally only support my original statement. Please... go on.

[bazza_12]

I'm gonna guess none of the folks that use Bluetooth Keyboards & keep MiSTer connected to their home LAN care that CVE-2020-12351 is remotely exploitable on kernel 4.19 over the air. In essence making MiSTer a backdoor into their home LAN that someone outside their home can use to compromise their network.

Personally I don't use bluetooth anything, I literally only plug the net in to the mister to do an update, the rest of the time it isn't online or linked to any network. That's just me..

[rhester72]

I'm beating a dead horse at this point, many of you clearly have no background in embedded devices, security, or linux, never mind threat modeling.
"NASA hacked because of unauthorized Raspberry Pi connected to its network"
https://www.zdnet.com/article/nasa-hack ... s-network/

These excuses and attempts to reason literally only support my original statement. Please... go on.

Yes...you are.

You're trying to get a home-built go-kart to pass a NHTSB test. It'd ridiculous on the very face of it.

Please return your DE-10 Nano. You are not the target market and do not understand the product. We'll all be happier.

[hostile]

"Please return your DE-10 Nano. You are not the target market and do not understand the product" this is the expected behavior.
"trying to get a home-built go-kart to pass a NHTSB test" over exaggeration.
"We'll all be happier" followed by attempts to get bandwagon shaming.

Please sir, explain the "target market" for both DE-10 Nano, and MiSTer. I'll sit and wait.

[jca]

hostile is becoming more hostile by the day. I don't think it will make you many friends. May be a little more diplomacy would.

[hostile]

I appreciate the hyperbole @jca, on the face of it suggesting those of us that perhaps want a package manager should use a little more diplomacy is funny. "Please return your DE-10 Nano. You are not the target market and do not understand the product" was of course extremely diplomatic.

I do wonder how real "angry" gets support, but pretend hostile doesn't. viewtopic.php?t=525

This place is very confusing. You are probably right. I'm gonna guess the next suggestion is I go buy a RasPi. Thanks for the #AbandonThread indicator. Cheers.

[aberu]

I'm gonna guess none of the folks that use Bluetooth Keyboards & keep MiSTer connected to their home LAN care that CVE-2020-12351 is remotely exploitable on kernel 4.19 over the air. In essence making MiSTer a backdoor into their home LAN that someone outside their home can use to compromise their network.

https://security-tracker.debian.org/tra ... 2020-12351
https://security-tracker.debian.org/tracker/DSA-4774-1 (fixed version 4.19.152-1)

/root# uname -a
Linux MiSTer 4.19.0-socfpga-r1 #1 SMP Mon Mar 15 01:16:44 CST 2021 armv7l GNU/Linux

What benefit would fixing BleedingTooth Bluez exploits do for gamers that use bluetooth keyboards?
https://access.redhat.com/security/vuln ... edingTooth

Linux Bluetooth Zero-Click Remote Code Execution over Bluetooth on your MiSTer is certainly nothing to worry about!
https://www.youtube.com/watch?v=qPYrLRausSw
https://www.exploit-db.com/exploits/49754

Let me get this straight, the MiSTer has a password "1" for the root user account, and you are worried about this 80% effective and somewhat complicated bluetooth exploit that will give an unauthenticated user escalated privileges?

1. The attacker has to know the bd address first of all. Not impossible, but walk me through how in the real world someone running a MiSTer in their home is going to get hit by this vulnerability? I want to see how credible of a threat it is.

2. They have to be within bluetooth broadcast range to do this exploit. --> https://github.com/google/security-rese ... -c88j-47wq

3. They have to be so stupid that they are ignoring the fact that you can easily get root access to the MiSTer anyways.

Also, you realize this is known (according to your own link you cited) to affect kernels 5.4 through 5.9.13, right? Please provide evidence that it impacts 4.19.0, which uses a different version of blueZ entirely which may not have this vulnerability (or it may).

We get it, no one cares. It is just unfortunate as I said before. The excuses on what you THINK makes a best practice need not apply.

No one claimed that the MiSTer linux build uses best practices. You are claiming that it doesn't follow best practices and I challenged you to back up your claim and you went to such an absurdly irrelevant thing, hoping that no one would fact check you.

Are we saying there aren't any problems? Are we saying that this project follows best practices?? We are not, but you obviously show that you are just motivated to attack the project itself as opposed to suggest any decent changes.

Why didn't you point this out on the github issues page for the MiSTer linux repo? Why did you instead post it here in some dramatic fashion? Really makes one think. You wouldn't happen to be involved in a competitor project would you?

I'm beating a dead horse at this point, many of you clearly have no background in embedded devices, security, or linux, never mind threat modeling.
"NASA hacked because of unauthorized Raspberry Pi connected to its network"
https://www.zdnet.com/article/nasa-hack ... s-network/

These excuses and attempts to reason literally only support my original statement. Please... go on.

Ah yes, because the average user has a target on their home network's back the size of NASA's network. Good job bro. Lemme read up on the 49 page OIG report and get back to you to see if this is relevant to the MiSTer by doing a risk analysis. lol jk that would be stupid to compare to NASA.

Bluetooth has been proven exploitable from miles away with amplified gear, and an antenna.
https://www.npr.org/templates/story/sto ... Id=4599106

So actually yes. I know a few mates in the UK if you want me to have one stop by and test with you how far away you could be easily exploited.

I'll maybe test this out up close in person at some point tonight then, if I can get the exploit figured out from your sources. We'll see if the older versions prior to the CVE you linked cites are also exploitable.

I appreciate the hyperbole @jca, on the face of it suggesting those of us that perhaps want a package manager should use a little more diplomacy is funny. "Please return your DE-10 Nano. You are not the target market and do not understand the product" was of course extremely diplomatic.

I do wonder how real "angry" gets support, but pretend hostile doesn't. viewtopic.php?t=525

This place is very confusing. You are probably right. I'm gonna guess the next suggestion is I go buy a RasPi. Thanks for the #AbandonThread indicator. Cheers.

I suggest you a buy a chill pill.

If someone implicitly owns your entire infrastructure because they compromise a single weak device, you probably shouldn't own any hobby or IoT devices. Put it on a DMZ network and done. Seriously, we're talking about a piece of lab kit intended for student research in a school setting. It's never going to be a GP compute device (or managed as one), no matter how much that may gall anyone.

Right, this guy is treating the MiSTer like it needs to be enterprise-grade secure, when people have their houses filled with all kinds of more insecure shit every day, like their regular Windows computers, their unpatched routers, their passwords whose value is "password1" etc... It's such a weird obscure thing to worry about if your main concern is concern for the average user's home network. Not to say it isn't legitimate to want this stuff to be upgraded at some point, but hostile isn't going about this the proper way. Go to the issues page and point it out, be specific as to what the problem is, and describe why it is a problem. Them just asking for the buildroot is not productive.

[hostile]

" Please provide evidence that it impacts 4.19.0, which uses a different version of blueZ entirely which may not have this vulnerability (or it may)."

Is there something about (fixed version 4.19.152-1) that you didn't understand?
https://security-tracker.debian.org/tracker/DSA-4774-1

https://packages.qa.debian.org/l/linux/ ... 1927Z.html
https://www.kernel.org/pub/linux/kernel ... g-4.19.152
- Bluetooth: A2MP: Fix not initializing all members (CVE-2020-12352)
- Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel
(CVE-2020-12351)
- Bluetooth: MGMT: Fix not checking if BT_HS is enabled
- Bluetooth: Consolidate encryption handling in hci_encrypt_cfm
- Bluetooth: Fix update of connection state in `hci_encrypt_cfm`
- Bluetooth: Disconnect if E0 is used for Level 4

Your 1, 2, and 3 above are hardly worth addressing, especially given you flat out don't understand the difference in a remote wireless threat that can be exploited from miles away, and one to your self contained home LAN (ssh password).

"hoping that no one would fact check you" lol dude. I picked a random seemingly easy to understand issue. And yeah, look how you beat your chest like king ape, and you turned out to be wrong re: impacted kernel version.

"Why didn't you point this out on the github issues page for the MiSTer linux repo" as I said above, Sorg has made his position on the Linux subsystem clear, both in his words that I pasted above, and in his refusals to support other PRs and issues in the past. Literally not worth my time. I'm free to discuss my concerns here on the forum, still, am I not?

"if I can get the exploit figured out from your sources" you clearly don't have that skill level on deck. Lets not pretend, we both know few people here can check you on that claim, but you don't have to pretend with me. I mean you can't even work out the differences in the processor arch, let alone debug the potential impact. You could have simply looked at the kernel patch, but we both know you aren't really that invested in this part of your theatrics.

"Right, this guy is treating the MiSTer like it needs to be enterprise-grade secure" literally no one is doing that. The ask was for a basic package manager, and that updates to packages and the OS be handled like literally EVERY other linux platform on the planet. Your hyperbole, and exaggeration are cool though. "Package managers have overhead and the MiSTer isn't a general purpose linux distribution" was how we started on this path. viewtopic.php?p=22856#p22856

"Them just asking for the buildroot is not productive" as if asking something on the issues page is a functional way to get something.

This is way off topic at this point, simply because you wanted to "check" someone on a simple example. Feel free to put this train back on the tracks. The fact remains, you folks act like basic linux package management has some huge level of overhead, and maintenance requirements. It isn't. Likewise, you advocate for this reinvention of the wheel, which is honestly way more complex than a proper update repo: https://github.com/MiSTer-devel/Updater ... updater.sh

The amount of effort put into explaining why MiSTer isn't right for a package manager twists my mind! Even if someone did the work to support it, the PR would be refused, we all know that.

[Bas]

This thread is veering a bit off track. I'm now up to the point where I have Jenkins building packages for all releases of all computer and console cores and they can be installed, upgraded, downgraded and removed at will on my test VM. Of course this is tackling the simplest bits first but the idea functions. No changes to anyone's workflow required. Next up: arcades. When that works I'm looking at dropping the binaries for apt into my actual MiSTer and see how that goes.

[aberu]

Jesus christ, you don't even know how to use quotes in a forum man.

" Please provide evidence that it impacts 4.19.0, which uses a different version of blueZ entirely which may not have this vulnerability (or it may)."

Is there something about (fixed version 4.19.152-1) that you didn't understand?
https://security-tracker.debian.org/tracker/DSA-4774-1

https://packages.qa.debian.org/l/linux/ ... 1927Z.html
https://www.kernel.org/pub/linux/kernel ... g-4.19.152
- Bluetooth: A2MP: Fix not initializing all members (CVE-2020-12352)
- Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel
(CVE-2020-12351)
- Bluetooth: MGMT: Fix not checking if BT_HS is enabled
- Bluetooth: Consolidate encryption handling in hci_encrypt_cfm
- Bluetooth: Fix update of connection state in `hci_encrypt_cfm`
- Bluetooth: Disconnect if E0 is used for Level 4

Right, what part of "or it may" don't you understand? Thanks. You gotta be less insufferable.

Your 1, 2, and 3 above are hardly worth addressing, especially given you flat out don't understand the difference in a remote wireless threat that can be exploited from miles away, and one to your self contained home LAN (ssh password).

Okay got it. So you think the average person's home LAN, especially with gamers forwarding ports frequently on their shitty unpatched routers, is not a major concern or anything, but some hackerbro using a high powered bluetooth gun from 2005, using this one exploit hoping to get in, is the real risk here to everyone's MiSTer's and should be taken extremely seriously. Got it. Priorities brutha.

"hoping that no one would fact check you" lol dude. I picked a random seemingly easy to understand issue. And yeah, look how you beat your chest like king ape, and you turned out to be wrong re: impacted kernel version.

I mean, I said OR IT MAY, but okay. I wasn't wrong, I'm open minded, unlike you. You can ignore that all you want.

"Why didn't you point this out on the github issues page for the MiSTer linux repo" as I said above, Sorg has made his position on the Linux subsystem clear, both in his words that I pasted above, and in his refusals to support other PRs and issues in the past. Literally not worth my time. I'm free to discuss my concerns here on the forum, still, am I not?

Okay, so you have just inferred that he won't patch this particular vulnerability, solely because you have read his response to other adjacent issues from a long time ago. Sounds like you aren't putting in any actual effort into getting this fixed when you ostensibly care so much about it. That's a weird conflict between your stated motives and your actions here.

"if I can get the exploit figured out from your sources" you clearly don't have that skill level on deck. Lets not pretend, we both know few people here can check you on that claim, but you don't have to pretend with me. I mean you can't even work out the differences in the processor arch, let alone debug the potential impact. You could have simply looked at the kernel patch, but we both know you aren't really that invested in this part of your theatrics.

What's the purpose of your theatrics? What's your intent?

"Right, this guy is treating the MiSTer like it needs to be enterprise-grade secure" literally no one is doing that. The ask was for a basic package manager, and that updates to packages and the OS be handled like literally EVERY other linux platform on the planet.

No. Not every other linux platform on the planet. There are loads of embedded devices running linux that don't have package managers. The MiSTer is being treated by the project maintainer as an embedded device, and those are not "all" supplied with package managers. Sorry.

This topic is about how a package manager will solve the problems that you and your buddies were being vague about until now. At first it was to make the cores easier to update? lol, right. Now it's obvious you are of the same group trolls that have been spazzing out on twitter for months because they want to fork the MiSTer project to "destroy it", but still beg for the buildroot, despite claiming to have easily figured it out on their own (which is a confusing mess of contradictions anyways), while complaining about security only the last month or so, when before it was complaining about all sorts of other things that had nothing to do with security. Shifting your rhetoric when one method of propaganda doesn't work, it's kinda annoying.

Please keep talking about theatrics when that's all you are doing.

Your hyperbole, and exaggeration are cool though. "Package managers have overhead and the MiSTer isn't a general purpose linux distribution" was how we started on this path. viewtopic.php?p=22856#p22856

What? I didn't even say that lol. That was someone else.

"Them just asking for the buildroot is not productive" as if asking something on the issues page is a functional way to get something.

The Mr. Fusion creator literally figured out the buildroot on his own. I'm sure you could too. Probably should stop being lazy and do the work you are demanding others do for you. You aren't entitled to sorgelig agreeing with you. Go ahead and fork the project and see if you manage it better I guess. Compete in the marketplace buddy.

This is way off topic at this point, simply because you wanted to "check" someone on a simple example. Feel free to put this train back on the tracks.

You are the person who flew off the rails with the stupid security complaints about a hobby video games FPGA system that is in like 0.000001% of homes in mostly wealthy countries only. Now you are asking to re-rail the thread YOU derailed?

The fact remains, you folks act like basic linux package management has some huge level of overhead, and maintenance requirements. It isn't. Likewise, you advocate for this reinvention of the wheel, which is honestly way more complex than a proper update repo: https://github.com/MiSTer-devel/Updater ... updater.sh

Why are you lumping me in with someone talking about overhead? I did mention maintenance requirements however. For the most part the bash script has been barely ever changed, check the commits. It works. And the best part is, people that know how to edit bash scripts can easily contribute. Fixing problems with package configuration is often a little less likely to have more people contribute a PR or raise productive feedback to an issue.

The amount of effort put into explaining why MiSTer isn't right for a package manager twists my mind! Even if someone did the work to support it, the PR would be refused, we all know that.

Why would Sorgelig do the work for you? If you are such a quitter then you'll never know I guess. Have fun being perpetually angry and deciding to not do anything about it.

[aberu]

This thread is veering a bit off track. I'm now up to the point where I have Jenkins building packages for all releases of all computer and console cores and they can be installed, upgraded, downgraded and removed at will on my test VM. Of course this is tackling the simplest bits first but the idea functions. No changes to anyone's workflow required. Next up: arcades. When that works I'm looking at dropping the binaries for apt into my actual MiSTer and see how that goes.

Well done! I'm glad you are doing the work instead of complaining like hostile over here.

[hostile]

You seem really angry! I love all the ad-hominem attacks in your loose comments. I don't see this conversation being productive. Thanks for your time!

[hostile]

"you obviously show that you are just motivated to attack the project itself as opposed to suggest any decent changes". Lol wut?

I went back and re-read some of this. It was also not at all lost on me that you tried to sell it off as "unreasonable" to suggest that a package manager be added, or that some sort of adherence to either a) buildroot standards or b) update practices be maintained. Somehow I'm "attacking" your project here, which I don't get. Likewise this "destroy it" thing, I don't get. I've never said that personally, nor do I even know the source of this mythical quote that everyone wants to throw around constantly.

Short of making this usable for me as an end user after having invested in some hardware, I could legit care less about your perception of someone trying to "destroy" your project. I don't even understand how that can happen to something that is Open Source, and has a solid community. That is such a wildly paranoid accusation to make to a random person.

"Jesus christ, you don't even know how to use quotes in a forum man" or I just don't care to? You really are abrasive about things for literally no reason. Is this how welcoming the community is generally speaking?

[grizzly]

You're trying to get a home-built go-kart to pass a NHTSB test. It'd ridiculous on the very face of it.

Right, this guy is treating the MiSTer like it needs to be enterprise-grade secure, when people have their houses filled with all kinds of more insecure shit every day, like their regular Windows computers, their unpatched routers,

Lightbulbs/refrigerators/owens/etc and many cant even be upgraded even IF the user and the maker would want to.

No. Not every other linux platform on the planet. There are loads of embedded devices running linux that don't have package managers.

There are probably many times more devices that do not run a package manager then systems that do.
Hell there are probably many times more devices that do not run a package manager AND can´t be updated then system with package managers.

[rhester72]

I've come to the inescapable conclusion we're being super-trolled (and quite successfully). It's like the guy doesn't even grasp that Linux was chosen for the ARM side of the house because it's convenient and available *to support the FPGA function, which is the _entire goddamned purpose of the board_*. It could have just as easily been Minix, for Chrissakes. (Wonder what sort of CVE opportunities there are there?)

This is, of course, with full realization that he's now claimed he was going to take his ball and go home three times in as many hours. LOL

At least he's contained to one thread that be tactfully closed and nuked later without any real harm.

[hostile]

"claimed he was going to take his ball and go home three times in as many hours" did I though? "It's like the guy doesn't even grasp that Linux was chosen for the ARM side of the house because it's convenient" lets be honest with each other, Sorg happened up on DE10 when he was trying to "destroy", I mean "port", or "hostile fork" MiST, am I right? He didn't really do any choosing. Someone earlier mentioned it would never be a general computing device, all the while I laughed at the literal existence Xfce Desktop, and LXDE Desktop variants.

I don't think there is any real harm in helping folks that tend to be abrasive toward suggested changes continue to act out. There were some points in there, but they were likely overshadowed by the tantrum that ensued. I will say Rhester, my intent isn't to troll you but perhaps you did catch on to me amplifying some of the absurdity in the responses.

[aberu]

For someone who says they are done and that they don't care, you sure are replying to every single thing everyone says btw.

[dmckean]

"hostile fork"

What the hell is a hostile fork? The entire point of open sources projects is that no one person has control over them they can be forked limitlessly. Forking is always something that is encouraged.

[hostile]

For someone who says they are done and that they don't care, you sure are replying to every single thing everyone says btw.

you keep saying I said I was done? When did I say that? I said I didn't care about your hyperbole about project theft. I also said that I thought the conversation was not going to be productive. "Thanks for the #AbandonThread indicator" doesn't mean I'm leaving, it was literally a sarcastic response to the "Please return your DE-10 Nano" comment, please try to keep up!

"hostile fork"

What the hell is a hostile fork? The entire point of open sources projects is that no one person has control over them they can be forked limitlessly. Forking is always something that is encouraged.

Forking is not encouraged here in the MiSTerFPGA project. From what I understand it is explicitly part of why the buildroot is so contentious. It is literally discouraged by Sorg so people "don't run off and fork the entire project that he made without talking to him" per one of the project heads. Folks that ask about buildroot or trying to recreate it are often accused of "trying to jack the project", or similar like above the weird claims to want to "destroy it" re: MiSTer project. Other folks just like to dog pile on "lazy" claims because people ask for things that outta already be included in the "open source" aspects of this project.

viewtopic.php?p=4327#p4327
"promotes fragmentation which is not good... promoting turn-key solutions which helps this IMHO harms the project because nullifies any incentive to join mister-devel... it may be really welcome by users, but it's bad for MiSTer as a project."

[throAU]

No, you are not 'reducing complexity'. you are moving it. Because now someone has to generate packages for what was previously just a dead simple release process for core developers. Now you're going to say 'automated CI/CD!' but now someone has to maintain that. And when it breaks (and it will) the core authors have almost zero visibility into it, and likely don't really have the expertise or motivation to debug it if they did. So all it does it delay their release or make it annoying to deal with.

I feel like you're trying to 'fix' MRAs by using packages and ignoring the fact that for everything else you're going to generate a package file for a single RBF, which seems a bit silly.

At the end of the day users are still going to run a script to update their mister, even if packages are involved. So now you have two problems.

What rhester72 means is that the 'linux' OS of the mister is updated as a single image, which is loopback mounted on boot. So when the 'linux firmware' of mister is updated, it completely replaces that image file.

Exactly this.

Adding packages to a platform isn't automatically/always the best thing to do. I get it you might feel you're (the OP) making things simpler, but really, you aren't. You're adding complexity/maintenance to the project for MAYBE some simplification on your end using the packages - which you could instead do by compiling packages from source with a /usr/local prefix or such like we did back in the old days.

You're simply shifting complexity from your use case to the maintainers of the packages.

And as rhester72 said - this is an appliance that may get full image updates, etc. It is not and has not been designed as a general purpose OS.

[Solskogen]

What will an updated linux kernel do for us gamers?

Not much, probably nothing. But compiling the main MiSTer file will be easier as you don't need to install a extra compiler instead of using the ones provided by Debian and/or Ubuntu. Keep in mind that I don't demand that someone else should do it. If anything, I'll do it my self