> 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”.
> 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.
I don’t see this article showing that. They query for extensions that could be used to do that, and that likely already is illegal, but those queries could solely be used to uniquely identify users (grabbing more bits makes it less likely to get collisions)
Those being in the list doesn't mean that's what they're looking for. Take a look at the database of extensions, there's far more extensions that don't seem limited to any particular group. The author just called those out specifically because they're perfect for implying nefarious intent.
It does suggest that’s what they’re collecting. That is per se a violation in many jurisdictions. It should trigger investigations in most others to ensure it wasn’t mis-used.
The claim I replied to is “They try to profile for things like political beliefs”.
I wasn’t contesting that they query extensions that can be used for that purpose, or that they use query results for that purpose, but indicated that the fact that they make such queries doesn’t necessarily imply that they try to do such profiling.
>LinkedIn scans for Anti-woke (“The anti-wokeness extension. Shows warnings about woke companies”), Anti-Zionist Tag (“Adds a tag to the LinkedIn profiles of Anti-Zionists”), Vote With Your Money (“showing political contributions from executives and employees”), No more Musk (“Hides digital noise related to Elon Musk,” 19 users), Political Circus (“Politician to Clown AI Filter,” 7 users), LinkedIn Political Content Blocker, and NoPolitiLinked.
>Each of these extensions reveals a political position. If LinkedIn detects any of them, it has collected data revealing that person’s political opinions. Article 9 prohibits this.
https://browsergate.eu/how-it-works/: “Every time you open LinkedIn in a Chrome-based browser, LinkedIn’s JavaScript executes a silent scan of your installed browser extensions”
- to have a convention to, instead of signing “payloads, to always sign “type identifier + payload”, to prevent adversaries from reusing your signature to sign the same payload, interpreted as a different type.
- use 64-bit type identifiers
- put the identifiers in the IDL (may need augmenting IDL to allow that)
#1 makes sense to me; #3 also makes sense, as that’s the place where people will have to look to learn about your types.
#2, I think, is up for discussion. These could be longer, Java-like strings “com.example.Foo”, or whatever.
I think some people also may disagree with the argument that putting type identifiers inside the payload makes messages too large, but I don’t have enough experience on that to make a judgment.
> 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”.
reply