Another way to look at it is that Apple is making it harder to run the system in an insecure fashion. You may not agree with that decision, but I certainly appreciate how Apple is looking out for the safety and security of the user. Tangent: as much as some developers hate that the only way to distribute apps for the iPhone is through the App Store, as a user I consider that walled garden of apps to be a real securit…
Wouldn't a sandboxed Zoom downloaded directly from them be equally secure?
Apple’s rejected a huge number of App updates for security reasons. It’s not a huge benefit, but it does exist.
> creating arbitrary directories in / is a terrible idea, and has been at least since I started using UNIX/Linux systems in the 90's Why?
Because the filesystem root is the domain of the OS, if tomorrow they decide they are going to create a symlink of /dev/null in /nix because they thought it sounded cooler as a way to "nix" stuff, there goes the Nix package manager. The OS gives you places to put your files, use them so that you prevent breakage. We have the FHS, so you even have some degree of certainty of where to do it across Unixes. EDIT: Two dow…
Because the filesystem root is the domain of the OS, if tomorrow they decide they are going to create a symlink of /dev/null in /nix because they thought it sounded cooler as a way to "nix" stuff, there goes the Nix package manager. The OS gives you places to put your files, use them so that you prevent breakage. We have the FHS, so you even have some degree of certainty of where to do it across Unixes. EDIT: Two dow…
This is wrong. Everything not specified in the FHS is the domain of the administrator and is a contract with the OS about what directories it wont touch. Nix, operating outside of the FHS, did the literal correct thing because there is no guarantee that the OS won’t install something in /opt/nix but there is a guarantee that it won’t touch /nix.
As a sysadmin you can do anything you want and are free to deal with the breakage you cause yourself. But the FHS pretty clearly establishes what behavior an application such as Nix should have: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03.html#p...
Quote:
"Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package."
They can choose not to abide the FHS, and that's fine if the users are happy with that tradeoff. But OSes observing the FHS are free to break Nix's expectations because they don't align with the FHS.
Windows + VSCode + WSL2 + Terminal + PowerToys = Just one love, never looked back.
The only problem I have with that is "Windows" I'm currently trying to figure out how to emulate windows from a *nix distribution using qemu. I plan to use this as a "home lab" (k8s cluster or just plain fucking around), but still retain the ability to play an occasional AAA game.
You don't need to emulate windows if you have windows as parent host ;). Windows with WSL is the best linux desktop which i had for past 20 years
Apple replaced the very simple (i.e. function fits in a cache line; inputs fit in a single dword) BSD user/group/other filesystem privileges system, with a Lisp interpreter (or maybe compiler? not sure) executing some security DSL[1][2]. [1] https://wiki.mozilla.org/Sandbox/OS_X_Rule_Set [2] https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand... This capabilities-ruleset interpreter is what Apple uses the te…
> Lisp interpreter (or maybe compiler? not sure) I believe it is actually a Scheme dialect, and I would be very surprised if it is not compiled to some internal representation upon load. > This capabilities-ruleset interpreter is what Apple uses the term "Gatekeeper" to refer to, mostly. I am fairly sure Gatekeeper is mostly just Quarantine and other bits that prevent the execution of random things you download from…
In the Apple Sandbox Guide v1.0 [1], it mentions Dionysus Blazakis' paper [2] presented at Blackhat DC 2011.
In the latter, Apple's sandbox rule set (custom profiles) is called SBPL - Sandbox Profile Language - and is described as a "Scheme embedded domain specific language".
It's evaluated by libSandbox, which contains TinyScheme! [3]
From what I could understand, the Scheme interpreter generates a blob suitable for passing to the kernel.
Because the filesystem root is the domain of the OS, if tomorrow they decide they are going to create a symlink of /dev/null in /nix because they thought it sounded cooler as a way to "nix" stuff, there goes the Nix package manager. The OS gives you places to put your files, use them so that you prevent breakage. We have the FHS, so you even have some degree of certainty of where to do it across Unixes. EDIT: Two dow…
It’s because Nix was designed to be part of the OS, as integral as apt is for Debian installations. The ability for it to live side by side with another packaging system is just a side-effect of how it was designed, not part of the original goals.
And NixOS is a great idea, but Nix advertises itself as "a powerful package manager for Linux and other Unix systems" in its the official site's description. Yet by not abiding to the FHS, they opened themselves up for breakage.
Can you explain the reasoning here? I can see it being _easier_ than doing it the right way but have trouble coming up with a scenario where it makes it _impossible_.
Packages can not 'accidentally' depend on other packages as the only way to depend on a package is by referring to their full path which your learn by evaluating that package. If you have an application that calls /usr/bin/nginx but doesn't declare a dependency on nginx; but you had nginx installed already the package works fine and you only find our later In nix you can't do this as you don't know nginx's path witho…
Nothing about that says that the path has to be /nix — it would work just as well with the standard layout under /opt/nix.
It also seems like it doesn't really help with the stated problem since a developer who would hard-code /usr/bin/nginx but not list it as a dependency would almost certainly just use whatever `which nginx` returns. The thing which would solve that is depending on a precise version or hash, and if you're doing that, the path prefix doesn't really matter.
> `mkdir -p /opt/nix` assumes that there is a convention A correct assumption on virtually all relevant extant systems... > which may not be the case for every situation In the supposed scenario where the assumption isn't correct, the downside of /opt/nix vs /nix is basically insignificant. What's the overhead of one level of directory nesting, a single extra inode? Big whoop.
And what is the issue with leaving it as `/nix`, which is (was) accessible on virtually all extant systems? Other than "the root folder is special!"
Nothing was wrong with it, except that it violated convention. As I said: "The big difference between the two is the later conforms to convention while the former doesn't."
Violating convention comes with risk. Whether violating convention and assuming that risk is a good idea depends on whether the risk is worth the reward. For Nix, I don't think it was.
Wouldn't a sandboxed Zoom downloaded directly from them be equally secure?
Apple’s rejected a huge number of App updates for security reasons. It’s not a huge benefit, but it does exist.
And also allowed a jailbreak app in the iOS App Store. Yes, it only happened once (that I know of), but it still shows you can't really be oblivious to their practices.