Live data from Hacker News

ScummVM on the App Store

apps.apple.com

191–197 of 197 posts

Re: ScummVM on the App Store

#191

Earlier quoted context omitted.

Not sure if you linked the wrong video, but the one you linked to barely supports your comment. Setting aside that abandoning OpenDoc turned out to be the right call, I see a dude trying to get a rise out of Jobs and Jobs handling it in a very respectful way, going as far as admitting they make mistakes and that he is flawed, but that ultimately the decisions are made with the end user (and sales) in mind and less wi…

> So I have no lost love for devs that couldn’t be arsed, How are teams that no longer exist supposed to recompile anything? Plenty of source is laying around where the last person who knew how to compile it left the company years ago and no one even knows how to check the software out from the source repo anymore. (Pre Git, it wasn't always obvious how to even pull software down from repos, tools like perforce allow…

As I stated in a reply[0] to a similar comment below, the way you’re framing it doesn’t reflect the reality of this specific 64-bit transition.

> How are teams that no longer exist supposed to recompile anything? Plenty of source is laying around where the last person who knew how to compile it left the company years ago and no one even knows how to check the software out from the source repo anymore.

This transition started five years after the birth of the App Store. Most of the abandoned apps and games were created in the two years between the start of the transition and the deadline, not to mention that many of those developers happily published other apps and games after the transition was complete.

So, the notion that there were no people around or that the source code was inaccessible is not believable.

> (Pre Git, it wasn't always obvious how to even pull software down from repos, tools like perforce allow for fancy remapping of folders so you cannot necessarily just pull source down, also I've worked in repos where you needed specially modified scripts that weren't in the repo so you could actually build things!)

This was well after the birth of Git. At the start of the transition, more than half of the developers were using Git, and another 40% were using SVN. So, we weren’t exactly in the stone ages of software development.

> Microsoft's MO has been that once the end user has acquired an executable, that program will keep working damn nearly forever.

This is becoming less and less the case. I must install dependencies like older .NET frameworks, track down obscure dlls, or generally run into compatibility issues.

While annoying, I can’t fault them for it. It’s simply not feasible to ensure compatibility in perpetuity and deliver a smooth, innovative experience.

You see them attempting this with their abomination, that is, the control panel and its underlying systems. It’s grafted together from all kinds of components that originate from pretty much every Windows in existence.

0: https://news.ycombinator.com/item?id=38827562

Re: ScummVM on the App Store

#192
post #182

Earlier quoted context omitted.

The source for the version that Apple ships is at https://opensource.apple.com/source/bash/bash-123.40.1/

The source for something that resembles something Apple ships is at that link, sure.

I'm not sure how to respond to this. You're making the claim that Apple is violating the GPL by not publishing the source of the bash. When shown the open source repository that Apple provides to comply with the license you wave it off and suggest that the binary that Apple provides isn't compiled from that source.

Do you have any evidence to support the claim that bash on a Mac is not what is build with the source there? If so, I am sure that the FSF would love to have an easily winnable lawsuit against a big company that goes in favor of the GPL. That the FSF hasn't done so in a decade and a half suggests that there is no license violation.

Re: ScummVM on the App Store

#193
post #192

Earlier quoted context omitted.

The source for something that resembles something Apple ships is at that link, sure.

I'm not sure how to respond to this. You're making the claim that Apple is violating the GPL by not publishing the source of the bash. When shown the open source repository that Apple provides to comply with the license you wave it off and suggest that the binary that Apple provides isn't compiled from that source. Do you have any evidence to support the claim that bash on a Mac is not what is build with the source t…

It’s literally at the top of this thread! Apple for years provided source code that didn’t compile because they considered some of their proprietary additions as “secret” and failed to include those headers. If you want more evidence of this being a regular occurrence, I have plenty of examples where Apple leaves security features out of the sources intentionally. Or you can look at WebKit, which is LGPL for many components but whose public source code has an explicit gap (search for “WebKitAdditions”) where Apple violates the license by shipping code in their OS that is not included.

Re: ScummVM on the App Store

#194

Earlier quoted context omitted.

What I really dont get is why in some cases, when it looks obvious to me that the XP UI is just some Microsoft GUI for the drivers, why Microsoft didn't consolidate those APIs into the modern UI. They own the entire run-time, I don't understand why they cannot add a translation layer.

It beats me; as you said, it would take relatively modest efforts to add a translation layer. Especially considering that most of it already is a translation layer for the Windows Registry.

Well they own the entire platform, and they know which APIs are called by drivers. I feel like its doable.

Re: ScummVM on the App Store

#195
post #113

Earlier quoted context omitted.

Apple is very weird with how they interpret that part of their rules. iSH is allowed but not iDOS, etc.

iSH has compiled the binaries for arm64 so they actually run natively. When they do a syscall to malloc they are actually doing a syscall to malloc. iDOS is interpreting the bytecode and wrapping the unavailable things with its own implementation. When a DOS application runs malloc, the memory is assigned by iDOS instead. I’m not saying Apple is consistent, but your example doesn’t show that well.

You're thinking of a-Shell, which does offer compiled & locked binaries in a command line environment on iOS (via "ios_system"). Even then, they also support running WASM/WASI modules in a-Shell's command line environment.

Re: ScummVM on the App Store

#196

Earlier quoted context omitted.

Isn't iSH literally an x86 emulator?

Yeah I mean, people think it’s a legal or engineering issue. If an App Store Editor (aka category manager) likes you, you will do alright.

This is why App Store needs 'conceptual approvals'. I would never build anything 'cool' on iOS knowing that 'cool' things tend to piss off Apple.

Re: ScummVM on the App Store

#197
post #151
post #116

Earlier quoted context omitted.

Forbidding tivoization does not forbid running the program, it forbids embedding the program in some piece of hardware and then not providing a means for the end user to run their own modified version on this same hardware. If a TV is to use some GPLv3 program, then it must allow the user to replace the program with their own version. And yes, tivoization is a major reason why GPLv3 was written indeed, it was seen as…

But what about apple restricting you from running a binary? If you don't have an apple id, you can't run apps? And you cannot redistribute the binary to someone else, since it won't run.

I agree with you on this, I guess I was bothered by the phrasing.
Post reply on HN