7 ms·

I dislike this whole trend. How about we start thinking in terms of leaving the user's default environment, and system, alone, and “installing” software into ni

I dislike this whole trend. How about we start thinking in terms of leaving the user's default environment, and system, alone, and “installing” software into nice sandboxed areas where we can easily enable/disable it, or delete it with a simple “rm -rf directory/path”

arjunbajaj 14y ago
I would love to use such a thing! I'm bugged with programs I don't use anymore which start on system boot. Even after removing some programs, they just don't go away. A sandboxed environment would be really good to use!
- jhasse 14y ago
  http://www.gobolinux.org/ http://www.gobolinux.org/ unfortunately it seems to be dead.
- laumars 14y ago
  That's just bad administration as even on Windows, you can easily disable them (msconfig). With Linux, this isn't even an issue unless you're blindly installing dozens of daemons (which, again, can easily be disabled) as Linux doesn't have hundreds of application launchers that install themselves like Windows does (again, daemons being the exception). The only example I can think of where you might run into problems is if your desktop environment is doing some weird sessions. But that's usually fixed pretty easily in the system settings for whatever desktop environment you're running. This is all pretty basic stuff; you shouldn't need a sandboxed environment to prevent applications from auto-launching unless you're going around installing malware (and if you are deliberately installing malware on your main bare-metal OS, then you're insane).
  - nitrogen 14y ago
    This may have been true 5-10 years ago, but modern desktops are removing the ability to manage services, sessions, and startup apps easily and clearly.
    - laumars 14y ago
      Unless they're blocking access to [insert your favourite terminal emulator] and deinstalling su, rm and unlink, then they are not removing any such ability.
    - cmsj 14y ago
      To be fair, some of this is driven by real needs. People want fast boots, so you have to work tightly in parallel. That requires a clear and complex dependency graph. That requires significantly more than some symlinks in /etc/rc?.d/. Also as distros aim to pare down their default installs, you end up in a situation where there is very little that you actually can disable without breaking your ability to boot. Furthermore, given typical CPU/RAM overheads on modern hardware, disabling something that takes a fraction of a second to start and consumes almost no RAM can seem slightly pointless! I'm not familiar with systemd, but upstart takes a similar approach to sysvinit - don't want something to start? Just move it out of /etc/init/ like you would have rm'd the symlink in /etc/rc?.d/ :)
      - nitrogen 14y ago
        I'm referring more to the GUI sessions, startup apps, etc. It seems when I first started using Linux, most of the DEs made it very clear how to edit menu entries, where startup apps were located, what data and apps were restored when a session was restarted... At least in the Ubuntu variants, those options are less obvious.
        cmsj 14y ago
        Ah right, then yeah, that stuff is now pretty opaque and has changed a bunch since the old desktop days.
  - dredmorbius 14y ago
    > With Linux, this isn't even an issue That's a problem systemd is trying very hard to solve. /sarcasm SysV init may be old, crufty, and inelegant, but it's reasonably straightforward to parse and troubleshoot manually (and BSD-style rc inits are even more straightforward). Making the bootstrap process nondeterministic strikes me as tremendously unwise.
    - fein 14y ago
      I agree here. I really enjoyed the explicit control granted by sysV. The switch to systemd just seems like fixing something that isn't broken. I will probably be proved wrong as systemd matures, but right now it's just not the case.
      - laumars 14y ago
        100% both those comments. I used to be a huge ArchLinux fan but them switching away from their rc.conf model to systemd felt like a real kick in the teeth.
        apotheon 14y ago
        Yeah . . . it looks like Arch has gotten to the point where it just kinda violates all the points of the so-called Arch Way wholesale, even worse than the mainstream (supposedly) Unix-like OSes tend to violate the so-called Unix Philosophy these days.
      - apotheon 14y ago
        > I will probably be proved wrong as systemd matures, but right now it's just not the case. Yeah . . . I doubt it. I made the switch to FreeBSD as my primary OS of choice back in 2005 or 2006 without being 100% certain why I decided to try to live on BSD Unix pretty much full-time right then (there were reasons, but I think the timing of the migration was largely whim). I never even missed the Linux world for the next half decade or so. I then tried living with Debian again for a while (long story why), and I discovered that everything of substance that had gone on in the Linux world since then seemed almost tailor-made to annoy the shit out of me. It was a real shock that destroyed the fondness I still harbored for Debian. I poked around at some other Linux distributions I hadn't tried, or handn't used in years, and discovered they were even worse -- and systemd is sorta the apotheosis (no relation) of exactly the sort of nondeterministic, "the software knows better than the user" BS that I remembered with severe loathing from my distant past primarily using (and fixing, for a living) MS Windows. Between Red Hat developers like Drepper and Poettering, the agenda of Canonical and Ubuntu, and the GNU project's strange synthesis of superficially opposed concepts like stagnation and invidious undermining of anything related to the (so-called) Unix philosophy of system design, I ultimately came to the conclusion that outside of a professional capacity (that is, writing code and/or managing servers, and that only if I'm paid) I'm simply not interested in screwing around with Linux-based systems any longer. Your tolerance may be higher than mine but, given your comment about what you dislike about systemd, I rather suspect you'll only grow more frustrated with the direction of Linux development community efforts over time. You might want to think about diversifying your OS experience in the near future (if you haven't already) so you have a place to ready and waiting for you to go when the Linux world has finally pushed you to the point of just wanting to escape.
wulczer 14y ago
Check out http://www.gnu.org/software/stow/ http://www.gnu.org/software/stow/
- duskwuff 14y ago
  Homebrew (http://mxcl.github.io/homebrew/ http://mxcl.github.io/homebrew/) does largely the same thing for third-party source installs on Mac OS X.
rits 14y ago
You can't just enable/disable software if it depends on other software or vice versa. But your package manager may have facilities for that, like Nix [ http://nixos.org/ http://nixos.org/ ].
NelsonMinar 14y ago
To be fair to Homebrew (the example I'm picking on here), it does install to a nice sandboxed area. That area is named "/usr/local", but you can give it its own path and everything works pretty well. (I find I have to completely remove and reinstall Homebrew about every two months, generally because libgettext changed yet again.)
- charlieok 14y ago
  Homebrew is ok, and it has arguably improved the situation on Mac OS X a great deal, but I think we can do better still. Using homebrew, one tweaks recipes in ruby code until they work. Why do we not have a common (and widely adopted!) way for software projects to tell other software how to install/uninstall them, and what other projects they depend on for what particular operations (e.g. configure, build, install, test etc), with reusable data rather than code. Why is (some of) this information captured in bits of ruby, useful for a particular OS X package management system, but not when you want to deploy a similar stack to a IaaS provider where you'll use a different incompatible system like Puppet or Chef to set up the same stuff. I think we have made this whole situation more complicated and fractured than it needs to be.
  - ricardobeat 14y ago
    Code is reusable data, and regardless of language is much more useful than an arbitrary data format. There was an attempt to port homebrew to linux, but it didn't go far. dotCloud has just open-sourced Docker[1], an attempt at solving the deployment issue. [1] http://docker.io http://docker.io
    - Thrall 14y ago
      > There was an attempt to port homebrew to linux, but it didn't go far. Linux already has more package managers than you can shake a stick at. To gain traction on linux, homebrew would have to offer useful features that other package managers don't have. Even then, people are more likely to copy the features into an existing linux package manager. I don't think people tend to shop around when it comes to package managers; you use whatever your distro provides. If it sucks, you find a better distro or submit patches, depending how involved you are.
csense 14y ago
I put all my sensitive files under my home directory. Every subdirectory of my home directory is non-world-accessible, and I have a cron job which chmod's world privileges away from new files and directories that don't match a whitelist of directories I wish to publish (e.g. ~/public_html). I've started giving each application its own user and group, and do the git checkout, compile, and install as that user. (You don't need root for "make install" if you ran configure with the --prefix option.) Then I know it's not going to be able to write anywhere but its own directories, and won't be able to see my browsing activities or sensitive files, because UNIX permissions won't let it. For added security, once the software is built, move it to a location where only root can write, and chown -R root:root. You can also use VM's for added security. With the new namespaces in 3.8 (the kernel for Ubuntu Raring Ringtail), it should (in theory) be safe to let untrusted software have root in a Linux container (LXC). (LXC is like chroot but you can virtualize stuff like the network, and since the guest uses the host's kernel memory allocator, you don't have to dedicate a block of memory to running the guest as you would with Xen or Virtualbox.)
- sliverstorm 14y ago
  It sounds like you really want BSD jails.
- trotsky 14y ago
  It seems like you've been putting a lot of effort in, but posix uid/gid isolation is increasingly pourous with the typical desktop environment these days. It sounds like you are ready for real RBAC - if you put the time in selinux (or apparmor or grsec) is leaps and bounds more effective.
  - sliverstorm 14y ago
    uid/gid is generally a sound system, the problem IMO is basically that no one uses it for serious security, so a lot of things are not set up to be properly careful by default.
    - XorNot 14y ago
peterkelly 14y ago
It's called iOS
thatthatis 14y ago
Like regularly backed up virtual machines?

arjunbajaj 14y ago

I would love to use such a thing! I'm bugged with programs I don't use anymore which start on system boot. Even after removing some programs, they just don't go away. A sandboxed environment would be really good to use!

jhasse 14y ago
http://www.gobolinux.org/ http://www.gobolinux.org/ unfortunately it seems to be dead.
laumars 14y ago
That's just bad administration as even on Windows, you can easily disable them (msconfig). With Linux, this isn't even an issue unless you're blindly installing dozens of daemons (which, again, can easily be disabled) as Linux doesn't have hundreds of application launchers that install themselves like Windows does (again, daemons being the exception). The only example I can think of where you might run into problems is if your desktop environment is doing some weird sessions. But that's usually fixed pretty easily in the system settings for whatever desktop environment you're running. This is all pretty basic stuff; you shouldn't need a sandboxed environment to prevent applications from auto-launching unless you're going around installing malware (and if you are deliberately installing malware on your main bare-metal OS, then you're insane).
- nitrogen 14y ago
  This may have been true 5-10 years ago, but modern desktops are removing the ability to manage services, sessions, and startup apps easily and clearly.
  - laumars 14y ago
    Unless they're blocking access to [insert your favourite terminal emulator] and deinstalling su, rm and unlink, then they are not removing any such ability.
  - cmsj 14y ago
    To be fair, some of this is driven by real needs. People want fast boots, so you have to work tightly in parallel. That requires a clear and complex dependency graph. That requires significantly more than some symlinks in /etc/rc?.d/. Also as distros aim to pare down their default installs, you end up in a situation where there is very little that you actually can disable without breaking your ability to boot. Furthermore, given typical CPU/RAM overheads on modern hardware, disabling something that takes a fraction of a second to start and consumes almost no RAM can seem slightly pointless! I'm not familiar with systemd, but upstart takes a similar approach to sysvinit - don't want something to start? Just move it out of /etc/init/ like you would have rm'd the symlink in /etc/rc?.d/ :)
    - nitrogen 14y ago
      I'm referring more to the GUI sessions, startup apps, etc. It seems when I first started using Linux, most of the DEs made it very clear how to edit menu entries, where startup apps were located, what data and apps were restored when a session was restarted... At least in the Ubuntu variants, those options are less obvious.
      - cmsj 14y ago
        Ah right, then yeah, that stuff is now pretty opaque and has changed a bunch since the old desktop days.
- dredmorbius 14y ago
  > With Linux, this isn't even an issue That's a problem systemd is trying very hard to solve. /sarcasm SysV init may be old, crufty, and inelegant, but it's reasonably straightforward to parse and troubleshoot manually (and BSD-style rc inits are even more straightforward). Making the bootstrap process nondeterministic strikes me as tremendously unwise.
  - fein 14y ago
    I agree here. I really enjoyed the explicit control granted by sysV. The switch to systemd just seems like fixing something that isn't broken. I will probably be proved wrong as systemd matures, but right now it's just not the case.
    - laumars 14y ago
      100% both those comments. I used to be a huge ArchLinux fan but them switching away from their rc.conf model to systemd felt like a real kick in the teeth.
      - apotheon 14y ago
        Yeah . . . it looks like Arch has gotten to the point where it just kinda violates all the points of the so-called Arch Way wholesale, even worse than the mainstream (supposedly) Unix-like OSes tend to violate the so-called Unix Philosophy these days.
    - apotheon 14y ago
      > I will probably be proved wrong as systemd matures, but right now it's just not the case. Yeah . . . I doubt it. I made the switch to FreeBSD as my primary OS of choice back in 2005 or 2006 without being 100% certain why I decided to try to live on BSD Unix pretty much full-time right then (there were reasons, but I think the timing of the migration was largely whim). I never even missed the Linux world for the next half decade or so. I then tried living with Debian again for a while (long story why), and I discovered that everything of substance that had gone on in the Linux world since then seemed almost tailor-made to annoy the shit out of me. It was a real shock that destroyed the fondness I still harbored for Debian. I poked around at some other Linux distributions I hadn't tried, or handn't used in years, and discovered they were even worse -- and systemd is sorta the apotheosis (no relation) of exactly the sort of nondeterministic, "the software knows better than the user" BS that I remembered with severe loathing from my distant past primarily using (and fixing, for a living) MS Windows. Between Red Hat developers like Drepper and Poettering, the agenda of Canonical and Ubuntu, and the GNU project's strange synthesis of superficially opposed concepts like stagnation and invidious undermining of anything related to the (so-called) Unix philosophy of system design, I ultimately came to the conclusion that outside of a professional capacity (that is, writing code and/or managing servers, and that only if I'm paid) I'm simply not interested in screwing around with Linux-based systems any longer. Your tolerance may be higher than mine but, given your comment about what you dislike about systemd, I rather suspect you'll only grow more frustrated with the direction of Linux development community efforts over time. You might want to think about diversifying your OS experience in the near future (if you haven't already) so you have a place to ready and waiting for you to go when the Linux world has finally pushed you to the point of just wanting to escape.

wulczer 14y ago

Check out http://www.gnu.org/software/stow/ http://www.gnu.org/software/stow/

duskwuff 14y ago
Homebrew (http://mxcl.github.io/homebrew/ http://mxcl.github.io/homebrew/) does largely the same thing for third-party source installs on Mac OS X.

rits 14y ago

You can't just enable/disable software if it depends on other software or vice versa. But your package manager may have facilities for that, like Nix [ http://nixos.org/ http://nixos.org/ ].

NelsonMinar 14y ago

To be fair to Homebrew (the example I'm picking on here), it does install to a nice sandboxed area. That area is named "/usr/local", but you can give it its own path and everything works pretty well. (I find I have to completely remove and reinstall Homebrew about every two months, generally because libgettext changed yet again.)

charlieok 14y ago
Homebrew is ok, and it has arguably improved the situation on Mac OS X a great deal, but I think we can do better still. Using homebrew, one tweaks recipes in ruby code until they work. Why do we not have a common (and widely adopted!) way for software projects to tell other software how to install/uninstall them, and what other projects they depend on for what particular operations (e.g. configure, build, install, test etc), with reusable data rather than code. Why is (some of) this information captured in bits of ruby, useful for a particular OS X package management system, but not when you want to deploy a similar stack to a IaaS provider where you'll use a different incompatible system like Puppet or Chef to set up the same stuff. I think we have made this whole situation more complicated and fractured than it needs to be.
- ricardobeat 14y ago
  Code is reusable data, and regardless of language is much more useful than an arbitrary data format. There was an attempt to port homebrew to linux, but it didn't go far. dotCloud has just open-sourced Docker[1], an attempt at solving the deployment issue. [1] http://docker.io http://docker.io
  - Thrall 14y ago
    > There was an attempt to port homebrew to linux, but it didn't go far. Linux already has more package managers than you can shake a stick at. To gain traction on linux, homebrew would have to offer useful features that other package managers don't have. Even then, people are more likely to copy the features into an existing linux package manager. I don't think people tend to shop around when it comes to package managers; you use whatever your distro provides. If it sucks, you find a better distro or submit patches, depending how involved you are.

csense 14y ago

I put all my sensitive files under my home directory. Every subdirectory of my home directory is non-world-accessible, and I have a cron job which chmod's world privileges away from new files and directories that don't match a whitelist of directories I wish to publish (e.g. ~/public_html). I've started giving each application its own user and group, and do the git checkout, compile, and install as that user. (You don't need root for "make install" if you ran configure with the --prefix option.) Then I know it's not going to be able to write anywhere but its own directories, and won't be able to see my browsing activities or sensitive files, because UNIX permissions won't let it. For added security, once the software is built, move it to a location where only root can write, and chown -R root:root. You can also use VM's for added security. With the new namespaces in 3.8 (the kernel for Ubuntu Raring Ringtail), it should (in theory) be safe to let untrusted software have root in a Linux container (LXC). (LXC is like chroot but you can virtualize stuff like the network, and since the guest uses the host's kernel memory allocator, you don't have to dedicate a block of memory to running the guest as you would with Xen or Virtualbox.)

sliverstorm 14y ago
It sounds like you really want BSD jails.
trotsky 14y ago
It seems like you've been putting a lot of effort in, but posix uid/gid isolation is increasingly pourous with the typical desktop environment these days. It sounds like you are ready for real RBAC - if you put the time in selinux (or apparmor or grsec) is leaps and bounds more effective.
- sliverstorm 14y ago
  uid/gid is generally a sound system, the problem IMO is basically that no one uses it for serious security, so a lot of things are not set up to be properly careful by default.
  - XorNot 14y ago

peterkelly 14y ago

It's called iOS

thatthatis 14y ago

Like regularly backed up virtual machines?