M3 core counts and performance

[theorist9]

The simplest approach would be to have a /Library/DLogs/ which contains a bunch of dlog.com.vendor.app files, listing the directories that an application has created files in. Each time the application creates a file, without going through a save dialog, the system would attach an ACL metatag identifying the app and add a dlog entry for the directory, if there is not one already. Hence, all the files belonging to an app could be found by searching the logged directories for app-tagged files, and no changes in the way an app is coded would be required.

I was wondering if there was a way the system could distinguish between files saved by the user and those saved by the application based on how they are saved. If what you suggest would work, that's a better basis for distinguishing between the two than what I had proposed, which is the location in which they were saved.

 

[Yoused]

There are all those obfuscated directories that the average user never sees. Anything in ~/Lbirary/ or ~/../../ , except in /Voumes/ , would be candidate locations for application-generated files that the user cannot know about, or anything anywhere with .filename. But, searching all over the place for meta-tagged files would be burdensome, so the dlog concept would help a lot, I think. Of course, dealing with bundles (e.g., an .rtfd type thing) might kind of a challenge.

 

[Agent47]

There might be a problem (for some, no technicality though): companies (e.g. VMWare) provide evaluation copies of their products, which run for a certain time (typically 30 days).
As far as I am aware they do this using secret/hidden files. If an uninstall reliably deletes all files, extending the evaluation period would just be an uninstall/reinstall cycle away.
I suspect software manufacturers would not be happy about such a feature and would boycott it.
Unless I am missing anything?

 

[theorist9]

There might be a problem (for some, no technicality though): companies (e.g. VMWare) provide evaluation copies of their products, which run for a certain time (typically 30 days).
As far as I am aware they do this using secret/hidden files. If an uninstall reliably deletes all files, extending the evaluation period would just be an uninstall/reinstall cycle away.
I suspect software manufacturers would not be happy about such a feature and would boycott kt.
Unless I am missing anything?

I'm no expert on this, but I'd imagine the program could require an internet connection to operate during the trial period. In that case, when it's first installed, the program could send the installation date and your Mac's hardware UUID (or some other unique identifier) back to the company's servers. Even if you did a complete uninstall, you wouldn't be able to operate the trial after reinstalling because the company's servers would know the trial period for your Mac had passed.

 

[Cmaier]

I'm no expert on this, but I'd imagine the program could require an internet connection to operate during the trial period. In that case, when it's first installed, the program could send the installation date and your Mac's hardware UUID (or some other unique identifier) back to the company's servers. Even if you did a complete uninstall, you wouldn't be able to operate the trial after reinstalling because the company's servers would know the trial period for your Mac had passed.

Lots of ways to do this. For some very expensive software we used to buy, the trial software simply included a digitally signed and encrypted key that incorporated the expiration date.

 

[theorist9]

Is this something a 3rd-party developer could build, or could it only be implemented by Apple? I'm guessing the latter, since I can't see a 3rd-party app being given permission to track the installation and operation of all other 3rd-party apps.

 

[leman]

To me it sounds like a recipe for losing data. I don't see how a system can reasonably distinguish between user-owned files and application-owned files. Save dialog is not a reliable criterion. There are myriads of applications out there, from code editors to apps using databases, which rely on more or less arbitrary file access.

 

[theorist9]

To me it sounds like a recipe for losing data. I don't see how a system can reasonably distinguish between user-owned files and application-owned files. Save dialog is not a reliable criterion. There are myriads of applications out there, from code editors to apps using databases, which rely on more or less arbitrary file access.

Well if you didn't like Yoused's save dialog idea, how about the one that I proposed, based on location?

If you want to be conservative about it, you could flag only app-generated files saved outside /Users (surely files saved outside /Users should not be user-owned) (excluding those in /Volumes). [Or are there apps that create a single shared database for all user-generated data for all User accounts, that is stored at the root level, e.g., in /usr/local?] That wouldn't get all the files, but it would get the ones that are most troublesome to identify and remove.

That may not be perfect, but my philosophy in this case is that the perfect is the enemy of the good, and adding the above functionality would be an improvement over what we have now.

And you could additionally include files that are inside user Accounts and are in folders starting with ".", and pehaps those in the User Library folders as well, but add a safeguard where the program lists all files it will delete, and if there are any that the developer indicates contain user data, you could exclude them from the list.

Indeed, the latter could be excluded by default, and the program could add a statement for those like: "Warning. Some of these may contain user data, which you may wish to preserve. If you are unsure, please contact the app's developer."

 

[Yoused]

At least macOS has a tradition of not using installers. In the past, a Windows installer would have the app putting in its own versions of various system files (the dynamic link library thing was particularly ugly). Mac apps have typically been much better behaved.

 

[leman]

Well if you didn't like Yoused's save dialog idea, how about the one that I proposed, based on location?

If you want to be conservative about it, you could flag only app-generated files saved outside /Users (surely files saved outside /Users should not be user-owned) (excluding those in /Volumes). [Or are there apps that create a single shared database for all user-generated data for all User accounts, that is stored at the root level, e.g., in /usr/local?] That wouldn't get all the files, but it would get the ones that are most troublesome to identify and remove.

That may not be perfect, but my philosophy in this case is that the perfect is the enemy of the good, and adding the above functionality would be an improvement over what we have now.

And you could additionally include files that are inside user Accounts and are in folders starting with ".", and pehaps those in the User Library folders as well, but add a safeguard where the program lists all files it will delete, and if there are any that the developer indicates contain user data, you could exclude them from the list.

Indeed, the latter could be excluded by default, and the program could add a statement for those like: "Warning. Some of these may contain user data, which you may wish to preserve. If you are unsure, please contact the app's developer."

I just don't think this is a solvable problem. A system should never delete data unless there is 100% chance this data is not relevant to the user. All the proposals described so far will lead to unexpected data loss. That's why common uninstallation techniques rely on installation recipes (you track which files the installer wrote and these are exactly ones you remove), application-defined uninstallers (the application knows which files it wrote), or application bundles (all application-specific data is in one place that cannot be further modified with user data, and can thus be safely removed).

Apple's system is already very good compared to many. The issue here is that some companies (like Adobe) do not respect the conventional platform guidelines, instead insisting on custom installer behavior that does something idiosyncratic. You can't disallow this behavior unless you go fully locked like iOS, because there is software that legitimacy needs more flexibility.

 

[JRLMustang]

I just don't think this is a solvable problem. A system should never delete data unless there is 100% chance this data is not relevant to the user. All the proposals described so far will lead to unexpected data loss.

App *developers* shouldn’t get to decide that. Hence the situation as it currently exists. Give them an inch, and well, they’re never quite satisfied.

The issue here is that some companies (like Adobe) do not respect the conventional platform guidelines, instead insisting on custom installer behavior that does something idiosyncratic. You can't disallow this behavior unless you go fully locked like iOS, because there is software that legitimacy needs more flexibility.

Legitimately needs more flexibility? Can you provide an example other than employing some type of end-user tracking and monitoring scheme used to harvest user data? The trouble seems to be that these app developers have ambitions of developing their own platforms and providing them as SAAS, relegating the actual foundational platforms they’re built upon as irrelevant. Why do they care if you use Windows or macOS, as long as you’re locked into their software and workflow, and hence their “platform”. Everyone wants to be their own “platform”. Ever notice that?

 

[Yoused]

A system should never delete data unless there is 100% chance this data is not relevant to the user.

I do not disagree with this. My thought was not so much that the process should be automagic but that app activity should be tracked. Many users would appreciate having an app scrub function, and/or an inspection tool. I try out browser W for a few days and decide it is not to my liking, ut in the meanwhile, W.app has crufted up ~/Library with cache files and cookies and other files that are just a waste of space (a universal cache framework might be a handy feature) that I would like to purge easily when W.app is not there to make use of them.

 

[theorist9]

I just don't think this is a solvable problem. A system should never delete data unless there is 100% chance this data is not relevant to the user. All the proposals described so far will lead to unexpected data loss. That's why common uninstallation techniques rely on installation recipes (you track which files the installer wrote and these are exactly ones you remove), application-defined uninstallers (the application knows which files it wrote), or application bundles (all application-specific data is in one place that cannot be further modified with user data, and can thus be safely removed).

I think it could be configured in a way that would leave user data protected. I like Yoused's idea of having the system track every file not installed via a save dialog. As you pointed out, this could include database files and others that contain user data. But then, rather than having the system delete all files it indentifies automatically, it would instead provide you a list of all files it found. You as the user would then examine the list to see if any contain user data, and exclude those from deletion. If you're not certain, you could always provide the list to the developer and ask.

To facilitate this, the app could have a filtering function. For instance, suppose it flags numerous user data files not installed by the save dialog. There's a good chance they all share the same extension(s). The filtering function could allow you to exclude all files of the form *.[extension].

With this, the risk of deleting user data is no greater than it is when doing a clean install. After all, when doing a clean install, the user likewise has to identify which files contain user data and thus must be preserved. Conversely, if you could never safely remove an app using the above approach, because the identity of the user data files is never 100% knowable, you likewise could never safely do a clean install either—which I'm sure you'll agree is clearly not the case.

The advantage of having such automatic tracking is that it allows one to fully clean out an app without having to do a clean install. It would be super-convenient to know that, say, "zr0393kqe9383rts.kext" belongs to the app you want to delete. Without some sort of tracking functionality (or external information) to tell you that*, you're forced to leave files like that alone, and such files can sometimes cause trouble. [*Or an uninstaller, which is often not provided, or an installation recipe, which sounds cumbersome to create.]

 

[leman]

I do not disagree with this. My thought was not so much that the process should be automagic but that app activity should be tracked.

I think it could be configured in a way that would leave user data protected. I like Yoused's idea of having the system track every file not installed via a save dialog. As you pointed out, this could include database files and others that contain user data. But then, rather than having the system delete all files it indentifies automatically, it would instead provide you a list of all files it found. You as the user would then examine the list to see if any contain user data, and exclude those from deletion. If you're not certain, you could always provide the list to the developer and ask.

That is something you can do today. MacOS does full filesystem event tracking, you can hook into that and maintain a database of accessed files. Will this help the end user in a meaningful way though? The performance cost and the amount of data to look through will be non-trivial.

It seems that most of the discussion revolves around dealign with "impolite" apps. For that, something more selective might be a better choice. For example, a way to tell the system that an app is potentially rude, so that more restrictions/monitoring can be placed on its behavior.

App *developers* shouldn’t get to decide that. Hence the situation as it currently exists. Give them an inch, and well, they’re never quite satisfied.

Making things difficult for everyone just because of few rogue players is rarely a good strategy. I am all for meaningful restrictions/safety features. I am however decidedly agains full sandboxing and iOS-like software filtering on a Mac.

Legitimately needs more flexibility? Can you provide an example other than employing some type of end-user tracking and monitoring scheme used to harvest user data? The trouble seems to be that these app developers have ambitions of developing their own platforms and providing them as SAAS, relegating the actual foundational platforms they’re built upon as irrelevant. Why do they care if you use Windows or macOS, as long as you’re locked into their software and workflow, and hence their “platform”. Everyone wants to be their own “platform”. Ever notice that?

Developer tools, various UNIX utilities, databases...

Again, we are talking about a few rogue players. Those are a known quantities and there are much better ways to deal with them than nuking everyone. My solution to Adobe and Microsoft is very simple — I just don't install their software on my computer. The very few times I need to use Excel for administrative stuff, I do it in the online MS suite my employer provides. If I really need to deal with some of this crappy software (like the IBM management software I had to use when I still had my IT admin job), I use a virtual machine.

 

[leman]

If one wants to solve these things in a way that actually works, one would probably need to start from scratch. And the first step is to complete reimagine how storage is organized and controlled. Imagine a system where all software fundamentally runs in their own jail, completely isolated from one another and the rest of the system. Instead of a file tree, there are (again, isolated) data containers, and users can freely select which application (and at what granularity) has access to which container. I really liked Microsoft's WinFS idea, it's a shame it never really worked out.

 

[theorist9]

It seems that most of the discussion revolves around dealign with "impolite" apps. For that, something more selective might be a better choice. For example, a way to tell the system that an app is potentially rude, so that more restrictions/monitoring can be placed on its behavior.

Making things difficult for everyone just because of few rogue players is rarely a good strategy. I am all for meaningful restrictions/safety features. I am however decidedly agains full sandboxing and iOS-like software filtering on a Mac.

Again, we are talking about a few rogue players....

I think it's a lot broader than that. According to the most recent Apple developer guidelines I could find*, other than user data, apps are supposed to restrict themselves to /Applications, /Library, and ~/Library. But that still means devs that "follow the rules" can (and do) scatter files and folders in numerous subdirectories throughout those two Library folders. That's a lot of crap to remove if you want to cleanly uninstall the app.

*From 2018, alas...but I don't think it's changed since then... https://developer.apple.com/library...e/FileSystemOverview/FileSystemOverview.html#

@Yoused's example of app testing is a great one. When I need a new functionality, I'll often install trials of 2-3 different apps which offer that, to test out which works best for me. Since this is just testing, there is no user data involved. It would be super-convenient for MacOS to provide me a list of all those files, so I could nuke them.

That is something you can do today. MacOS does full filesystem event tracking, you can hook into that and maintain a database of accessed files. Will this help the end user in a meaningful way though? The performance cost and the amount of data to look through will be non-trivial.

I've never done this, but it sounds like you are talking about noting the time, installing the app, and immediately going into event tracking to identify all files created since that time, and then filtering those for the files installed by the app. That sounds terribly burdensome (as you acknowledge yourself), and is not at all what I proposed, which is for the system to tell you which files belong to the app specifically.

So you really can't "do it today", at least not in any practical way, since today you can't automatically get a list of the files the program installed, and only those files. That's the issue my proposal is designed to address.

My solution to Adobe and Microsoft is very simple — I just don't install their software on my computer. The very few times I need to use Excel for administrative stuff, I do it in the online MS suite my employer provides. If I really need to deal with some of this crappy software (like the IBM management software I had to use when I still had my IT admin job), I use a virtual machine.

I can understand that works for you, but many of us need those programs, and/or find the alternatives even worse, and don't like the added complication, and possibly reduced responsiveness, of switching to online use/virtual machines/remote desktops. I've found, for my workflow, it's much nicer to to have all my apps locally installed, and to not have to use a VM.

For instance, some of the PDF's that NIH uses for grant submission can only be opened in Acrobat; Preview doesn't work. Plus I do need a convenient way of displaying and manipulating the large amounts of data some of my programs output, and I've found Excel works better for this that any other spreadsheet program I've tried. Likewise, while Outlook and Word are far from perfect, I've tried various alternatives and either I don't like their interfaces, or find they lack key functionality I need. And at this point they're "the devil I know".

 

[theorist9]

Returning to the RAM discussion we were having earlier on this thread: I don't know if anyone has already posted this elsewhere, but Steam's hardware survey lists RAM by OS. I've pasted screenshots for OSX, Windows, and Linux, respectively.

Here we can clearly see the effect of Apple's RAM pricing, and its non-upgradeability. For OSX, the most common RAM size is 8 GB, followed by 16 and 32. For Windows and Linux, it's 16, followed by 32 and 8.

What's striking is that 45% of the Macs have 8 GB RAM, while only 3.5% and 3.1% of the Windows and Linux boxes do. On the latter, it seems 8 GB is mostly a relic of the past. Using the Wayback Machine, I found the last survey that had 8 GB as the most common RAM size was four years ago (Oct 2019).

Windows' and Linux's most common RAM size, 16 GB, is similar to Apple's 8 GB in that all are found on about half of the machines (50% and 60% for Windows and Linux, respecively).

Thus I guess Bob Borchers (Apple's VP of worldwide product marketing) was right when he said "Actually, 8GB on an M3 MacBook Pro is probably analogous to 16GB on other systems." It really is!

I don't know how representative these distributions are of Macs and PC's generally. I suspect that they underrepresent the proportion that have 64+ GB RAM, since such workstation-class machines are (I'm guessing) less likely to be used for games.

But I don't know how to make an educated guess about the low end. E.g., are Steam users less likely to buy Macs with only 8 GB RAM, such that these figures might underrepresent the proportion of Macs as a whole that have 8 GB?

Steam Hardware & Software Survey

 

[Jimmyjames]

Just saw this. Not sure what GF DGEMM is, or how competitive 800 Gflops of it is, but they seem impressed! Anyone know how compares to other cpus?

https://x.com/HPC_Guru/status/1741582324255641773?s=20

 

[leman]

Just saw this. Not sure what GF DGEMM is, or how competitive 800 Gflops of it is, but they seem impressed! Anyone know how compares to other cpus?

https://x.com/HPC_Guru/status/1741582324255641773?s=20

View attachment 27837
View attachment 27838

Is that the new AMX unit in action?

 

[Jimmyjames]

Is that the new AMX unit in action?

I was hoping someone could tell me! Sounds plausible though.