ScummVM on the App Store(apps.apple.com) |
ScummVM on the App Store(apps.apple.com) |
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.
There really should be a "full backup" option.
For good or bad, they are flexible - and that is frustrating at times trying to get Apps approved.
That means 'no'.
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.
https://developer.apple.com/app-store/review/guidelines/#phy...
> 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).
0: https://www.fsf.org/blogs/licensing/more-about-the-app-store...
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.)
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 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.
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.
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.
On the other hand it only does LucasArts games so you need both DREAMM and ScummVM.
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.
[0]: https://downloads.scummvm.org/frs/scummvm/2.8.0/ReleaseNotes...
ScummVM - https://news.ycombinator.com/item?id=33701378 - Nov 2022 (2 comments)
ScummVM 2.5 “Twenty years ago today” - https://news.ycombinator.com/item?id=28812403 - Oct 2021 (43 comments)
ScummVM “Interactive Fantasy” 2.2.0 Sees the Light - https://news.ycombinator.com/item?id=24619533 - Sept 2020 (52 comments)
ScummVM 2.1.0 - https://news.ycombinator.com/item?id=21231840 - Oct 2019 (38 comments)
ScummVM 2.0 released - https://news.ycombinator.com/item?id=15946692 - Dec 2017 (31 comments)
ScummVM ported to HTML5 - play old games in your browser - https://news.ycombinator.com/item?id=5861429 - June 2013 (34 comments)
Maniac Tentacle Mindbenders: ScummVM's unpaid coders keep adventure gaming alive - https://news.ycombinator.com/item?id=3508909 - Jan 2012 (7 comments)
GPL, ScummVM and violations - https://news.ycombinator.com/item?id=2108237 - Jan 2011 (11 comments)
Atari violates the ScummVM's license - https://news.ycombinator.com/item?id=675418 - June 2009 (11 comments)
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.
1. In mobile Safari, tap the file to download and tap ok
2. When it’s finished, tap the blue circle with a down arrow next to the address bar to open downloads
3. Tap the file you just downloaded to switch to the Files app
4. In the Files app, tap the zip file you just downloaded to uncompress it
5. Tap and hold the directory and select “Move”
6. Navigate to or search for the “ScummVM” folder
7. Tap “Move” in the upper right hand corner
Now the game should show up in the file browser within ScummVM to be added
1. In the ScummVM launcher, tap “Add Game”
2. Select the folder and tap “Choose”
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.
It seems like the current bar is something like “can it plausibly run something other than pirated Nintendo ROMs”.
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.
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)
I remember fondly replaying Monkey Island on my Linux machine thanks to it.
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).
0: https://news.ycombinator.com/item?id=38826426
1: https://developer.apple.com/app-store/review/guidelines/#int...
2: https://www.fsf.org/blogs/licensing/more-about-the-app-store...
Here's the list of supported games: https://wiki.scummvm.org/index.php?title=Category:Supported_...
If you're looking for recommendations...
- Zork (the OG, and sequels): https://wiki.scummvm.org/index.php?title=Zork
- Beneath a Steel Sky: https://wiki.scummvm.org/index.php?title=Beneath_a_Steel_Sky
- Blade Runner: https://wiki.scummvm.org/index.php?title=Blade_Runner
- The Castle of Dr. Brain (and sequels): https://wiki.scummvm.org/index.php?title=Castle_of_Dr._Brain
- Maniac Mansion / Day of the Tentacle: https://wiki.scummvm.org/index.php?title=Maniac_Mansion https://wiki.scummvm.org/index.php?title=Day_of_the_Tentacle
- The Dig: https://wiki.scummvm.org/index.php?title=The_Dig
- Full Throttle: https://wiki.scummvm.org/index.php?title=Full_Throttle
- Gabriel Knight (and sequels): https://wiki.scummvm.org/index.php?title=Gabriel_Knight
- Grim Fandango: https://wiki.scummvm.org/index.php?title=Grim_Fandango
- Indiana Jones and the Fate of Atlantis: https://wiki.scummvm.org/index.php?title=Indiana_Jones_and_t...
- Kings Quest (and sequels): https://wiki.scummvm.org/index.php?title=King%27s_Quest
- Leather Goddesses from Phobos (and sequel): https://wiki.scummvm.org/index.php?title=Leather_Goddesses_o...
- Leisure Suit Larry (and sequels): https://wiki.scummvm.org/index.php?title=Leisure_Suit_Larry
- The Longest Journey: https://wiki.scummvm.org/index.php?title=The_Longest_Journey
- Police Quest (and sequels): https://wiki.scummvm.org/index.php?title=Police_Quest
- Riven: The Sequel to Myst: https://wiki.scummvm.org/index.php?title=Riven:_The_Sequel_t...
- Sam and Max Hit the Road: https://wiki.scummvm.org/index.php?title=Sam_%26_Max_Hit_the...
- The Secret of Monkey Island (and sequels): https://wiki.scummvm.org/index.php?title=The_Secret_of_Monke...
- Space Quest: https://wiki.scummvm.org/index.php?title=Space_Quest
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.
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.
[0]: https://quickandeasysoftware.net/software/monkey-island-expl...
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 - cringeYep, they were freewared.
> quality
I have the experience with Flight and Steel Sky only, but they are good.
And archive.org some of the games are abandonware and free.
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.
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.
[1] https://opensource.stackexchange.com/questions/9500/is-apple...
I don't think so:
The Free Software Foundation explicitly forbade tivoization in version 3 of the GNU General Public License.
https://en.wikipedia.org/wiki/Tivoization
I think this is one of the reasons GPLv3 came along.
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
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).
0: https://www.apple.com/legal/sla/docs/macOSSonoma.pdf (see §15)
1: https://opensource.apple.com/source/files/files-553/Library/...
2: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
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.
FM/YI, here's the mapping of games to engines: https://wiki.scummvm.org/index.php?title=Engines
Apparently the Sierra engines were AGI and then SCI. https://wiki.scummvm.org/index.php?title=AGI https://wiki.scummvm.org/index.php?title=SCI
"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 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
Games are entertainment. So they are supposed to have higher levels of engagement over time
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.
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 have a hard time finding the appeal for myself.
It doesn’t have to be all about high-end graphics.
Plot, game play, fun is what’s most important for a large segment of gamers.
I would argue the age of a game is entirely orthogonal to whether it is possible to still enjoy playing it.
Will EVERYONE enjoy playing it? Probably not. But some people do. And that's enough to give projects like ScummVM a valuable purpose.
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.
Very impressive (and faster than emulation, since WASM can be JIT compiled by iOS!), but not Linux :)
"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."
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.
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).
Looks like it’s Chunky:
https://apps.apple.com/us/app/chunky-comic-reader/id66356762...
shagie@Mac-Pro ~ % bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin23)
Copyright (C) 2007 Free Software Foundation, Inc.
https://ftp.gnu.org/gnu/bash/ has version 3.2.57.
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.
There's no reason for bash people or FSF to sue Apple as they are strictly following the license.
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].
[1] https://sfconservancy.org/
[2] https://en.wikipedia.org/wiki/Software_Freedom_Law_Center
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.
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.
Security
Updates for even ancient phones
Massively integrated ecosystem
Higher quality apps, even googles own
Best hardware
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)Their reasons (their excuses? At this point I'm not convinced at all) to ban AGPL are documented at [1].
[1] https://opensource.google/documentation/reference/using/agpl...
What motivation do you think they have to lie about this?
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.
[1] https://en.wikipedia.org/wiki/Magical_thinking
[2] https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
> 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
And yes, tivoization is a major reason why GPLv3 was written indeed, it was seen as a loophole to fix by the FSF.
---
Linus Torvalds says GPL v3 violates everything that GPLv2 stood for - https://youtu.be/PaKIZ7gJlRU
The start of the video:
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 ...
AppStore apps themselves are sandboxed too. You can’t execute all arbitrary code just because it’s an app.
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.
(Of course the problem is that it's damn hard to run old versions of iOS under emulation. That's the solution that would appease me)
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.
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.
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.
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.
Especially considering that most of it already is a translation layer for the Windows Registry.
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.
> 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.
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.