COMP 3000 2012 Week 9 Notes: Difference between revisions
moooooar formatting |
I must have been on crack, there was some wierd typos |
||
Line 2: | Line 2: | ||
*Fakeroot fakes root permissions | *Fakeroot fakes root permissions | ||
*Does so by faking a library | *Does so by faking a library when there's a call to libraries. THese ones return root permissions. Messing with Dynamic linker | ||
Messing with Dynamic linker | *We need fakeroot because tar balls save permissions and when they're untarred, these permissions are maintained. | ||
*We need fakeroot because tar | |||
Line 25: | Line 23: | ||
* Oses, though, want to run in Supervisor mode, they're typically designed to be in | * Oses, though, want to run in Supervisor mode, they're typically designed to be in | ||
controll | controll | ||
Two approaches: software and hardware | Two approaches: software and hardware | ||
Line 52: | Line 51: | ||
Desktop Virtualisation | Desktop Virtualisation | ||
* Typical desktop hardware, though, is designed to be used by only OS, so the hypervisor must do tricks. | * Typical desktop hardware, though, is designed to be used by only OS, so the hypervisor must do tricks. | ||
** for example, one OS will set the Videocard registers to one setting, another | ** for example, one OS will set the Videocard registers to one setting, another OS will set them to other settings | ||
OS will set them to other settings | |||
* Desktop hardware is not so virtualizable. | * Desktop hardware is not so virtualizable. | ||
* where not virtualisable, emulate virtualisation. This is what VMware figured out how to do. It emulated support for unvirtualiasable hardware, it did so in software. | * where not virtualisable, emulate virtualisation. This is what VMware figured out how to do. It emulated support for unvirtualiasable hardware, it did so in software. |
Latest revision as of 17:36, 8 November 2012
PACKAGING
- Fakeroot fakes root permissions
- Does so by faking a library when there's a call to libraries. THese ones return root permissions. Messing with Dynamic linker
- We need fakeroot because tar balls save permissions and when they're untarred, these permissions are maintained.
Package management exists on MACOS and windows, but exists more for patching the OS instead of incremental change. The reason they don't have a complicated PKG mangment is because they don't have DEBIAN's distributed development culture. They're more tightly nit, so big changes happen in a less formal, more verbal way.
/var is current state
/var/lib is important state. Don't mess with it
/var/lib/dpkg is where package management state exists. (see status file, status line)
/var/lib/dpkg/info/*.list --lists all files that are installed with a package (dpgk --list <packagename>)
/var/lib/dpkg/info/*.conffile --lists where the overridable conf files are...
VIRTUALISATION
- Convert OS to "Apps" (or app container)
- Oses, though, want to run in Supervisor mode, they're typically designed to be in
controll
Two approaches: software and hardware
Software:
- limited emulations that emulates hardware. Emulation is slow though cause you're simulating hardware. Can reduce to physics emulation.
- we only emulate priviledged operations. For example, interrupts
Hardware virtualisation:
- the "chip" itself is virtualisazing
- the hardware intercepts interrupts and then allows the OS to run on the computer's CPU
Hypervisors
- Hardware is developed know that it will be controlled by multiple masters (OSes)
- Sets Policy on how hardware is shared between OSes
History of hypervisors
- Developed by IBM, in the 60's, for their mainframes.
- Mainframes originally built for batching
- Timeshare was then developed
- During the transition, clients wanted to run their old batching code
- IBM developped hypervisors so that BATCH OS's could be run on the same hardware as the time sharing machine
Desktop Virtualisation
- Typical desktop hardware, though, is designed to be used by only OS, so the hypervisor must do tricks.
- for example, one OS will set the Videocard registers to one setting, another OS will set them to other settings
- Desktop hardware is not so virtualizable.
- where not virtualisable, emulate virtualisation. This is what VMware figured out how to do. It emulated support for unvirtualiasable hardware, it did so in software.
- Modern CPUs support virtualisation though, it lets you catch software interrupts and
redirect them to other OSes
- HW that doesn't have virtualisation support, like some Graphic cards, VMs must emulate them. THis is typically slow.