COMP 3000 2012 Week 9 Notes - Revision history

Cdelahou: I must have been on crack, there was some wierd typos

2012-11-08T17:36:11Z

I must have been on crack, there was some wierd typos

← Older revision		Revision as of 17:36, 8 November 2012
Line 2:		Line 2:

	*Fakeroot fakes root permissions		*Fakeroot fakes root permissions
	*Does so by faking a library ~~the called~~ libraries. THese ones return root permissions		*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 ~~feels~~ save permissions


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.

Cdelahou: moooooar formatting

2012-11-08T17:32:10Z

moooooar formatting

← Older revision		Revision as of 17:32, 8 November 2012
Line 8:		Line 8:


	Package management exists on MACOS and windows, but exists more for patching the OS		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.
	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.


Line 18:		Line 15:
	/var/lib/dpkg is where package management state exists. (see status file, status line)		/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		/var/lib/dpkg/info/*.list --lists all files that are installed with a package (dpgk --list <packagename>)
	--list <packagename>)

	/var/lib/dpkg/info/*.conffile --lists where the overridable conf files are...		/var/lib/dpkg/info/*.conffile --lists where the overridable conf files are...
Line 31:		Line 27:

	Two approaches: software and hardware		Two approaches: software and hardware


	Software:		Software:
	* limited emulations that emulates hardware. Emulation is slow though cause you're		* limited emulations that emulates hardware. Emulation is slow though cause you're simulating hardware. Can reduce to physics emulation.
	simulating hardware. Can reduce to physics emulation.
	* we only emulate priviledged operations. For example, interrupts		* we only emulate priviledged operations. For example, interrupts

	Hardware virtualisation:		Hardware virtualisation:
	* the "chip" itself is virtualisazing		* the "chip" itself is virtualisazing
	* the hardware intercepts interrupts and then allows the OS to run on the		* the hardware intercepts interrupts and then allows the OS to run on the computer's CPU
	computer's CPU

	Hypervisors		Hypervisors
Line 53:		Line 48:
	* Timeshare was then developed		* Timeshare was then developed
	* During the transition, clients wanted to run their old batching code		* 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		* IBM developped hypervisors so that BATCH OS's could be run on the same hardware as the time sharing machine
	the time sharing machine

	Desktop Virtualisation		Desktop Virtualisation
	* Typical desktop hardware, though, is designed to be used by only OS, so the		* Typical desktop hardware, though, is designed to be used by only OS, so the hypervisor must do tricks.
	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		* 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.
	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		* Modern CPUs support virtualisation though, it lets you catch software interrupts and
	redirect them to other OSes		redirect them to other OSes
	* HW that doesn't have virtualisation support, like some Graphic cards, VMs must		* HW that doesn't have virtualisation support, like some Graphic cards, VMs must emulate them. THis is typically slow.
	emulate them. THis is typically slow.

Cdelahou: formatting

2012-11-08T17:29:42Z

formatting

← Older revision		Revision as of 17:29, 8 November 2012
Line 1:		Line 1:
	PACKAGING		== PACKAGING ==

	*Fakeroot fakes root permissions		*Fakeroot fakes root permissions
Line 24:		Line 24:


	VIRTUALISATION		== VIRTUALISATION ==

	* Convert OS to "Apps" (or app container)		* Convert OS to "Apps" (or app container)
Line 32:		Line 32:
	Two approaches: software and hardware		Two approaches: software and hardware

	~~Softare~~:		Software:
	* limited emulations that emulates hardware. Emulation is slow though cause you're		* limited emulations that emulates hardware. Emulation is slow though cause you're
	simulating hardware. Can reduce to physics emulation.		simulating hardware. Can reduce to physics emulation.
	* we only emulate priviledged operations. For example, interrupts		* we only emulate priviledged operations. For example, interrupts

	Hardware virtualisation:		Hardware virtualisation:
	* the "chip" itself is virtualisazing		* the "chip" itself is virtualisazing
	* the hardware intercepts interrupts and then allows the OS to run on the		* the hardware intercepts interrupts and then allows the OS to run on the
	computer's CPU		computer's CPU

Cdelahou: added initial notes.

2012-11-07T17:56:23Z

added initial notes.

New page

PACKAGING

*Fakeroot fakes root permissions
*Does so by faking a library the called libraries. THese ones return root permissions
Messing with Dynamic linker

*We need fakeroot because tar feels save permissions

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

Softare:
* 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.