paperplane

joined 2 years ago
[–] paperplane@lemmy.world 2 points 7 hours ago

To be fair, even with 3G networks being decommissioned, many countries still have 2G networks up and running to support older phones. Data speeds are usually way to slow to be useable, but for text messages it might work.

[–] paperplane@lemmy.world 2 points 7 hours ago

By the way, it looks like someone already did this (though for iOS 6): https://chatgptlegacy.com/

The app seems to be open-source too: https://github.com/bag-xml/ChatGPT-for-Legacy-iOS

[–] paperplane@lemmy.world 2 points 7 hours ago (1 children)

Don't think it would be impossible to make an app for both iOS 3 and 26. You wouldn't be able to make it binary-compatible due to different architectures, but you might be able to use the same source code to target both OSes. You'd have to use a very old Xcode version to target iOS 3, since deployment targets this old generally aren't really supported by recent Xcode versions, and you wouldn't be able to submit that version to the App Store. Naturally you'd have to limit yourself to some subset of UIKit APIs supported back then (that hasn't been deprecated and removed). But if done right, you should be able to open up the project with a recent Xcode, hit build and run it on iOS 26.

[–] paperplane@lemmy.world 3 points 2 weeks ago* (last edited 2 weeks ago)

Arguably mapping out cities to this degree across the globe is a ginormous effort, on an order of magnitude more so than what Google Maps etc. currently provide. Thus I don't think it's entirely unreasonable to try designing something that operates purely in terms of sensory input (and of course map data where available, those approaches don't have to be mutually exclusive).

[–] paperplane@lemmy.world 2 points 2 months ago (1 children)

What I mean is that you (IIUC) can't use an AGPL library in a GPL app without relicensing the whole thing to AGPL. For many larger projects relicensing is a huge hassle and often a non-starter if there aren't very good reasons for it.

[–] paperplane@lemmy.world 1 points 2 months ago (1 children)

"just don't enforce it" probably isn't enough for most companies and projects

[–] paperplane@lemmy.world 10 points 2 months ago (8 children)

A good reason to pick GPL is if you want to allow GPL software to integrate yours and you don't care that much about the AGPL clauses (e.g. because your app isn't a server).

CC0 might be a good fit for trivial template repos where you don't want to burden downstream projects with having to include copyright notices.

[–] paperplane@lemmy.world 4 points 2 months ago (1 children)

Also the iOS SDK isn't freely available, so you'd have to copy that out of an Xcode installation... but given enough time and effort, you could almost certainly hack together a cross-compilation config for Clang that compiles an unsigned iOS app on Linux. Signing it might in fact be the bigger issue, since I'm not aware of any tools that sign Mach-O binaries on Linux.

[–] paperplane@lemmy.world 2 points 2 months ago

Should also be noted that macOS does support Bluetooth File Transfer natively, so they did already implement it elsewhere.

[–] paperplane@lemmy.world 4 points 3 months ago (1 children)

Having the ability to overload functions or constructors without a million Stuff::with_x variants is something I consider more ergonomic and not unsafe. I know the Rust community prefers explicitness in many places, but explicitness and safety are somewhat orthogonal in language design. I consider e.g. Swift to be a safe and ergonomic/sugared language, that borrows, no pun intended, a lot of ideas from Rust

[–] paperplane@lemmy.world 6 points 3 months ago (3 children)

As long as you limit yourself to a subset of modern C++, it's actually a decent language. Less guardrails than Rust, but more syntactic sugar (think overloading, default parameters, implicit this, implicit reference-taking, implicit conversions). You could argue those are anti-features, but even as someone who really likes Rust, I gotta admit C++ is occasionally more ergonomic.

view more: next ›