Tony Baechler here.
Honestly, I don't really have answers to your questions, but you raise good
points. I installed and played with nix and it's very accessible. It's just
a suite of command line tools to manipulate packages. It could easily be
scripted. In fact, the install script just downloads and extracts binaries
for your system. I saw no support for anything other than x86 and x86_64, so
no ARM, but the C source looks portable enough.
I wasn't thinking about low memory systems. Ultimately, it's doubtful that
you could use it on a small system. The memory wouldn't be an issue, but the
disk space definitely would. Just a minimal install with no packages takes
221 MB. However, with drives being so cheap, this is hardly an issue,
especially since ARM isn't officially supported anyway. There is no reason
why it couldn't be, it just isn't.
Regarding sandboxing, no, I don't think that's it. It modifies the system
environment to add the "nix store" to the path. Since each package gets its
own directory, it's impractical to add potentially thousands of directories
to the system path. It symlinks the binaries somewhere (I haven't quite
figured out where, but somewhere under /nix) and adds that directory to the
user's path. You can have multiple environments and switch among them. I
think your worry about Orca wouldn't be an issue. I guess someone could
install several different versions of various desktops and create a
conflict, but even then, they could create a different user environment. I
haven't tried installing multiple versions of a package, but when I
installed hello, I was able to run hello from the shell as normal. The only
time I see sandboxing being an issue is if you use nix-shell which runs an
isolated shell for you to test or build from source. My server doesn't have
X, so I can't test this further.
The obvious workaround is to only install the accessibility stack from nix
and not from the running distro. As an example, it said you could run
multiple versions of Firefox, but didn't deal with accessibility. I guess
others would have to look into this further. I think you can still only run
one version at a time, even if multiple versions are installed. Yes, each
app has its own dependencies in its own directory. I don't know how it works
around the same services being launched multiple times, but it uses a custom
init manager which I haven't looked into yet. Based on a quick look, to me,
it looks like a better base for a custom distro than Fedora which has no
great accessibility anyway. While nix says nothing at all about
accessibility and the nixos distro is probably not accessible, the package
manager is no different than Arch or most others in that it's just command
line tools. Obviously, this would need to be investigated further.
On 5/7/2017 8:16 AM, Linux for blind general discussion wrote:
Just how sandboxed is each application on a system like this? I'm concerned
about the increase in disk and RAM requirements for such an OS, since the
concept of shared dependencies is essentially being circumvented using this
packaging system. That said, the more important issue by far is
accessibility. There is a high probability that attempting to package
accessibility in such an environment would effectively sandbox the a11y
stack so that it would not be able to communicate with the other equally
isolated applications on the system, thereby causing worse problems than we
would be trying to solve. The concept of version conflicts would no longer
be a problem, but the ability to run multiple versions means nothing if
applications can't efficiently communicate with multiple at-spi instances,
and if Orca would get confused by so many at-spi instances trying to talk to
it at once. Would each application also need its own Orca? In this case,
we're talking about gigabytes of redundant dependencies, which is a huge
problem on low-storage and low-RAM systems, as well as all these Orca
instances needing to communicate with speech-dispatcher, which would cause
other problems.
~Kyle
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list