Why not use a package manager?

Kernel, Main, Utilities & Applications, Miscellaneous Devices.
hostile
Posts: 21
Joined: Wed Feb 24, 2021 6:47 am
Has thanked: 10 times
Been thanked: 1 time

Re: Why not use a package manager?

Unread post by 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
Posts: 21
Joined: Wed Feb 24, 2021 6:47 am
Has thanked: 10 times
Been thanked: 1 time

Re: Why not use a package manager?

Unread post by 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
Posts: 375
Joined: Tue Jun 16, 2020 12:22 pm
Has thanked: 55 times
Been thanked: 76 times

Re: Why not use a package manager?

Unread post by grizzly »

rhester72 wrote: Mon Apr 12, 2021 5:36 pm You're trying to get a home-built go-kart to pass a NHTSB test. It'd ridiculous on the very face of it.
:shock: :? ;) :) :D :lol: :mrgreen:
aberu wrote: Mon Apr 12, 2021 7:50 pm 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.
aberu wrote: Mon Apr 12, 2021 8:54 pm 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
Top Contributor
Posts: 1107
Joined: Thu Jun 11, 2020 2:31 am
Has thanked: 13 times
Been thanked: 169 times

Re: Why not use a package manager?

Unread post by 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
Posts: 21
Joined: Wed Feb 24, 2021 6:47 am
Has thanked: 10 times
Been thanked: 1 time

Re: Why not use a package manager?

Unread post by 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.
User avatar
aberu
Core Developer
Posts: 1144
Joined: Tue Jun 09, 2020 8:34 pm
Location: Longmont, CO
Has thanked: 244 times
Been thanked: 388 times
Contact:

Re: Why not use a package manager?

Unread post by 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.
birdybro~
dmckean
Posts: 307
Joined: Sat Jan 16, 2021 7:03 am
Has thanked: 387 times
Been thanked: 95 times

Re: Why not use a package manager?

Unread post by dmckean »

hostile wrote: Tue Apr 13, 2021 12:16 am "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
Posts: 21
Joined: Wed Feb 24, 2021 6:47 am
Has thanked: 10 times
Been thanked: 1 time

Re: Why not use a package manager?

Unread post by hostile »

aberu wrote: Tue Apr 13, 2021 2:23 am 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!
dmckean wrote: Tue Apr 13, 2021 2:37 am
hostile wrote: Tue Apr 13, 2021 12:16 am "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
Posts: 181
Joined: Fri Sep 11, 2020 1:06 am
Has thanked: 229 times
Been thanked: 27 times

Re: Why not use a package manager?

Unread post by throAU »

zakk4223 wrote: Fri Apr 09, 2021 4:17 pm 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
Posts: 89
Joined: Mon May 25, 2020 5:33 am
Has thanked: 11 times
Been thanked: 6 times

Re: Why not use a package manager?

Unread post by Solskogen »

ARCADEAGES wrote: Mon Apr 12, 2021 2:52 pm 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 :-)
Bas
Top Contributor
Posts: 518
Joined: Fri Jan 22, 2021 4:36 pm
Has thanked: 60 times
Been thanked: 225 times

Re: Why not use a package manager?

Unread post by Bas »

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.
zakk4223
Posts: 270
Joined: Sun May 24, 2020 10:55 pm
Been thanked: 107 times

Re: Why not use a package manager?

Unread post by zakk4223 »

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.
RascalUK
Posts: 156
Joined: Mon Jun 08, 2020 2:02 pm
Location: Manchester, UK
Has thanked: 72 times
Been thanked: 23 times
Contact:

Re: Why not use a package manager?

Unread post by RascalUK »

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....
Lightwave
Posts: 231
Joined: Sun May 24, 2020 10:06 pm
Has thanked: 110 times
Been thanked: 68 times

Re: Why not use a package manager?

Unread post by Lightwave »

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.
User avatar
Sorgelig
Site Admin
Posts: 877
Joined: Thu May 21, 2020 9:49 pm
Has thanked: 2 times
Been thanked: 211 times

Re: Why not use a package manager?

Unread post by Sorgelig »

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