> At work we're using an LLM to analyze Windows crash dumps, which turns out to be quite expensive -- several dollars per dump, and you might analyze many every hour
Is that in any way useful?, how so?, are dumps from optimized builds?
I've found that most of the time I don't even need to open a dump because of regular automation providing all thread callstacks in tickets... That and logs are generally enough...
> Also, running a program is the most basic functionality of an OS and you suggest that I need to write my own sandbox to do this because it is not included with Linux. Maybe that is why this year still is not the year of Linux on desktop.
I'm saying other OSs are worse for sandboxing.
How would you achieve what you want on MacOS or Windows? (or others?), what do you think goes on behind the scenes?
I would set up a VM if i were that paranoid btw. Qemu, docker, deploy the container to it, vnc or gpu access.
Also, one question for you, since you brought up microphone, how do you defend from Microsoft/Google/Apple deciding to spy on you and access the microphone? (secret court order or who knows why in the future)
> Neither SELinux not AppArmor allows to show a question "would you like to allow program N to access your microphone"
Permissions on microphone device would work, build your own UI / virtual device or generate one with claude if you really want popups.
> "would you like to let the program connect to github.com? (Yes) (No) (With decrypting SSL traffic)"."
I actually have something for this. Firewall everything blocked, domains unblocked via DNS request if I allow them.
Linux is very powerful here compared to iOS - can you block specific domains there?
> The best you can do today is either write your own sandbox around Linux namespaces (very complicated), or try lightweight VMs like Firecracker, or paravirtualization (like VM but with a shared kernel).
What do you think the sandbox on ios/android is?, still a vm/namespace/container...
> require lot of work and programming.
Sure, but you learn.
> I want to install random packages and still be safe. That's the point of installing an OS, to be able to run random programs on the computer.
That's not true anywhere. I would not feel safe with random apks or random store entries on android OR iOS. On iOS i lived through the whole 'access a webpage to get jailbreak' phase... with no way around it since mandatory safari
So, other OSs just give you the impression of safety. And you're locked. (iOS with safari...)
Internal projects can get done with less of either.
Nobody really cares about great UX or about how great someone can implement a CRUD app.
So there will be less need/fighting over such resources.
If I can just generate a usable UI for a hobby project I don't need to find some company to build it out. Sure, it will miss out on a lot of stuff but it's a trade off.
If someone else can build a product and needed a basic web shop / crud app, they don't need to find someone to implement that at a massive overcharge.
> The attack works by having an NTFS log get replayed against another partition than the one the log is stored on.
Obfuscated enough to pass internal reviews, sloppy enough to make it look like a bug.
Other reply makes it even more suspicious... change is new in a subsystem that hasnt been updated in a long tine and it's only present in recovery mode files.
Microsoft handle of this also screams it's not a regular bug and they're likely investigating or someone is trying to cover their ass.
What's even more troubling is that the fix would be a very simple/quick rollback of the change that introduced this... and that they haven't done that is interesting.
3 would be either direct or friends/relatives with experience and I got involved to help, other 3 would be through news and incidentally knowing some people.
> but one person having direct experience of all these cases is unusual for a civilian
Sure, still, indirect stories I have a lot more, just stopped at those 6
Is that in any way useful?, how so?, are dumps from optimized builds?
I've found that most of the time I don't even need to open a dump because of regular automation providing all thread callstacks in tickets... That and logs are generally enough...