This reminded me of the fact that excellent remasters of monkey island were released on the iPhone (and a few other paltforms) but were removed from the App Store after a few years. It’s a shame, they had great new artwork and sound/music but you could switch back and forth with the old art and it was cool to see the difference in each scene.
I was so pissed when I went to re-download them and they disappeared even from my Purchased list. Complained to Apple and they basically said "shouda made backups, good bye and fuck off". $12 down the drain.
They still sell the enhanced editions on PC and Xbox (even works on One and Series X|S). Probably still PS3 too. They probably couldn't be bothered to update it to 64 bit on iOS.
If they got depreciated once, it's gonna happen again. Apple should invest in Microsoft-tier backwards compatibility if they want to avoid publishers abandoning their software.
As an end user it’s already annoying how, mainly big devs, are extremely slow in adopting the latest APIs, this would only motivate them more to just sit on their laurels.
As a dev for Apple platforms it would become a buggy mess and would lead to less bumping of target OS versions, which in turn leads to needing to reinvent wheels and coming up with time consuming workarounds.
Just one look at the gazillion ways Windows 11 has implemented configuration apps, from as far back as the XP era, has me shudder. You start out with Win 11 stuff but oh, you want to use that one thing? Now you’re lopped into Windows 7 stuff oh you want this other thing, enjoy this XP app, etc, etc.
All in the name of backwards compatibility, no thank you.
Hell, the fact that they had to skip Windows 9 because of so many devs checking for a 9 to detect 95/98 is another such messy nonsense.
If I had to choose between that experience or Apple forcing me every year to learn an entirely new programming language + UI framework + persistent storage framework I’ll happily become a polyglot because the MS way of doing things is ridiculous.
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.
XP? They still have the NT 3.5 UI if you dig deep enough. Translating these is just asking for trouble when an important checkbox moves out of the frame because the original dev, in 1993, placed it with absolute coordinates. And there's no way in hell MS has access to all of these vintage drivers.
The driver has to talk to the OS somehow, and they have insane amount of telemetry, might as well use it to some actual usefulness. Always allow a way to "use the old UI" with this approach, but at least then, you can have more uniformity.
Most software is written for ten year business cycles. Maybe the Apple approach makes sense for most consumers and the few little apps they use, but there's reasons why Microsoft is so strong in the enterprise, and backwards compatibility is a huge part of that.
I’d say that more and more are moving to SaaS and/or platform-agnostic web-based stuff (even if it just runs on an on-prem server).
But you’re right in that a lot of enterprise software is/was written with ten years or more in mind.
Having seen it in action, I wonder if that’s the right course of action just in terms of security and what passed as acceptable UI alone, but I suppose that’s a topic for another time. For most enterprises, it’s a cost consideration where there’s a high tolerance for crap as long as it means that it saves money.
While Apple is nowhere near as uncommon in the enterprise world as it used to be, it’s no secret that enterprise is far down Apple’s priority list. Backward compatibility (or rather lack of motivation to facilitate that) might very well be a factor in that, but it seems to be more a matter of not needing to tap into that market.
I suspect Apple considers developers ignoring a five(?) year notice period that 32 bit compatibility will be dropped a sign that the publisher has already abandoned their software.
Expecting old software to be backwards compatible forever is unrealistic. Even modern 64-bit Windows doesn't support 16 bit applications, and the only reason this isn't a problem is because of how long ago they were of any importance.
Old software still lives on in emulation and old hardware. If a developer doesn't feel the need to keep it updated for new hardware, it can join the outdated hardware it was made for in the archive.
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 with what kind of nifty technology is behind it.
Specifically on the matter of 32-bit support, not dropping it would’ve meant not being able to make the leaps forward that they were able to make, which led to a better user experience.
From the developer side of things, as a developer for Apple platforms, it’s a silly discussion to begin with because in 99% of the cases it just meant recompiling it against the latest SDK.
So I have no lost love for devs that couldn’t be arsed, even ignoring the fact that the entire ecosystem is known for rapid improvements and continuous maintenance. In fact that’s what most indie devs love about it.
> 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 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!)
Microsoft's MO has been that once the end user has acquired an executable, that program will keep working damn nearly forever.
16bit support was the only time they ever dropped anything, and people are still upset about that.
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.
This assumes you have all the source code for everything available, the person to do it ready, and that no compiler errors anywhere have crept in through the many revisions of the SDK. None of these assumptions hold for iOS ports that sold poorly (as most did), that were done by some team (likely defunct) as a one-off, that probably used a bunch of middleware they didn't own. It's just not worth it, otherwise it would've happened.
You’re acting like this is about decades-old software with obscure source code that’s nowhere to be found.
The transition to 64-bit started in 2013 with iOS 7, 5 years after the App Store launched and included a 64-bit compiler in Xcode 5 that year.
Not long after, 64-bit was set to default for new projects in Xcode.
That was the point developers should have made the transition.
Instead, we saw that most developers didn’t bother, and by the time 2015 rolled around, and 64-bit became mandatory, many had still published 32-bit apps in the two preceding years.
In other words, most of the abandonware was made in the two years leading up to the 64-bit requirement despite ample warnings.
Now, you have me believe that they didn’t have their source code lying around somewhere? I’m sorry, but that’s just not believable.
So, the source code was available. How about the people who could do it?
Many makers of abandoned apps and games happily continued publishing new 64-bit apps and games after the transition (e.g., Capcom), so I think it’s safe to say that the people were available.
Now, what about the difficulty of porting it to 64-bit? I can’t find an authoritative source that describes it objectively, so I’ll just have to throw in my own anecdotes.
I’ve done about 15 ports for various people with apps varying from your garden variety app to some games.
As I stated above, in most cases, it was as easy as recompiling it. In a few instances, Xcode would throw up some warnings and errors, but those were all of the “you need to do this” variety, and working through them didn’t take me (a solo dev) more than a day.
Games were a little more involved in some cases because I needed to audit pointer usage and optimize memory usage, but even so, in all cases, I had a build up and running within a week.
Would all of this been harder had this been abandonware from two decades ago that nobody had touched since? Probably.
But specifically, in the case of the iOS transition to 64-bit, it mostly boiled down to “just recompile it, bro,” as you so aptly stated in part because they were, by definition, relatively recent projects.
So to me, the ones that didn’t do it didn’t bother because it wasn’t opportune to them, rather than out of a lack of ability to do it.
This is an example of the value provided by ScummVM, it means that fans are able to keep playing the games without having to deal with rightsholders who don’t want to maintain them.
Exactly, which is why if this gets any traction I believe it'll be removed. Apple does not allow you to consume your own content on their platforms without a tax or at least a little roughing up.
VLC’s doing fine. It’s how our kids watch movies on road trips (download to iPad from Jellyfin’s web interface, play in VLC).
Almost every book I’ve read in Books is from libgen. Download, open-in, and it’s on all my devices. Reading progress syncs and everything.
The best electronic comic book experience I’ve seen is from a free app (optional one-off IAP that does nothing—I wish it had higher tiers, the author is doing god’s work and I’d have given them $50 or something, no question). I put related cbr and cbz files in a directory in icloud, they show up seconds later in this app, it quickly figures out what they are (no clue how it’s as accurate as it is) and organizes them, and I get to reading two pages at a time in landscape on a 12.9” iPad.
The only Apple content I pay for is Apple Music, because it’s so damn convenient and I listen to way more music when I have it. I used to put my own music files in the exact same app, though, and that worked fine.
> The only Apple content I pay for is Apple Music, because it’s so damn convenient and I listen to way more music when I have it. I used to put my own music files in the exact same app, though, and that worked fine.
You can still do this, but you have to use a Mac or Windows PC to do so. It’ll sync your music up as part of a cloud library that exists alongside Apple’s licensed music. It’s the reason I go for their service vs. Spotify (which will let you sync music locally to their app, but doesn’t have a cloud library).
Does VLC have any extra codec support (read: software decoding) compared to what Apple makes available via APIs? I think the only thing I've noticed is webm files being playable in VLC and not when opening via the `files` app, but the vp9 codec is hardware accelerated and has been available for playback in apps for years (the YouTube app shows it in use a lot).
Can’t speak for VLC because I don’t use it that often, but other apps like Infuse support extra codecs (including vp9) beyond Apple’s offering, so AFAIK there’s no limitation on this from Apple’s side.
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.
"Possibly the most interesting thing I wrote as part of iSH is the JIT. It's not actually a JIT since it doesn't target machine code. Instead it generates an array of pointers to functions called gadgets, and each gadget ends with a tailcall to the next function; like the threaded code technique used by some Forth interpreters."
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.
Though it doesn't invalidate the gist of your saying, malloc is a user-space function not a syscall. (Its implementation will occasionally do a syscall, such as to sbrk or vmmap.)
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
This is not as cut and dry as you might think it is.
> Apps should be self-contained in their bundles, and may not read or write data outside the designated container area
This refers to the storage container each app gets, once a user loads up a script into the app, it’ll be stored within its container. So there’s no reading or writing outside its container area.
One could argue that the app itself isn’t self-contained in its bundle, but that depends on how you draw the lines. If your definition is that the app is an emulator then it’s self-contained within its bundle, if however you contend that the games you load in are to be considered part of the app and that those games are to be deemed apps then it’s not self-contained.
> nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps
There is no downloading or installing code, but there is executing code. Again, does executing this code change the features or functionality of the app? If your definition is that the app is an emulator, then no, if your definition is that when it runs these games it changes the app then yes the execution clause applies.
At face value the app, the emulator, is not changed and is self-contained, but reasonable minds can differ.
Nevertheless I don’t think the app it at risk for its functionality, rather it’s at risk for being under GPL license as per the App Store listing.
This is because Apple doesn’t allow GPL licensed apps on their App Store courtesy of the FSF[0] who tried to force Apple to change their App Store terms with a gambit by submitting an app licensed under GPL, to then turn around and complain that Apple’s App Store doesn’t comply with the GPL license by virtue of not distributing the app without DRM and other restrictions.
Apple’s response of course was to simply remove the app in question and adopt a silent policy of not allowing GPL apps (and other apps with a license that collides with the App Store ToS and license).
Yeah, ScummVM runs the original game scripts, doesn't it? And the original games aren't bundled with it (they can't be). Kind of surprising they got away with violating that rule.
ScummVM explicitly denies being any kind of emulator.
It doesn't run the original source code of the games. Rather, it's a complete rewrite of the game that uses the original assets (images, sounds, internal scripts, etc.)
Yes, but those games contain scripting languages, like Lua for Grim/Escape from Monkey Island. That isn't shipped with the app, so it technically violates the rule. Hope they keep it up though, or if not, hope they get their ass kicked into allowing third-party app stores soon so that you don't need to jump through massive hoops to use anything like this.
My 5 year old sons favourite app on his Android tablet is ScummVM.
I bought all the Putt Putt, Freddy Fish, and Spy Fox games on Steam, and after copying the data files over to ScummVM on Android, my son has been enjoying them a lot.
I'd much prefer him spending his time with these rather than these toxic mobile games that target young kids with repetitive loops locked behind countdown timers and in app purchases.
I replayed all the Spy Fox games on my steam deck a few months ago, so much fun. Point and click isn’t great on the deck but it was manageable and the nostalgia made up for it.
They are also sold as games on the App Store, but I think they use an older version of ScummVM and it was really broken for us.
I am hoping some more iOS improvements/fixes could be done. These games are amazing (still are very funny to my 4yo!). I would like to see a bigger touch area and proper touch dragging support.
While I also think they don't make games like these anymore nowadays. Please comment below with examples to proof us wrong.
Gog is ideal. I own several of them, and if you are patient, they run great sales throughout the year making them very cheap to obtain (and there isn't any DRM).
To add to this, the commercially available versions of the first two Monkey Island games are not ScummVM compatible without some hackery. The games are perfectly playable, indeed, but a lot of people don't have much fondness for the visual style choices.
Luckily, the original game data files are included in the homogeneous .pak files for the games, and Monkey Island Explorer[0] can unpack them.
For both games the files are MONKEY.000 and MONKEY.001 (MONKEY2.00{0,1} for Monkey 2) and the explorer program can filter for file types making it easy. Just unpack them, add to ScummVM and away you go.
Caveat is that these are the CD versions of the games. The Secret of Monkey Island was actually "remastered" previously! The colour palette is altered slightly and the UI includes an updated inventory, with images instead of just words for items. The stump joke is removed, too (partly due to the LucasArts hintline getting calls about a missing disk #131!).
Monkey Island Ultimate Talkie Edition[1] is another project that can extract the data from the Special Editions, as well as the music and voice files. The resulting build is compatible with ScummVM, meaning you can play the original games with the updated audio.
The kids are playing Freddy Fish and Pyjama Sam on the iPad right now. Good stuff! There is just no modern equivalent of these games that let's kids puzzle like this!
but hm, that category is larger than the category of supported games ... clicking through to the "where to get" link gives a more curated list.
There are 4 shipped in most Linux distros (probably more a matter of exact license than quality alone):
Flight of the Amazon Queen - everything you'd expect from a fantasy adventure; play this if nothing else
Beneath a Steel Sky - a good game, just not a happy one
Lure of the Temptress - this was buggy when I played it, managing to crash/freeze the VM
Drascula: The Vampire Strikes Back - cringe
For anyone who cares about legality, do not touch Internet Archive (archive.org) with a 10 foot pole. That place is one of the biggest collections of warez known to man today.
Just note that abandonware is not a legal term, and the ScummVM team consider it piracy/warez. You don't get supported with problems by ScummVM if you play an illegitimately acquired copy of a game.
There ARE some games which are released by the original developers for free. Beneath a Steel Sky can even be found in the Debian and Arch repositories, for example.
"ScummVM is a program which allows you to run certain classic graphical adventure and role-playing games, provided you already have their data files. The clever part about this: ScummVM just replaces the executables shipped with the games, allowing you to play them on systems for which they were never designed! ScummVM is a complete rewrite of these games' executables and is not an emulator.
ScummVM supports an extensive library of over 325 adventure games, including classic titles from iconic studios such as LucasArts, Sierra On-Line, Revolution Software, Cyan, Inc. and Westwood Studios. Alongside groundbreaking games like the Monkey Island series, Broken Sword, Myst, Blade Runner and numerous well-known titles, you can experience truly obscure adventures and discover hidden gems."
For those (like me) who didn't know what ScummVM was.
DREAMM is a pretty significant project, and differs from ScummVM in a few ways. Primarily, ScummVM is an engine rewrite. They write new code that copies the behaviour of the original games.
Aaron Giles worked at LucasArts and was instrumental in porting SCUMM to Windows (for Full Throttle and Curse of Monkey Island). DREAMM is a full x86 emulator that takes the original game code and runs it directly.[0]
Amusingly enough, I guess that makes DREAMM more of a virtual machine than ScummVM is.
ScummVM 2.8.0 is a pretty big release overall, with the App Store release just being the icing on the cake. The full notes are pretty long![0]
The list of supported games has grown a lot. ScummVM is capable of running the Adibou series now, as well as the first Might & Magic game and Muppet Treasure Island!
A hefty review of the Broken Sword engine has also restored a lot of small missing features.
If you have even a passing interest in classic adventure games, you owe it to yourself to check it out.
Is there a way to load games directly on mobile without using a cloud storage provider?
There a bunch of freely downloaded games on the ScummVM page here [0]. I can download a zip file in mobile but I can’t figure out how to get it into the app.
I’d say it’s curious it happened at all. As others have mentioned Apple doesn’t allow emulators at all in their store, perhaps they are afraid of losing too much of the market after EU forces them to allow side-loading?
EDIT: I just checked the App Store listing for this app - I find it pretty hilarious (and for more than one reason) that it’s listed in the Adventure category which has a pirate flag for an icon.
I understand that new app launches need approval by someone who actually knows the rules, whereas new updates for already-published apps are run-by the rank-and-file reviewers.
I stand corrected, although from a policy-making perspective ScummVM allows users to run software acquired through ways not sanctioned by Apple (or owners of the original IPs), which I believe is the major part of why emulators are not allowed on App Store and thus bears a similarity to them in that particular aspect.
Apple controls the JS sandbox in Safari, whereas they don’t control the ScummVM scripting sandbox. In theory it’d allow the execution of arbitrary scripts that can do anything native code can do, although I don’t know - maybe ScummVM checksums the games you load into it and will only run code it recognizes (and if so, maybe that’s why it’s allowed).
Isn't Apple very restrictive about apps that allow running arbitrary code like emulators? I'm also a bit perplexed, unless they have changed their policy recently.
That one runs WASM binaries interfacing (via WASI) with the native iOS AArch64 environment and some clever built-in bindings that make iOS look not entirely unlike a normal POSIX.
Very impressive (and faster than emulation, since WASM can be JIT compiled by iOS!), but not Linux :)
I wonder if it was determined that the code isn’t arbitrary, and nothing is being emulated. It’s more like a content engine.
Perhaps ScummVM is closer in concept to something like Super Mario Maker than to a full blown programming environment. You could argue that the custom content is “code” but it’s more like a limited set of actions accompanied with content.
Yes, but those game engines are - on iOS especially - locked in to running bundled scripts that drive the specific game you’ve purchased from the App Store. ScummVM is running externally provided scripts.
hmmm I suspect this is because it is GPLv2 which doesn't require the freedom to RUN the program (which apple doesn't give you)
apple seems to ship software with gplv2 (old bash, etc) but no GPLv3 software.
...even though they are technically in violation of the GPL by modifying and shipping bash binaries without full source - it is missing rootless.h (not the X11 file)
> GPLv2 which doesn't require the freedom to RUN the program
It does. This is the first freedom of free software. I'm not sure the issues with distributing GPL software on the App store are specific to the GPLv3. I don't fully understand things on this, but [1] seems to be a good entry point.
> apple seems to ship software with gplv2 (old bash, etc) but no GPLv3 software.
This is an Apple policy / a choice that they make. They could decide to distribute GPLv3 software with Mac legally, but chose not to.
> by modifying and shipping bash binaries without full source - it is missing rootless.h (not the X11 file)
I would be interested in knowing more about this. I'm surprised they've not been already sued if they violate bash's license.
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 a loophole to fix by the FSF.
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.
From what I remember, GPLv3 is simply a clarification of GPLv2, the intent was always the same for all the purposes. But how lawyers see it could be another matter.
Q: do you agree that you undermine GPL version 3 and how can I get you to stop
Linus: what
Q: how can we get you to stop
Linus: oh I hate GPL version 3 undermined it on purpose I actually thought the GPL version 3 extensions were horrible. I understand why people would want to do them but I think it should have been a completely new license. My argument for liking version 2 - and I still think version 2 is a great license - was that I give you source code you give me your changes back we're even. Right - that's that's my take on GPL version 2 it's that simple and version 3 extended that in ways that I personally am really uncomfortable with; namely I give you source code that means that if you use that source code you can't use it on your device unless you follow my rules and to me that's that's a violation of everything version 2 stood for ...
Funny because RMS has said you can USE the software for any purpose. It's just that when you redistribute it you have to pass on the rights you received along.
Opening up the 'COPYING' file from that distribution:
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Apple is scrupulous at ensuring that they only distribute GPL Version 2 software, if at all (they've made efforts to switch to using BSD licensed software wherever possible).
There's no reason for bash people or FSF to sue Apple as they are strictly following the license.
Apple’s violation of GPL has nothing to do with which version they’re using and everything to do with failing to provide source code promptly that matches the OS they’re shipping.
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.
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.
Bash is part of the GNU project. As a consequence, I believe contributors assign their copyright to the FSF. I downloaded a random release of bash 3 (3.0.16) and opened a random C file from it and it is indeed "Copyright (C) 1993-2004 Free Software Foundation, Inc."
I appreciate that individual developers might not have the time & energy to engage in a lawsuit against Apple, but the FSF is bigger, and has all the incentive to be firm with the terms of the GPL licenses for the licenses to look strong. Developers can also certainly request help from the Software Freedom Conservancy [1] or the Software Freedom Law Center [2] (which has helped BusyBox win several lawsuits) for this kind of stuff. Apparently the SFLC has helped the FSF in the past, against Cisco, if I'm to believe [2].
GPLv3’s anti-Tivoization clause specifically targets software bundled with a device, which this is not. There’s plenty of GPLv3 software distributed by its developers on the App Store and nothing in the text of the GPL forbids distribution in a proprietary marketplace.
hmmm. I thought that software loaded on an apple device is DRM'd, meaning it cannot be installed or run without an apple id (basically you must ask apple permission to run the program).
GPLv2 didn't prevent this, but I thought GPLv3 conferred additional rights to the user.
I remember RMS saying, "I realized I had to explicitly say the freedom to RUN the program" I believe about revising GPLv2 to GPLv3
What doesn't make sense? They don't want AGPL code to accidentally end up anywhere that's publicly accessible, and a lot of the code in their monolith is used across many different products, so a blanket ban seems entirely reasonable.
What motivation do you think they have to lie about this?
Not speaking about code, they ban use of AGPL software. This does not make sense to me.
Software you use does not magically [1] end up in your code base, or you are doing something horribly wrong, I can't even begin to imagine how. Like, "Whoops, I downloaded and executed this AGPL-licensed binary, and now this Google process running on my laptop (or phone!) has automatically fetched its source code and put it to prod and linked it to our software, and now oh no, all our code are belong to GNU!". This is ridiculous. This is some massive, solid bullshit we have here.
You can use AGPL software for any purpose within the law, no strings attached. You never need to touch the code, and if you do, you never need to link your product to it. It does not take a lawyer to understand this simple concept. Proprietary software have more restrictions than that, you'd better not have third party proprietary code ending up in your product, although it's not banned at Google. I hope they do check license compliance on their code base anyway, there are automatic scanners for this. So the chances of some AGPL code ending in their repositories seem vanishingly small.
As for why Google would be dishonest, of course we have no proof and we can't know for sure AFAIK. By default I side with Drew DeVault [2], to me this is anti-AGPL propaganda and their goal is to discourage people from licensing their software under AGPL so they have a bigger pool of open source projects they can potentially reuse without having to contribute back, and it works because now people are afraid to license their stuff under AGPL because "businesses" "often" have an AGPL ban. I know of exactly two companies banning AGPL: Google and Apple. Apple already did that with GPLv3 (AGPLv3 being GPLv3 + a clause). Again, does please the big company (and come on, outdated bash and GNU tools on Mac does not make any kind of sense, the GPL never restricted stuff at the process level interface). I'm sure there are smaller businesses thinking that if Google and Apple ban those licenses, they must be bad and they should do too to be safe, while not having a business model where it even makes sense, playing Google and Apple's game.
If I'm to license software under AGPL, I'm giving Google the right to use this software. That they don't want to use it is their loss. They are doing this to themselves.
> they want to discourage people from using the AGPL, because they cannot productize such software effectively [...]
> By discouraging the use of AGPL in the broader community, Google hopes to create a larger set of free- and open-source software that they can take for their own needs without any obligations to upstream
> ...even though they are technically in violation of the GPL by modifying and shipping bash binaries without full source - it is missing rootless.h (not the X11 file)
They're not.
They've covered this in two main ways:
1) By listing all their source code on https://opensource.apple.com/ (which links to their GitHub with all the source code)
2) By offering a complete machine-readable copy of the source code upon request as per GPLv2 (3)(b). This offer is made both in the license agreement[0] you agree to when booting up your Mac for the first time, updating it, etc., as well as in an Acknowledgements.rtf[1] file that is located on your drive at multiple locations (e.g., /Library/Documentation) and linked to from within certain apps (e.g., about section, acknowledgment section under Help, EULA agreement prompt, etc.).
That covers the bash part. rootless.h isn't part of bash and is part of libSystem.dylib, so that would fall under the OS exception in GPLv2[2]:
> However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
That said, it probably won't be long before they stop shipping bash altogether, they've already switched to Zsh a while ago and seem to have moved to a "bring your own tool" philosophy for anything they don't support by default (see Python removal and future Ruby and Perl removal notice).
It's been a hot minute since I had to dig into the code Apple publishes for anything and since then they seem to have moved it all to Github. I don't have my mac handy to try building it, but I don't see any references to a rootless.h in the code they're publishing. I'm curious to know a bit more about what's missing.
That would be perfectly legal under the GPL, right?
It doesn't say you're not allowed to modify the code, just that you have to distribute the modified code in its entirety. If what Apple is distributing is sufficient to build (their version of) bash, it's perfectly fine.
If the code is what Apple used to build what they're distributing, then yes this is valid. (For this case at least, they have a tendency of doing this a lot and I suspect the change to bash was made just to address this specific complaint while missing every other place they strip out code.)
I tried to rebuild bash a while back on macos and couldn't do it because the source code was not available for rootless.h. I guess someones complaint finally got some action from apple.
I remember doing macos kernel debugging (in the non-gpl code apple distributes) and it was pretty evident that the code they distribute like xnu is NOT the code that is in the OS. Stack traces had lots of functions apple keeps to itself. Looking in the distributed code shows suspicious blank lines where automated tools must remove apple-only source.
Many people need more clarification about how this passed App Review, and some are bringing up 2.5.2 of the guidelines.
This doesn't meet the 2.5.2 prohibition for reasons explained elsewhere[0], and it shows a misunderstanding about which guidelines prevent commonly desired emulators.
Emulators are generally barred mainly under the intellectual property guidelines[1] in §5.2 because most emulators require copyrighted bios files to run. Some other emulators were yanked after a DMCA request, and again, others were yanked because they were disguised as other apps.
ScummVM doesn't suffer from these issues at face value, but their more significant problem is that they're licensed under GPLv3, and Apple has an unofficial policy of not allowing GPL(v3) on the App Store thanks to a gambit the FSF[2] tried to pull that blew up in their face.
They tried to force Apple to change their App Store terms by submitting an app licensed under GPL, then turned around and complained that Apple’s App Store doesn’t comply with the GPL license because it does not distribute the app without DRM and other restrictions.
Apple’s response was to remove the app and adopt a silent policy of not allowing GPL apps (and other apps with a license that collides with the App Store ToS and license).
For those who don't recognize Scumm (since it's getting pretty old now...), it was an adventure game engine. Widely used for classic Lucasfilm Games/LucasArts titles. (edit fixed! See below comment)
I’ve often pondered this and I have concluded that there are a number of factors:
1. Licensing. While it might appear that the Indiana Jones IP is fully in the hands of Disney, it’s plausible that there are nuances behind the scenes. For example, Paramount owns the distribution rights to the first four films. That’s a different issue, but I mention it as an example of how rights can become fragmented over time over multiple contracts. I wouldn’t be at all surprised if the rights to Fate of Atlantis are more complex than we see from the outside. Having said that, I’ve no evidence of this.
2. It was a good game, but does that make for a good movie? FoA had some great game features: multiple paths, fun puzzles, classic adventure game exploration and interactivity, awesome pixel art - but none of these are useful to a movie.
3. The script was… OK. It doesn’t have any standout quotable lines like the first three films did. Its comedy is more slapstick than witty, and there are more than a few video-game in-jokes. It’s also highly derivative, written, I suspect, to make players think “This is cinematic! This is just like a real Indiana Jones movie!” To that end, it worked brilliantly. But in the 90s, games were still a sideshow compared to Hollywood, and were written in a parodic style, not yet having found their own space as a unique medium. To an extent, this is still true today.
4. An aging Harrison Ford is tough to reconcile with a story set in the 1930s. I expect this alone was a big driver in the studio wanting new scripts set in the 50s and 60s for the last two films.
5. Movies based on games have an abysmal track record, and I’m sure Hollywood producers get an allergic reaction whenever someone suggests another one.
And yet, despite all the above, FoA is still fantastic raw material for a movie. The plot, mythology, locations, set-pieces, and even the music, are all perfect for being reimagined on the big screen. Which leads me to the final reason why I think it hasn’t happened:
5. Nobody took games seriously in the 90s, Lucas was in control in the 00s for Crystal Skull and wanted his own story not somebody else’s, Disney was distracted by Star Wars and Marvel in the 10s, and by the time we get to Dial of Destiny in the 20s, Disney has become so risk averse that the idea of pulling ideas from a video game seems far outside what they are creatively capable of. Sadly, with Dial of Destiny bombing, the franchise is probably dead until the 30s.
Still, the fact that Disney lawyers shut down the recent fan-remastered version of the FoA game gives me hope that they still recognize how much value that IP has. They’ve strip-mined every other IP, so it’s possible they will eventually realize they've been digging in the wrong place, let go of Harrison Ford (in either live, de-aged, or posthumous generative form), and get their top men working on it.
To pedantically correct a thing you said, SCUMM (Script Creation Utility for Maniac Mansion) was an adventure game engine, and was used for early LucasArts titles (absolutely no Sierra games!).
ScummVM is a program that bundles a lot of reimplementations of different game engines together, such that you can play pretty much any game in the "point and click adventure" category from the late 80s through early 2000s on modern platforms so long as you provide the data-files for it yourself. As you might guess from the name, some scope creep has happened since its origin.
IIRC, some time ago I purchased The Secret of Monkey Island from GOG, and discovered it actually packages ScummVM.
I wonder if they "give back" to the community somehow.
This is fantastic. I consider iOS far superior in so many ways over Android. Except that it is locked down so much. If iOS becomes more open, there will be nearly no reason to get an Android.
> Android rules except in one aspect - battery life.
This is like saying Windows is better than Linux for battery life, which is obviously ridiculous because it's primarily about the hardware, not software. Put Android on Apple's excellent silicon and watch how suddenly "Android" has really good battery life.
Anyway, both are disgusting passive consumption oriented walled gardens, and phones in general are terrible computers as software goes.
Locked downness is a non issue coming from a previous android fanboy. iOS is just superior in every way. No I don’t care that you can change some font on your android phone.
I can swipe to go back on either side on Android, while on iPhones the 2 options is a swipe from the left or a button ON THE TOP LEFT OF THE SCREEN usually. With my right hand, even going back one page in the settings app is a chore on small iPhones, while being comfortable on even the largest Android phones. Who thought this was a good idea? So much of the common requires uncomfortable gestures / button presses.
Agree with all of this.
Apps are so much better on iOS. I have been on Android since the G1, but switched to iPhone with the 14 Pro Max.
Here were the apps I switched to using when moving over to iOS. I consider every switch superior on iOS vs what I was using on Android.
JuiceSSH: ShellFish
OneTracker: Parcel
Smart AudioBook Player: Prologue
Plex client: Infuse is superior to Plex and direct-plays everything
MX Player: Infuse replaces MX Player for local playback too
Plex Dash: Varys (Plex Dash is also available on iOS, but Varys is superior)
Embiggen: Big
Markor: 1Writer
RealCalc: RPN 30
Overdrop: Apple Weather
Shredder Chess: Hiarcs & Shredder Chess.
SwiftScan: ScanPro (I use this to scan work receipts)
Todo app - Things (and Superlist)
What is the appeal with games that are this old? Is the audience people that played them in their childhood? I struggle to see kids (who are used to super colourful, hyper interactive, animated games) play GBC games let alone something like this. Any ideas?
To turn it around on you: what's wrong with old games? Does anyone ask the same about books?:
"What is the appeal with books that are this old?"
Not very often from what I can tell. I do see the sentiment you've expressed regarding games much more often. Why is that? I'm not sure. Perhaps it's just a sign of the immaturity of games as a medium (compared to books, anyway).
There's a lot of user interface issues in playing an older game. Not so much the graphics -- people like "pixel" styling in modern games, though generally at much higher resolutions and with better color palettes than in old games -- but rather in how you interact with the games.
There's a lot of experimentation in old games about how to approach certain concepts, where eventually something won out and became the way we do it. So it's very strange to go back to e.g. an old first-person game and realize that WASD controls aren't used.
I recently saw this YouTube video ("How System Shock's Reboot Wrestles With Adapting Its Legacy" by Errant Signal) that talks a bit about this take on the issue, which might interest you: https://www.youtube.com/watch?v=YDQ24iAkh90
Well, technology has progressed quite far while humans are still humans with the same (but slightly better maintained) brain. I have a hard time watching old movies where the FX is crap
And many of us who like practical effects feel the opposite. If a movie hasn’t engaged you enough to see past the puppet, makeup, and rigging, there’s probably something else missing.
A lot of the audience probably is the nostalgic. But also, there's quite a few genuinely good games in there, and also some very foundational ones. The tendency towards cartoony graphics and a plot/humor focus means that in some ways they've aged a lot better than other games from a similar era.
In a way it's like asking why people read old fashioned novels, even though they're out of step with modern language and culture.
While I don’t share the sentiment, I have an anecdote that might be relatable.
Some time around 2014 I finally got around to playing Castlevania: symphony of the Night. It was almost 20 years old, casykevania had long since moved to 3D graphics and stages. Even when it was released in the 90s it could have been considered outdated due to its small, sprite-based graphics.
It turns out, the game is a masterpiece. The control, the level design, the progression, the exploration, the freedom of item choice are all exceptional. Even the graphics are beautiful for what they are without needing a RTX 4090 and 4K display. I’ve replayed it several times since then and it opened up a new genre of games that I hadn’t previously considered liking.
Many of the Lucas Arts point and click adventures may or may not soar the same interest. They’re quirky, funny, clever games that can be played casually.
For kids who like games, the gameplay is enough. They might say how dopey it looks at the start, but if it hooks them, that reaction will fade away.
I'd be surprised if many youngsters would seek these out themselves but nostalgia drives many people and they're likely to push younger people to try this out.
