SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm kinda on the fence with multilib, I have no problem setting up multilib myself, but perhaps at one point during the installation there should be an option to add multilib to the system, or maybe the best option is to have have a multilib in /extra.
Actually /extra might be the best option IMHO.
I hate to repeat myself. Please re-read my earlier post.
TobiSGD, you can run X apps including games and the like as long as you completely trust the container. You need to pass a good deal of raw device access through to make it work.
lxc.arch = i686
lxc.utsname = macro86
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = vth0
lxc.network.ipv4 = 0.0.0.0/24
lxc.network.name = vth0
lxc.mount = /var/lib/lxc/macro86/rootfs/etc/fstab
lxc.tty = 2
lxc.pts = 1024
lxc.rootfs = /var/lib/lxc/macro86/rootfs
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 226:* rwm
lxc.cgroup.devices.allow = c 13:* rwm
lxc.cgroup.devices.allow = c 14:* rwm
lxc.cgroup.devices.allow = c 116:* rwm
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm
#lxc.cgroup.devices.allow = c 4:2 rwm
lxc.cgroup.devices.allow = c 4:3 rwm
lxc.cgroup.devices.allow = c 4:4 rwm
lxc.cgroup.devices.allow = c 4:5 rwm
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
lxc.cgroup.devices.allow = c 254:0 rwm
# we don't trust root user in the container, better safe than sorry.
# comment out only if you know what you're doing.
lxc.cap.drop = sys_module mknod
lxc.cap.drop = mac_override kill sys_time
lxc.cap.drop = setfcap setpcap sys_boot
# if you want to be even more restrictive with your container's root
# user comment the three lines above and uncomment the following one
I also reduce the number of gettys running on the host in /etc/inittab on both the host and the contain filesystem, this way I can access the container on vttys 3 and 4.
And the fstab from the container so you can get an idea of what other file system parts are being shared.
Obviously with all this stuff shared the container does little to protect the host from misbehavior going on. You will need all the X libraries and whatnot on the container rootfs, and I have been unable to get things to work anything short of "xhost +" run on the host but if you start an X app as the same user inside the x86 container it will use the host's X server. I play a few games under WINE this way. The host is 64-bit no multilib.
I do get accelerated openGL, but I am using intel graphics you might have to pass other devices through to get AMD/NVIDIA video hardware to work full, can't say. I am also not sure how 'safe' this is in terms of stability all I can say is *I* haven't had any problems.
I have no experience with LXC containers, so this looks rather complicated to me. Do you have a link to a good tutorial about LXC?
I think this might only be handy to run 32 bit games, but also to set up conatiners with older OSes for old games that won't run anymore on modern distros.
Using containers to directly share X as I have done with this is kludgy at best. The easiest way to get started with LXC on Slackware is to grab Ponce's stuff and adapt it to your needs from there. He has put lots of work into it and it works well.
Keep in mind containers are not VMs, they basically create discrete name spaces within the kernel. So those "older OSs" will need to be A) Linux and B) new enough to run on whatever kernel your host is using. That can be older than you might at first guess though because you won't run udev and things like the modinit tools inside the container.
I currently have Alien Bob's cups-compat32-1.5.4-x86_64-2.txz and glibc-solibs-2.17_multilib-x86_64-5alien.txz packages installed on my otherwise pure 64-bit system to support a printer with a 32-bit driver.
I have not used WINE in a long time, preferring to run Windows software either natively in a multiboot system or in a QEMU virtual machine.
Very likely your hardware is capable of running skype without noticable slowdown in a virtual machine.
I consider this from time to time. It seems a bit extreme though, all things considered. I then need VM and a full installation of another distribution (be it Slackware or something else) just to run something that only needed a few extra libraries. If Slackware64 wasn't multilib ready, I might have done it this way as it would need a fair bit more tinkering to set up.