I have found that a lot of the techniques used to decensor models (as far as I can tell, they basically get all their weights to say no turned off) also make them really stupid. Like, sure, it will help you rob a bank, but if you ask whether you should rob the bank it will go "The positives: … The negatives: … My take: You should ABSOLUTELY rob the bank".
I wonder if this is due to abliteration actually "damaging" the model, or just an artifact of the model never having been properly trained on "forbidden" topics (as it's enough for them to recognize them, and there's no point in dedicating neurons to something that will never be exercised anyway).
Modern abliteration is quite good at not damaging the model on ordinary topics. But yes, on many of the weirdest "forbidden" topics (excluding the mild stuff like ordinary erotica) there's not going to be any real training of any sort and it's basically hallucinations running wild. You even see this claim repeated explicitly on every model release "safety card": 'no, this model does not have the sort of fiddly tacit know-how it would need to actually advise anyone nefarious on this dangerous stuff'.
Someone doing harm to you doesn't automatically mean you wish harm to them. Not that I necessarily take what Garry says at face value but it's definitely possible to unironically take this viewpoint.
I thought that was a typo or the forum software removed something, but no - it's a pointer to an empty string literal. If I understand how that works, this creates a null byte (in the read-only memory section of the compiled output?) and points to it. Before this line it checks if p is NULL.
I wonder what is the advantage of doing this? Maybe to make sure that p is an actual pointer, so later code can just make that assumption.
That makes sense, with that "guard" at the top, the rest of the function can return the pointer anywhere. And I imagine the compiler will ensure the empty string literal is created only once. Good to know!
it would be better to make p a const char* though, so that the code is not casting away the constness of the string literal (which can invoke undefined behaviour, though in practice string literals are going to be in a read-only area of memory anyway).
I feel like the complaints here are…not really Samsung's fault?
> So I’ve dug around and found a cleanup script buried six folders deep inside the app bundle. Let’s try to run it:
> sh ~/Library/'Application Support'/Samsung/'Samsung Magician'/SamsungMagician.app/Contents/Resources/CleanupMagician_Admin_Mac.sh
> It ran. And my kitty exploded. Sweet kitty overflowed. Hundreds - literally hundreds - of lines of chown: Operation not permitted.
I mean, if you read on, you'll find that most of the things that were removed were from system folders that are owned by root? Presumably this was run without sudo…
> I rm -rf every Samsung folder I could find. The Preferences. The Caches. The LaunchAgents. The LaunchDaemons. The kernel extensions. The crash reports.
…that's where you put your stuff on macOS. Would you prefer that they picked some non-standard location you had to dig up?
> Package receipts in /private/var/db/receipts/ (Samsung left its receipts behind like a burglar leaving a bunch of turds in the living room)
This is again for your benefit so you know what was installed on your system
> Cached processes in /private/var/folders/7v/<your username hash>/C/ (yes, Samsung is in there too)
That's getconf DARWIN_USER_CACHE_DIR
> I shut down my Mac. Held the power button. Booted into Recovery Mode. Opened Terminal. Ran csrutil disable. Rebooted. Opened Terminal. Deleted the kernel extensions.
That's just how kernel extensions are on Apple silicon
* going into some internal directory and running a script based on the name
* deleting a bunch of directories
Seem like pretty bad ideas. Especially for software provided by a hardware vendor, which is probably a little clunky and inherently touches deep stuff.
But not including a removal script seems like bad form.
Edit: On the other hand, I don’t actually know for certain that the tool doesn’t have an uninstall script. Just, that the author didn’t find it. This seems worth noting because the author really wasn’t giving them the benefit of the doubt on anything, see all of the irrelevant complaints about animations.
I mean, there clearly was an uninstall script. It was in the app's Contents/Resources file, and it was called CleanupMagician_Admin_Mac.sh. Which means there was some intended way to trigger running it. Perhaps Samsung's instructions or their menu system weren't clear and they managed to hide it from him. But there most definitely was an uninstall script, and if he had managed to find the intended button in the interface, it would have asked for admin permissions and then done all the cleanup for him. The very cleanup that he complained about having to do by hand.
I think you are probably right. Although, with a name like that it could be some post-install cleanup of temporary files (which would explain why it was doing chown, rather than rm, although there are certainly other options!).
I wondered about the chown thing myself, but ended up concluding that the author was misremembering the errors. He probably saw some chown messages and didn't read all the hundreds of lines (I certainly don't read every line of hundreds of log lines, I skim looking for key words), meaning many of them could well have been rm failures that he misremembered as chown. But whatever it was doing, the author would have been wise to read it before deleting the directory it contained, as it would have saved him a lot of trouble finding all the bits and pieces he had to hunt down later.
The author is an unreliable narrator. The very first thing, the location of the script, can’t possibly be true (the app itself won’t be in per-user support data directory). They conflate things, they definitely don’t know enough about macOS to know to use sudo. I mean, they even rant about bog standard localization files…
Sadly, there are apps out there whose installers drop helper apps in ~/Library/Application Support. Or worse: Eve Online actually puts the whole game there. The Eve.app in /Applications (or wherever you choose to put it) is just the launcher/downloader.
> I feel like the complaints here are…not really Samsung's fault?
I don't know man, the last time I uninstalled an app on macOS, all I had to do was drag it to the trash. If you find this procedure sane, then I don't know what to tell you.
Samsung is responsible of how users interact with their app, including its install and removal.
There is a new way to make apps to mostly allow this to work, but very few apps have taken advantage of this. That is definitely on Samsung. However, macOS was really like this for many years and if you ship software that talks to your SSD you kind of have to make it this way.
It's a .sh script, so he could have read it before running it. And when he saw "chown: Operation not permitted", he could have realized that the word Admin in the script was a clue that it needed, well, admin-level privileges, and he should try running it with sudo (after reading it first, naturally). I'm with you, I feel like this is someone who caused himself a lot of self-inflicted pain.
I mean, if he had read the script before deleting it (that's the third time I've mentioned reading the script, do you think I'm dropping enough hints?), he might have found a handy list of ... ALL THE FILES HE WAS LOOKING FOR. You know, all the 18 or so locations that he had to find by hand.
But nope, he didn't ... yes, I'm going to say it for the fourth time ... READ THE SCRIPT.
And what about for users that either can’t find this uninstall script or wouldn’t know how to read it or what the contents mean? While I think you do have a point, we also can’t assume that the uninstall script really would’ve removed all traces.
The fact that it reported "hundreds" (if the author is right about that, he might be misremembering) of permissions-related errors tells me that it was trying to clean up hundreds of files. Sure, not knowing what's in the script, I can't say for certain that it wouldn't have missed something... but it sounds like it was trying to be thorough. And it was written by the people in position to know what needed to be cleaned up, so I actually have no reason to assume that it wouldn't have removed all traces.
Those users have never heard of the word `uninstall` nor have any comprehension of what it would do. They will after a time, just buy a new computer because the old one is full up.
Also it doesn't take 18 steps to uninstall. The steps provided are the steps he took stumbling around trying to remove every trace of it, but it is in no way the optimal method.
reply