On Sat, Jun 01 2019, <zeurk...@volny.cz> wrote: > Haai, > > "Jeremie Courreges-Anglas" <j...@wxcvbn.org> wrote: >> >> Not to rain on your parade, but... > > Don't worry, me's just sharing a WFM :) > >>> 'dyncore': re-enable the dynamic core (possibly insecure) >> >> You don't mention a rationale for this. The only wxneeded report I know >> of mentions no performance change. > > Mehasn't measured, but on me (by your standards possibly ancient ;) > machines it really does help performance a lot (mewouldn't have > bothered if it didn't). > >> https://marc.info/?l=openbsd-ports&m=149053625314161&w=2 >> >> So what's the point of lowering the security of an emulator possibly >> used to run untrusted images? > > That's the one thing medoesn't do, mehas a background in IBM PC poop > (the horrors of me youth), so mealways manually installs stuff. Of > course, one needs to know what one is doing, but UNIX ain't for lusers. > > Of course, your point remains: most stuff running inside the emulator > is inherently untrusted (since most often no source code is available), > so there's still a risk. Honestly, though, given the general, ehrm, > "quality" of dosbox code, mesuspects some much larger holes in there > than --disable-dynamic-core could possibly address. > > It's a risk and people are free to take it or not to take it. Me's just > contributing a patch :)
Who should provide actual data regarding the risk increases and the *actual benefits* if not you? While Jonathan (maintainer) has the final say here, I would object to such a FLAVOR and patch being added. A better way to spend time on dosbox would be to investigate ways to improve speed without sacrificing basic security protections. [...] >>> 'nosplash': disable spam piccy upon invocation >> >> Is that a serious proposal? The wording used for the ifdef doesn't seem >> appropriate. > > *shrugs* It's up to individual operators what runs on their machines, > and how it runs. Do we really want to end up w/ things like bc(1) first > sprouting lines of copyright info before accepting any input (the GNU > version does)? For the record: --8<-- bc 1.07.1 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. -->8-- You're indeed free to do whatever you want on your machines, but the OpenBSD ports tree can't get away with removing copyright notices from software later distributed on the mirrors. > Besides, me's always figured that the ad was put in as a response to > commercial peddlers wrapping old games inside dosbox and re-selling them > w/o giving any credit or indeed any indication, which is definitely not > the case here. Again, maybe not for your own use case. emulators/dosbox/Makefile: PERMIT_PACKAGE_CDROM= Yes so people may sell packages produced with the port. >> Regarding the intent, your diff contains the surrounding >> line: >> >>> + /* Please leave the Splash screen stuff in working order in DOSBox. We >>> spend a lot of time making DOSBox. */ >> >> That change doesn't look desirable in the ports tree IMO. > > It's a patch, and an optional one: individual operators are free to > honour or disregard the request. Me's giving choice, not a strait > jacket. > >> Obviously tests on -current would be better. > > Medoesn't have any machine that runs -current right now, sorry. > >> If you're proposing this diff for inclusion in the ports tree, please >> make that clear. > > Medoesn't know. Depends on whether or not people like it enough. > >> Your earlier proposal (with MAINTAINER in Cc) > > Meforgot the Cc this time, so mesent it separately to the maintainer > moments later. > >> didn't >> make it clear either: >> >> https://marc.info/?l=openbsd-ports&m=154669079320603&w=2 > > Well, honestly, me's been burned a little here and there when trying to > contribute to OpenBSD... If there's interest, me's certainly inclined to > rework it to make it more suitable for inclusion. Proposals need to be reviewed, tested and committed. This takes time, and time is a scarce resource. So again, please make it clear whether you consider your next contributions proper for inclusion in the ports tree. You'll save other people's time and you'll avoid rants from grumpy porters like me: a clear win for everybody. >> FLAVORS should be seldom used, they add complexity and make >> tests/updates harder. > > The lack of FLAVORS in several packages (feh, fceux...) actually made me > build them manually, in order to cut down on the bloat. So that argument > works both ways. Looking at the deps of feh and fceux, I doubt you're having a point here. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
