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 :) >> 'ne2000': add third-party ne(4) emulation > > I guess this is the easiest way to get networking support in dosbox. > But is that a good thing? Running DOS applications on the modern > internet looks dubious at best. Actually, friends have used this in the past to play network doom w/ me running it on a real machine =) There are some other uses, as well. Me's not shooting anyone for this not being included in the first place, but it's handy at times. > Technically such a patch should probably be handled using > PATCHFILES/SUPDISTFILES. Yeah, you're prolly right, me's not that familiar w/ ports so metook the most straightforward way... >> '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)? 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. > 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. > 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. > s/WANT_LIB/WANTLIB/ below Ah, sorry, will fix on this end :) Again, if there's any interest (please speak up folks!), me'll work on this further. --zeurkous. -- Friggin' Machines!
