| |||||||||||||
GNU Guix launchesGNU Guix launchesPosted Nov 28, 2012 13:29 UTC (Wed) by pboddie (subscriber, #50784)In reply to: GNU Guix launches by davidescott Parent article: GNU Guix launches
First of all, thanks for keeping the discussion productive and informative. I think that one of the fundamental differences in perspective is related to the following remark: The problem is that the acceptability of applications is defined by the individual policy of the firm. Somehow the package manager has to classify packages in a manner that is consistent with the policy articulated by the firm, allowing the firm to then blacklist/whitelist individual packages as needed. Here, we're talking about more than one organisational role. One matter is what people can do on their workplace machines to do their work in the most convenient and productive way possible without disturbing others or doing bad things to the workplace's systems. Another matter is whether the techniques used are sustainable and documented so that other people in the workplace can follow what was done. In the case of Apache, surely the way to deal with the possibility of someone installing it is to make sure that any instance of it will never be seen from any other computer, which is probably a policy employed in organisations where "high ports" are regarded as completely untrusted. The tools already exist to contain unprivileged users, mostly because that was the motivation for having multi-user/privilege systems in the first place. So it seems to me that forbidding package installation - recalling that I only advocate installation under non-root privileges - is a very coarse way of controlling what users do, and the extent of that control will rely on the existing measures, anyway. (Forbidding the installation of Ruby doesn't stop people from writing "bad" programs unless you take the shell away from them as well.)
(Log in to post comments)
GNU Guix launches Posted Nov 28, 2012 17:13 UTC (Wed) by davidescott (guest, #58580) [Link]
I don't see how we are ever going to agree, because we see something like "running apache on a high port on an internal desktop for internal business purposes" differently.
You view it as developer Joe just wanting to be able to run the server for his own use, and it cannot possibly harm anyone so long as the corporate firewall works.
Management may see it as (a) something that others may come to rely upon and when Joe leaves for another firm someone else has to take over requiring that the code be brought up to the appropriate standards or (b) an internal application that leaks data across business lines and fails to integrate with the standard security policies managed by the firm.
Similarly with installing Inkscape, it could become something that is integrated into a process without approval, such that nobody knows how to manage it when the installer leaves, or could expose the firm to legal risk down the road (those automated charts Joe creates with inkscape are deemed to be deceptive according to Regulation 142.6(a) subsection (iv) paragraph 3.14 which requires that all bar charts have a width of at least 22px). I personally don't like this attitude, but after working in a regulated industry I recognize that it exists.
You are also implicitly suggesting that every machine on the internal network run a firewall that blocks incoming packets on high ports. How many companies actually do this, vs just having a firewall at gateway? It could be a lot of work for network admins to customize the firewall rules to the individuals machine.
I'd also be curious to know how a company like Google handles this kind of situation. Certainly their staff is skilled enough to be able to run personal web-servers, but at the same time someone with a misconfigured server could leak data across the google network.
--------------------------------------------------
A lot of this audit stuff is ridiculous, and I think there is a tacit recognition that it is absurd. Saying that an employee went off an did something on his own without approval makes it possible for the corporation to avoid liability, whereas if you all them to apt-get install something its much less clear that they were violating policy in doing so.
GNU Guix launches Posted Nov 28, 2012 19:59 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
I assume that there would be a way that administrators could disable per-user package installation if wanted. I don't see how the *existence* of the feature is a problem in and of itself. I'd certainly like to be able to install different versions of the boost packages into a local directory so that I don't have to touch Boost.Jam umpteen times to test against everything from 1.44 to the latest release. Or try out the newest shiny (especially with things like newer mesa where if it screws up, I still have a fallback to rely on). without having to upgrade an entire distro (or install an ancient one for older versions).
I would like to have 10 compiler versions installed so that I can test everything with one machine instead of needing 10 VMs of various versions of distros to get those versions and installing things by RPM is a whole lot more reliable than me trying to replicate what is installed in those systems manually.
GNU Guix launches Posted Nov 28, 2012 21:23 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
The issue is that the main case for why this feature is needed is a very close overlap with the cases where it is very questionable due to the reasons mentioned above.
As far as installing multiple compilers, go read Rob Landley's notes of the fun he has doing cross compiles, specifically all the work he has to do to beat gcc into using the right version of things. It sure doesn't look like it would be nearly as trivial as "install multiple copies of gcc in different directories"
If I had to do that, I'd use debbootstrap to create chroot sandboxes with different versions installed in each one. You don't even need containers, let alone VMs.
GNU Guix launches Posted Nov 29, 2012 14:23 UTC (Thu) by pboddie (subscriber, #50784) [Link]
I do actually use debootstrap with chroot sandboxes precisely to be able to manage multiple software environments. However, this only works reliably for genuine chroots and not fakechroots, at least if you want to sample other distribution versions (mostly because of system library incompatibilities), and it gets to the point where you also need a newer kernel version to run significantly newer distribution versions. At that point, I actually use User Mode Linux, but there are plenty of root privilege obstacles that would prevent me from having such a sandbox if I didn't have root access.
Setting up chroot sandboxes isn't really so lightweight, but I suppose it is at the lighter end of the virtualisation spectrum in the broadest sense of the term.
GNU Guix launches Posted Nov 29, 2012 17:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I don't want to install old RPMs as-is; that way does indeed lead down into its own dependency hell. I would like to recompile Fedora 14 RPMs for my current machine and still be able to install it somewhere.
GNU Guix launches Posted Nov 29, 2012 18:00 UTC (Thu) by pboddie (subscriber, #50784) [Link]
I don't do things with RPMs, but if I wanted to build a Debian package for my current distribution version, I guess I'd go through the usual dpkg-buildpackage route (or use pbuilder if I had root access) after tweaking the package metadata. Since I only ever back-port things (and not that often given that I may choose to run them in a chroot), I don't know how much work would actually be necessary to forward-port a package, but quite possibly not that much.
Installing the package is another matter, though. Without root access, I'd have to hope that my fakechroot sandbox is up to the task, but given that it would be the same distribution version, the chances of that are a bit higher than they otherwise might be. I suppose that febootstrap would be able to deliver the same experience for Fedora, potentially not even needing fakechroot to do an initial bootstrap.
GNU Guix launches Posted Nov 29, 2012 17:20 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Hmm…installing a different GCC in macports looks like it just dumped it all in its own subdirectory. I'm not so interested in cross compilers, just different versions of various compilers.
I don't know why GCC would have problems with it unless you used the same $PREFIX for all of them. It's not like GCC would know to look anywhere other than its installation tree and possibly the system. Usually I use $HOME/misc/root/$name-$version as the prefix so that removing one is an rm -rf without having to rely on whatever (usually broken) uninstall mechanisms the project uses. LLVM is certainly happy being installed to $HOME/misc/root/llvm-3.2svn without being confused by the system version.
GNU Guix launches Posted Nov 29, 2012 17:06 UTC (Thu) by davidescott (guest, #58580) [Link]
We aren't objecting to the existence of the feature. If someone wants to implement it that is their right. What we are questioning is the marketability of the feature. It was initially described as a killer feature of Nix, but in my mind Virtualization looks a lot better for a number of different potential use cases. Other than shared hosting (which I don't have a particularly high opinion of to begin with). I'm genuinely curious what use case makes this the killer feature that really sells Nix/Guix.
|
|||||||||||||