I've been using VirtualBox a lot recently, and I've been pretty impressed with it - running more than one simultaneous machine, setting up an internal network and running ansible between them, nifty. Today at work we had an interesting discussion about Digital Ocean: the suggestion was made (and undoubtedly it's obvious to many on this list, but it was eye-opening to me, I'm still getting my head around disposable machines) that if you weren't sure an upgrade to a droplet would work, just clone it, do the upgrade on the clone and see how it goes. Then you can make your decision and destroy the unwanted version. All of which made me think "wouldn't it be cool if I could have a system with an totally stripped Linux with VirtualBox as the "Window Manager" so I could toggle between two or three running OSes with graphical interfaces ..." So: http://en.wikipedia.org/wiki/Operating_system-level_virtualization_implement... I've already ruled out OpenVZ as it looks like all virtualized systems have to use the same kernel. Xen seems like the optimal method, but I seem to remember that your processor specifically has to support virtualization ("lscpu" says, among other things, "Virtualization: VT-x", so I'm covered?) Assuming I want the base OS (does that term even apply?) to be Linux, and I don't like proprietary software, what's the "best choice" if I want to simultaneously run things like Debian Jessie, TinyCore, SliTaz, and possibly even Windows 7? Links to good tutorials and "Getting Started" guides would also be very much appreciated. -- Giles http://www.gilesorr.com/ gilesorr@gmail.com
On 04/21/2015 09:45 PM, Giles Orr wrote:
with VirtualBox as the "Window Manager" so I could toggle between two or three running OSes with graphical interfaces ...
FWIW, I have VirtualBox on my openSUSE 13.1 notebook. I have installed VMs for Windows 10, Windows 98 and OS/2 Warp 4. I can switch among them and back to Linux. The VMs run full screen and to look at them, you wouldn't know you were in a VM. On my desktop system, I have Windows 7 & 10 in VMs.
On Tue, Apr 21, 2015 at 9:45 PM, Giles Orr <gilesorr@gmail.com> wrote: <snip>
Assuming I want the base OS (does that term even apply?) to be Linux, and I don't like proprietary software, what's the "best choice" if I want to simultaneously run things like Debian Jessie, TinyCore, SliTaz, and possibly even Windows 7?
Links to good tutorials and "Getting Started" guides would also be very much appreciated.
I've not tried it yet (it's on my todo list) but you might have a look at Qubes OS. May not be exactly what you're looking for but it's the closest that I can think of (aside from VirtualBox et al). If it's possible to run docker (perhaps via subuser)* under Qubes, you might be able to have your cake and eat it too. <https://www.qubes-os.org/> Best, - Scott. * Additional links <https://www.docker.com/> <http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/> <http://subuser.org/> -- Scott Elcomb @psema4 http://psema4.com/pubkey.txt http://www.pirateparty.ca/
On 04/21/2015 09:45 PM, Giles Orr wrote:
Today at work we had an interesting discussion about Digital Ocean: the suggestion was made (and undoubtedly it's obvious to many on this list, but it was eye-opening to me, I'm still getting my head around disposable machines) that if you weren't sure an upgrade to a droplet would work, just clone it, do the upgrade on the clone and see how it goes. Then you can make your decision and destroy the unwanted version. ... I've already ruled out OpenVZ as it looks like all virtualized systems have to use the same kernel. On Solaris, we did tons with very-lightweight VMs, using code for security isolation that could create "containers" that looked just like machines.
The only limitation was the common OS version, and you could be ahead of the evrsion in userspace stuff like shared libraries. We rarely found cases where we wanted a different OS, just some where we wanted to emulate an older one. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
You may want to check out Proxmox, i use it for the cloud as VM env., it is amazing!, not sure how it would work however on strictly a desktop environment. It is free, even though it bugs you to sign up for support. -tl On Wed, Apr 22, 2015 at 11:43 AM, David Collier-Brown <davec-b@rogers.com> wrote:
On 04/21/2015 09:45 PM, Giles Orr wrote:
Today at work we had an interesting discussion about Digital Ocean: the suggestion was made (and undoubtedly it's obvious to many on this list, but it was eye-opening to me, I'm still getting my head around disposable machines) that if you weren't sure an upgrade to a droplet would work, just clone it, do the upgrade on the clone and see how it goes. Then you can make your decision and destroy the unwanted version.
...
I've already ruled out OpenVZ as it looks like all virtualized systems have to use the same kernel.
On Solaris, we did tons with very-lightweight VMs, using code for security isolation that could create "containers" that looked just like machines.
The only limitation was the common OS version, and you could be ahead of the evrsion in userspace stuff like shared libraries. We rarely found cases where we wanted a different OS, just some where we wanted to emulate an older one.
--dave
-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
--- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
| From: Giles Orr <gilesorr@gmail.com> | I've been using VirtualBox a lot recently, and I've been pretty | impressed with it - running more than one simultaneous machine, | setting up an internal network and running ansible between them, | nifty. It is a neat trick. But what is it useful for? Clearly it is great to be able to run different OSes if you need to run more than one. For example, to be able to run MS Word when you mostly want to run Linux. Or to test on multiple platforms. In the Libreswan project, we use virtualization to test networking software. Since some of the code is in the OS, we at least sometimes have to run different OSes. But most of virtualization seems to be for other purposes. | Today at work we had an interesting discussion about Digital | Ocean: the suggestion was made (and undoubtedly it's obvious to many | on this list, but it was eye-opening to me, I'm still getting my head | around disposable machines) that if you weren't sure an upgrade to a | droplet would work, just clone it, do the upgrade on the clone and see | how it goes. Then you can make your decision and destroy the unwanted | version. Yeah, that (sadly) is a good use case. But surely a proper package management system would let you do this too. - allow more than one version of a package to be installed - allow more than one instance of the same package, but with different global configuration. Perhaps global configuration is evil. - allow package dependencies to contol which versions of each package talk to each other. For example, if A talks to B, under some conditions, old A should talk to old B - make sure that distinct package's configurations don't affect each other. Example: two different packages that use Apache; they should not configure Apache in ways that conflict. - job migration between machines, even while running, seems useful. (That's not a package management problem.) One step more towards virtualization: Jails are minimal and may be good enough but a lot cheaper than supporting true virtual x86 machines. | All of which made me think "wouldn't it be cool if I could | have a system with an totally stripped Linux with VirtualBox as the | "Window Manager" so I could toggle between two or three running OSes | with graphical interfaces ..." So: I think that Serious VMware products are stripped Linux systems that can run VMs without a lot of extras. I think that Zen Dom0 (host) can be minimal too. So much of the noise this day is about things like Docker and CoreOS. A lot feels like branding exercises rather than technology. I find it too hard to figure out what they actually are.
Yeah, that (sadly) is a good use case. But surely a proper package management system would let you do this too.
- allow more than one version of a package to be installed
- allow more than one instance of the same package, but with different global configuration. Perhaps global configuration is evil.
- allow package dependencies to contol which versions of each package talk to each other. For example, if A talks to B, under some conditions, old A should talk to old B
- make sure that distinct package's configurations don't affect each other. Example: two different packages that use Apache; they should not configure Apache in ways that conflict.
I think Red Hat's software collections are supposed to do that: https://www.softwarecollections.org On 22 April 2015 at 17:24, D. Hugh Redelmeier <hugh@mimosa.com> wrote:
| From: Giles Orr <gilesorr@gmail.com>
| I've been using VirtualBox a lot recently, and I've been pretty | impressed with it - running more than one simultaneous machine, | setting up an internal network and running ansible between them, | nifty.
It is a neat trick.
But what is it useful for?
Clearly it is great to be able to run different OSes if you need to run more than one. For example, to be able to run MS Word when you mostly want to run Linux. Or to test on multiple platforms.
In the Libreswan project, we use virtualization to test networking software. Since some of the code is in the OS, we at least sometimes have to run different OSes.
But most of virtualization seems to be for other purposes.
| Today at work we had an interesting discussion about Digital | Ocean: the suggestion was made (and undoubtedly it's obvious to many | on this list, but it was eye-opening to me, I'm still getting my head | around disposable machines) that if you weren't sure an upgrade to a | droplet would work, just clone it, do the upgrade on the clone and see | how it goes. Then you can make your decision and destroy the unwanted | version.
Yeah, that (sadly) is a good use case. But surely a proper package management system would let you do this too.
- allow more than one version of a package to be installed
- allow more than one instance of the same package, but with different global configuration. Perhaps global configuration is evil.
- allow package dependencies to contol which versions of each package talk to each other. For example, if A talks to B, under some conditions, old A should talk to old B
- make sure that distinct package's configurations don't affect each other. Example: two different packages that use Apache; they should not configure Apache in ways that conflict.
- job migration between machines, even while running, seems useful. (That's not a package management problem.)
One step more towards virtualization:
Jails are minimal and may be good enough but a lot cheaper than supporting true virtual x86 machines.
| All of which made me think "wouldn't it be cool if I could | have a system with an totally stripped Linux with VirtualBox as the | "Window Manager" so I could toggle between two or three running OSes | with graphical interfaces ..." So:
I think that Serious VMware products are stripped Linux systems that can run VMs without a lot of extras.
I think that Zen Dom0 (host) can be minimal too.
So much of the noise this day is about things like Docker and CoreOS. A lot feels like branding exercises rather than technology. I find it too hard to figure out what they actually are. --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
I am thinking of moving off Debian/Mint-DE, to Nixos linux for this type of flexibility. -tl On Wed, Apr 22, 2015 at 5:40 PM, Peter Platek <peterplatek@gmail.com> wrote:
Yeah, that (sadly) is a good use case. But surely a proper package management system would let you do this too.
- allow more than one version of a package to be installed
- allow more than one instance of the same package, but with different global configuration. Perhaps global configuration is evil.
- allow package dependencies to contol which versions of each package talk to each other. For example, if A talks to B, under some conditions, old A should talk to old B
- make sure that distinct package's configurations don't affect each other. Example: two different packages that use Apache; they should not configure Apache in ways that conflict.
I think Red Hat's software collections are supposed to do that:
https://www.softwarecollections.org
On 22 April 2015 at 17:24, D. Hugh Redelmeier <hugh@mimosa.com> wrote:
| From: Giles Orr <gilesorr@gmail.com>
| I've been using VirtualBox a lot recently, and I've been pretty | impressed with it - running more than one simultaneous machine, | setting up an internal network and running ansible between them, | nifty.
It is a neat trick.
But what is it useful for?
Clearly it is great to be able to run different OSes if you need to run more than one. For example, to be able to run MS Word when you mostly want to run Linux. Or to test on multiple platforms.
In the Libreswan project, we use virtualization to test networking software. Since some of the code is in the OS, we at least sometimes
have
to run different OSes.
But most of virtualization seems to be for other purposes.
| Today at work we had an interesting discussion about Digital | Ocean: the suggestion was made (and undoubtedly it's obvious to many | on this list, but it was eye-opening to me, I'm still getting my head | around disposable machines) that if you weren't sure an upgrade to a | droplet would work, just clone it, do the upgrade on the clone and see | how it goes. Then you can make your decision and destroy the unwanted | version.
Yeah, that (sadly) is a good use case. But surely a proper package management system would let you do this too.
- allow more than one version of a package to be installed
- allow more than one instance of the same package, but with different global configuration. Perhaps global configuration is evil.
- allow package dependencies to contol which versions of each package talk to each other. For example, if A talks to B, under some conditions, old A should talk to old B
- make sure that distinct package's configurations don't affect each other. Example: two different packages that use Apache; they should not configure Apache in ways that conflict.
- job migration between machines, even while running, seems useful. (That's not a package management problem.)
One step more towards virtualization:
Jails are minimal and may be good enough but a lot cheaper than supporting true virtual x86 machines.
| All of which made me think "wouldn't it be cool if I could | have a system with an totally stripped Linux with VirtualBox as the | "Window Manager" so I could toggle between two or three running OSes | with graphical interfaces ..." So:
I think that Serious VMware products are stripped Linux systems that can run VMs without a lot of extras.
I think that Zen Dom0 (host) can be minimal too.
So much of the noise this day is about things like Docker and CoreOS. A lot feels like branding exercises rather than technology. I find it too hard to figure out what they actually are. --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
On Wed, Apr 22, 2015 at 05:43:27PM -0400, ted leslie wrote:
I am thinking of moving off Debian/Mint-DE, to Nixos linux for this type of flexibility.
Of course you trade it for the annoyance of being not compatible with any standard linux binary. Everything ahs to be wrapped in environment settings to find the ld-linux.so and otehr things, because NOTHING is in the places that they are supposed to be. So interesting design, but it comes at the expense of total incompatibility with everything that already exists. It can be worked around though. -- Len Sorensen
On 23 April 2015 at 10:34, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
On Wed, Apr 22, 2015 at 05:43:27PM -0400, ted leslie wrote:
I am thinking of moving off Debian/Mint-DE, to Nixos linux for this type of flexibility.
Of course you trade it for the annoyance of being not compatible with any standard linux binary. Everything ahs to be wrapped in environment settings to find the ld-linux.so and otehr things, because NOTHING is in the places that they are supposed to be.
So interesting design, but it comes at the expense of total incompatibility with everything that already exists. It can be worked around though.
It seems a little late to retitle this as being about NixOS, although I'm going to address that. But since I'm not retitling, first off: thanks everyone who replied about virtualization, this has been educational. As for NixOS - after Jamon's mention of it a couple months ago, I played with it for a bit and wrote up a rough review at http://www.gilesorr.com/blog/nixos-review.html Some points for those who don't bother to follow the link: - /bin/rm doesn't exist. "rm" does, and it's on the PATH, but imagine how many scripts that breaks. - vi isn't installed by default. this is a 838MB compressed image they provided, and they didn't include the POSIX standard browser? It's available as a package though. - if a package is installed at the system level, the package manager will still happily install the same package for an individual user. Think about this last point: the user will now be using their own version of the package. System-wide security updates are totally out the window. I see the flexibility NixOS offers, but I think the price is too high. -- Giles http://www.gilesorr.com/ gilesorr@gmail.com
On Thu, Apr 23, 2015 at 12:18:08PM -0400, Giles Orr wrote:
It seems a little late to retitle this as being about NixOS, although I'm going to address that. But since I'm not retitling, first off: thanks everyone who replied about virtualization, this has been educational.
As for NixOS - after Jamon's mention of it a couple months ago, I played with it for a bit and wrote up a rough review at http://www.gilesorr.com/blog/nixos-review.html
Some points for those who don't bother to follow the link: - /bin/rm doesn't exist. "rm" does, and it's on the PATH, but imagine how many scripts that breaks. - vi isn't installed by default. this is a 838MB compressed image they provided, and they didn't include the POSIX standard browser? It's available as a package though. - if a package is installed at the system level, the package manager will still happily install the same package for an individual user.
Think about this last point: the user will now be using their own version of the package. System-wide security updates are totally out the window.
I see the flexibility NixOS offers, but I think the price is too high.
It is an interesting design that is trying to solve one problem, but does so by creating a bunch of other ones. It is not a tradeoff I would be willing to take. Certainly the problem it is trying to solve is not one that has ever really been an issue for me (the few times I have had a reason to use another version of something, I have installed it in a small chroot running an appropriate version of the distribution to run that version). -- Len Sorensen
| From: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> | Certainly the problem it is trying to solve is not one that has ever | really been an issue for me (the few times I have had a reason to use | another version of something, I have installed it in a small chroot | running an appropriate version of the distribution to run that version). Me too, I think. Sometimes "systems" get stuck on old versions of Linux (let's forget other OSes for now). Why do they get stuck? I think that they are working and changing to a new distro release has a significant chance of destabalizing them. Maybe the process to actually configure the old system is lost. But you don't want everything in your organization stuck at that old version. So you end up with a diverse set of versions. They cannot normally live on one box. The cure is virtualization or some other trick. This all seems wrong, but all too understandable. (I have a couple of boxes still running RHL 8.0 from 2002.) So what are the correct solutions? - RHEL has something like 10 year stability for each release. Ubuntu has LTS. This allows you to safely ignore the problem for a decade. By which time it is enormous! But of course they don't force you to ignore the problem. - keeping up with the rat-race of rolling updates is noble but probably wasteful. It is the opposite approach to LTS. - virtualization allows you to put off the problem for a long long time. But it doesn't address vulnerabilities in no-longer-supported distros. - For me, running a virtual copy of an ancient system let me avoid buying a new license when the old machine wasn't worth running any longer. - NixOS would seem to address this. Is that its justification? What do real businesses do? What should they do?
snip
- For me, running a virtual copy of an ancient system let me avoid buying a new license when the old machine wasn't worth running any longer.
- NixOS would seem to address this. Is that its justification?
What do real businesses do? What should they do? ---
There is an important subset of computing out there that does something rather interesting with this. Machine tools run old versions of Windows. I'm not in the field at present but I know that not too many years ago it was like DOS was still alive and a small subset of the available control software ran on a Windows system. Likely things have moved forward somewhat but when I was working on things the software was at least 15 if not 20 years behind. Many large businesses are still running on NT 3.51 (IIRC (the version numbers)). When you are at your bank look at the screen - - - its Win XP. If the software does what you want it to do why change for the newer - - - big business has always done that. I'm very much of the opinion what change for changes sake is a waste of effort. Dee
On 22/04/15 05:24 PM, D. Hugh Redelmeier wrote:
Yeah, that (sadly) is a good use case. But surely a proper package management system would let you do this too.
- allow more than one version of a package to be installed
- allow more than one instance of the same package, but with different global configuration. Perhaps global configuration is evil.
- allow package dependencies to contol which versions of each package talk to each other. For example, if A talks to B, under some conditions, old A should talk to old B
- make sure that distinct package's configurations don't affect each other. Example: two different packages that use Apache; they should not configure Apache in ways that conflict.
- job migration between machines, even while running, seems useful. (That's not a package management problem.)
NixOS addresses quite a few of these. Each version of a package is built into its own unique prefixed environment, and each build can have its own env variables set. You're free to switch between versions on your system as well. Essentially it is a distro that is built using pointers to individual packages' git commit ids. Cheers, Jamon http://nixos.org/nixos/about.html - see How does NixOS work?
On 22/04/15 05:44 PM, Jamon Camisso wrote:
NixOS addresses quite a few of these. Each version of a package is built into its own unique prefixed environment, and each build can have its own env variables set. You're free to switch between versions on your system as well.
Essentially it is a distro that is built using pointers to individual packages' git commit ids.
Replying to myself - that part isn't accurate. The package manager deals with where the upstream source is found. http://nixos.org/nixpkgs/ Cheers, Jamon
| From: D. Hugh Redelmeier <hugh@mimosa.com> | So much of the noise this day is about things like Docker and CoreOS. | A lot feels like branding exercises rather than technology. I find it | too hard to figure out what they actually are. I guess that Ubuntu Snappy is something like this. I gave up figuring out what it is after a couple of minutes of reading marketing. <http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-15.10-DEB-To-Snap>
participants (10)
-
D. Hugh Redelmeier -
David Collier-Brown -
Giles Orr -
James Knott -
Jamon Camisso -
Lennart Sorensen -
o1bigtenor -
Peter Platek -
Scott Elcomb -
ted leslie