I think I would find it very challenging but fun. Certainly more fun than writing a date/time library (way more inconsistent cases; daylight savings time horrors; leap seconds; date jumps when moving from Julian to Gregorian) or a file system (also fun, I think, but thoroughly testing it scares me of)
FTA: “The update text is appearing on apps that have not been updated in some time, as well as apps that received recent updates, so it's not clear what the apps have in common.”
⇒ I think that’s unlikely. If some optimization got broken that produces results that bad that it has to be fixed, users would have noticed in those apps that “have not been updated in some time”.
I don’t think that’s a valid comparison. It compares two entirely different cases.
In general, if the guts of Foo are similar to those of Bar, translating Foo to Bar is fairly easy.
If Foo has additional guts, as in the C++-to-ℂ translator, translating those parts can lead to hard to read code.
In the C-to-D translator case, it’s not Foo that has additional guts, though, but Bar.
Then, a reasonable 1:1 transaction is easy. Doing it in idiomatic style can still be hard, though. For example D has garbage collection, classes and inheritance. I doubt the readily translation of C to D will replace C equivalents (e.g. a garbage collector written in C that’s part of the code) by those where possible.
It's true that D has many features that are not part of C, and a translator from C to D will not recognize constructions in C meant to exhibit inheritance. It's also true that a C to D translator will not be able to translate metaprogramming done with the C preprocessor.
It is a valid comparison, though, as there is no point to designing a language that has a 1:1 mapping to/from C.
> What has changed? Why do I need 10x the RAM to open a handful of terminals and a text editor?
It’s not a factor of ten, but a 4K monitor has about four times as many pixels. Cached font bitmaps scale with that, photos take more memory, etc.
> When Windows 2000 came out
In those times, when part of a window became uncovered, the OS would ask the application to redraw that part. Nowadays, the OS knows what’s there because it keeps the pixels around, so it can bitblit the pixels in.
Again, not a factor of ten, but it contributes.
The number of background processes likely also increased, and chances are you used to run fewer applications at the same time. Your handful of terminals may be a bit fuller now than it was back then.
Neither of those really explain why you need gigabytes of RAM nowadays, though, but they didn’t explain why Windows 2000 needed whatever it needed at its time, either.
The main real reason is “because we can afford to”.
No — web fonts bypass the Preferences mechanism entirely, which means you lose the cross-site persistence that makes Step 1 valuable. A web font attack is a different chain (CSS injection → malicious @font-face → GSUB) with a different threat model and narrower scope. P.S. Sorry I missed this earlier — thanks for the comment, really appreciated it!
> I still think it’s ridiculous that Apple never solved for this.
I think that problem, in general, is unsolvable on the Mac. The OS cannot know whether a file that an application creates is a user file that should be kept on uninstall or an application one that, maybe, should be deleted on uninstall.
(Maybe because Apple’s guidelines say (or at least used to say) uninstall ers, if you have one, should keep preferences files around, in case a user reinstalls the app later. Also, applications may ship with files (e.g. fonts, sounds, picture libraries) that users may want to keep around)
> For app that just get dragged into the Applications folder, they end up doing all this additional file creation on first-launch instead of via an installer
For quite a few things that an installer can install, applications cannot do that, as they want to install them into protected directories.
I think most of the leftovers whose locations you cannot gauge from looking at the file list in the installer are for caches, preferences, logs, etc.
Yeah, it's usually plist files for preferences and maybe an Application Support folder with whatever the app needed. Occasionally some other things. More recent apps end up with a container in there.
The upgrades process for some apps almost necessitates that the those files/folders are decoupled from the app and can live on, as the app upgrade ends up deleting the existing app and dropping a new one in it's place.
I get wanting to keep user preferences around in spirit, but in practice keeping them forever can sometimes be problematic. If I tried an app, then installed it again in 8 years. I usually want to start over. For users who don't know about the ~/Library, this is hard. Especially now that Apple hides it in Finder.
When having issues with an app, deleting those files (or simply moving them somewhere else like the desktop as a test) is a great troubleshooting step to see if its an app problem or something corrupt in your settings or support files. When most users reinstall an app as a troubleshooting step, they aren't doing much of anything, with all those files sticking around.
UTM buries their VM disks away in a container inside the ~/Library. I have a 20GB disk in there. It's not always trivial small files. If someone deletes UTM and forgets to check for old VMs first, that's a big hit.
What I'd like to see is a something, maybe in the Settings app, that lists all the applications on the system and 3 options.
1. Remove Application, keep Library data
2. Remove Application and Library data (have it give into on what files are in there)
3. Remove Library data only (this could be used to refresh an app to start over with it)
Maybe in addition to that, as part of the Optimize Storage feature, it could crawl through all those old orphaned application support folders and containers, and list all the ones without an app installed, show the size, and the user can choose to get rid of them.
Looking at how much junk I have out there now, I may just do a re-install of my OS to clean things up soon. I usually wait for a new system, but this M1 Pro is lasting a long time. I recently migrated off 1Password and it seems to have a bunch of junk out there, including 4 year old weekly archives of all my passwords that it took for a few months for some reason. The files are encrypted, but who knows how long that will actually be good for.
I don’t understand. Any MacOS Finder that had an open file handle into an application bundle runs on the Unix version of MacOS, and that allows deletion of open files (the inode stays around until the process exits), doesn’t it?
Or did/does the Finder check whether to-be-deleted files are open? Or did I forget how older Mac file systems behaved?
> This would explain why HTML entities are so effective.
Could also be that they learned that sending spam to obfuscated addresses doesn’t gets much response. Such messages might get filtered out more and/or addressees might be less inclined to reply to it.
Will flag this because of the misleading title.
reply