MiSTer FPGA Forum

Please stop conflating the presence of a package manager with the idea that it should be used for maintenance of the core OS. That's an assumption that's at the very least not true for the bit of work I'm attempting at the moment. I'm also very well aware of the fact that the initial design premise of MiSTer's update mechanism was to keep its business logic running on the board instead of some external infrastructure. There is a lot to be said for that approach, especially when you have very little to deal with other than a bundle of independent RBF-files and a near-static partition image.

As it stands right now, my MiSTer system goofded itself up two times now since I built it in late 2020. Mind you: that's not counting the times I broke it myself due to my own stupidity. It just unhinged itself to the point of being unbootable while I was doing exactly what it said on the label. That's what triggered me to start looking at the Linux end of the project.

Corruption to IT systems happens only when moving parts interact in a way that's unforeseen and from which recovery is less than obvious. Recovery being less than obvious is also often the reason people place the label "corruption" on such a condition in the first place. Usually things aren't really broken beyond repair, but just in an unexpected state. I'm trying my hand at very little else than reducing the opportunity for unexpected state here.

In the Linux world we have a number of tried and true tools to manage moving parts: package managers. My sole intention with what I'm doing is to bring the moving parts of *my own* MiSTer board under management of such a solution. In this case dpkg/apt, which is an extremely reliable and proven pre-invented wheel for just this purpose.

Of course this requires me to move the updater business logic off the board and onto, for now, my existing Jenkins setup and an S3-bucket to host the packages eventually. I am 100% aware that this violates the initial design principle of MiSTer's updater.

Now as to why I disagree with the design principle. That's because I disagree with the entire premise that the MiSTer is like an embedded or IOT system. Rhester72 stated a few posts up that the DE10-nano is a piece of lab kit, and I agree. However, a DE10-nano turned into a MiSTer does not qualify as such anymore.

Read the forum here. End users all over the place are asking how to adjust the MiSTer's default installation to their liking, which is to be expected for a DIY-project like this. Custom cases, add-on boards, controller interfaces, displays, midi-devices.. the works.. it's all part of an awe-inspiring ecosystem whether anyone likes it or not. In that sense MiSTer is turning the DE10-nano into the Raspberry Pi of FPGA dev-boards. No matter how Intel ever intended the DE10-nano to be used, we're simply not in Kansas anymore. The same effectively goes for how Sorgelig intended the MiSTer project iself. Things are growing organically, and it never hurts to test previous assumptions and experiment with alternative approaches in a controlled way.

Now update_all.sh may not be part of the project, but every Joe has it on their MiSTer and uses it with reckless abandon. I personally feel that now would be a very good time to streamline the itch that update_all.sh scratches by unifying the approach to MiSTer updates. To me it would be very useful if the MiSTer's official cores (and supporting tools like midilink etc.) and those made by people like Jotego could be pulled from different apt repositories but we'd be using one single set of on-board business logic to do it.

Sure there's package and repo maintenance to be done, and that's the flipside of this coin. I'm currently in the process of finding out just how much effort and money this would really cost. For now, I simply don't know yet. I'll be dogfooding it for a while myself first and when I'm satisfied with its reliability, I'll publish the entire scaffolding under the same Free Software license terms as the rest of MiSTer so that won't be a roadblock. I'm not asking anything of the MiSTer maintainers and I won't be touching anyone's workflow. Nor will I be taking any capacity away from core development. Once I release my work everyone can evaluate it on their own terms, at least there'll be a factual foundation for an honest and open discussion on whether or not this whole idea would benefit MiSTer or not. And if it does not, the world will keep on turning and at the very least I will have sharpened a few of the more rusty tools in my shed.

Now if we could please stop the vitriol in this thread, that would be much appreciated.

You should aim for zero cost. All done via github if possible. We've kinda been through the 3rd party hosting thing and it just ended with a bunch of people having to switch to something else when that particular party retired all their work. That and this project is likely too loosely organized to sustain reliable paid hosting for anything.

You should be able to easily build packages via github actions. I also suspect as gross as this sounds, you could abuse github repos as apt repos. (future me here before I hit send: https://github.com/rpatterson/github-apt-repos)

I'm also greatly offended that this is a retro gaming project and you're not using pacman. I mean, look at the name.

hostile wrote: ↑Mon Apr 12, 2021 4:33 pm 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 think I'll be fine, wired keyboard and all....

Not sure if I'm missing something, but one reason for the third-party update_all script is to separate out handling of intellectual property from the standard update process.

If the end user is still going to need to run a script to handle that part, and then also deal with a package manager, I think you will see people sticking with the script method, since it's run-and-done and covers everything at once.

Not every linux system is general OS with package manager. A lot of systems (including Android) have no package managers because linux for these systems are not for users. It does background tasks not expecting user interaction. MiSTer is one of these systems. MiSTer gives some amount of access to system and even has some utilities integrated, but it's not a green light to use MiSTer as generic computer. Basically MiSTer user should not know about existence of Linux on MiSTer.

Package manager also implies the fact that Linux should be based on some existing Linux with large amount of packages like Ubuntu. This is not acceptable for MiSTer as it will require a large and heavy part of Linus which contradicts the nature of MiSTer being an FPGA platform in the first place.
Even system volume of Linux on MiSTer is read-only (unless user logged in) so it limits the way Linux work.

No one talks about package manager on router, or refrigerator running the Linux. Neither ask it from MiSTer.

I see this topic is going to nowhere and only increase the flame. There is really nothing left to discuss here.

There is MiSTer LXDE Linux (with package manager and based on Ubuntu) to play with if someone wants.