COSI History And Some Other Stuff
Ryan Lewis and I went exploring today after bringing some VR equipment back to the lab. We ended up looking at the SC450, 452, 454 rooms which are practically hidden at the very top of two science center stairwells. Apparently they have been used for many things through out the years including grad offices, COSI room, ACM room, and, of course, bathrooms! Also, back in the day we had a VAX machine in one of the labs. Once they switched from batch computers to interactive computers they had a day of throwing the computers off the science center roof. Perhaps all of this history would make for a good COSI presentation, and even include some of it in open house presentations. Of course this would require some interviews with older faculty members and exploration of all the material that is currently holed up in the rooms. Possibly a discussion of Old Snell is in line as well.
Okay, it wasn't all about history though. I read about a couple technologies, SE Linux and stateless linux. A key idea in SE Linux is that you can't expect applications to be secure if your operating system is insecure. So a necessary step is to integrate MAC(Mandatory Access Control) into the operating system. A MAC-enabled system would need the "ability to enforce an administratively-set security policy over all subjects and objects in the system." This is different than DAC (Discretionary Access Control) for obvious reasons. I didn't read too far into this though. Basically, they want a policy that limits all applications to exactly what they require to function. Thus there would be more security requirements for each program than user, group, other and read, write, execute. This way if there was an exploit into the system through this program, a hacker could only mess with a very limited amount of the system. I was hoping for something really new or interesting, oh well.
Stateless linux is a bit more interesting though. In the past there's been mainly two kinds of clients, thin and fat. Thin clients aare formed when a central computer runs the operating system for its client machines. Thus, local machines don't run any of their own programs and don't require a harddrive. Fat clients are formed when most of the data and programs required are stored on the local machine and most processing is done on the local machien. Red Hat attempted to reach a compromise between these. Stateless Linux has a main server that contains the operating system and systemwide configuration files. The server distributes these files to all of the lab machines as read-only. Thus, users will have their own operating system in memory and will use their own processors to do the work, but won't necessarily have to save any files to the local file system. This should ease the burden of maintaining a large computer lab. You only have to change one instance of the operating system to change them all, but there isn't a tremendous load on the main server. Perhaps I'll look into this a bit more in depth at a later date.
One thing that I noticed is in the past couple of years, which is all the time I've known linux for, there haven't been many truly novel, unique ideas. Usually people innovate older technology and find new applications. I suppose that's the nature of any field though. When it's new the discoveries come very quickly and slope off with time. Or maybe I'm just not looking hard enough because of course they will be switching to photonic circuits in a couple decades. They are researching quantum computing. Organic computers have been researched as well, though probably for way down the road. So who knows ... no really, who knows???
Also, in the past few months I've been trying to learn about the 2.6 Linux kernel by reading Robert Love's kernel development book and recently reading some of the source code. Learning about all of these internals is fascinating, but reading the 1000s of lines of code is a little difficult, though probably worth while. One thing I noticed is that the kernel uses a lot of features that are dependent on the GNU gcc compiler. One interesting feature of GNU gcc is __attribute__(). This function has many purposes. One is if the only argument of __attribute__ is (constructor), then that function will be run before main is started. If the argument is (destructor), then the program will be run after main has returned. An example of the code is:
####################################################
static void foo () __attribute__ ((constructor));
static void bar () __attribute__ ((destructor));
static void
foo ()
{
}
static void
bar ()
{
}
####################################################
There are many more capablities of this feature. Just one more example of a neat feature in gcc is the ability to have function definitions that accept a variable amount of parameters. The main lesson from my first attempt at the kernel code is that in order to know the code you first need to know the compiler well, C REALLY well, and a bit of assembly. To read more about the gcc compiler just use "info gcc". Note: one useful term to know when looking this kind of thing up on the internet is ELF, Executable and Linkable Format.
Oh, and a project I'm thinking of undertaking some day is a suite of interactive, highly graphical, in depth teaching modules for the Linux kernel. I learn best with pictures and interactivity. Graphical representations are not readily available when learning about the internals of operating systems.
Okay, it wasn't all about history though. I read about a couple technologies, SE Linux and stateless linux. A key idea in SE Linux is that you can't expect applications to be secure if your operating system is insecure. So a necessary step is to integrate MAC(Mandatory Access Control) into the operating system. A MAC-enabled system would need the "ability to enforce an administratively-set security policy over all subjects and objects in the system." This is different than DAC (Discretionary Access Control) for obvious reasons. I didn't read too far into this though. Basically, they want a policy that limits all applications to exactly what they require to function. Thus there would be more security requirements for each program than user, group, other and read, write, execute. This way if there was an exploit into the system through this program, a hacker could only mess with a very limited amount of the system. I was hoping for something really new or interesting, oh well.
Stateless linux is a bit more interesting though. In the past there's been mainly two kinds of clients, thin and fat. Thin clients aare formed when a central computer runs the operating system for its client machines. Thus, local machines don't run any of their own programs and don't require a harddrive. Fat clients are formed when most of the data and programs required are stored on the local machine and most processing is done on the local machien. Red Hat attempted to reach a compromise between these. Stateless Linux has a main server that contains the operating system and systemwide configuration files. The server distributes these files to all of the lab machines as read-only. Thus, users will have their own operating system in memory and will use their own processors to do the work, but won't necessarily have to save any files to the local file system. This should ease the burden of maintaining a large computer lab. You only have to change one instance of the operating system to change them all, but there isn't a tremendous load on the main server. Perhaps I'll look into this a bit more in depth at a later date.
One thing that I noticed is in the past couple of years, which is all the time I've known linux for, there haven't been many truly novel, unique ideas. Usually people innovate older technology and find new applications. I suppose that's the nature of any field though. When it's new the discoveries come very quickly and slope off with time. Or maybe I'm just not looking hard enough because of course they will be switching to photonic circuits in a couple decades. They are researching quantum computing. Organic computers have been researched as well, though probably for way down the road. So who knows ... no really, who knows???
Also, in the past few months I've been trying to learn about the 2.6 Linux kernel by reading Robert Love's kernel development book and recently reading some of the source code. Learning about all of these internals is fascinating, but reading the 1000s of lines of code is a little difficult, though probably worth while. One thing I noticed is that the kernel uses a lot of features that are dependent on the GNU gcc compiler. One interesting feature of GNU gcc is __attribute__(). This function has many purposes. One is if the only argument of __attribute__ is (constructor), then that function will be run before main is started. If the argument is (destructor), then the program will be run after main has returned. An example of the code is:
####################################################
static void foo () __attribute__ ((constructor));
static void bar () __attribute__ ((destructor));
static void
foo ()
{
}
static void
bar ()
{
}
####################################################
There are many more capablities of this feature. Just one more example of a neat feature in gcc is the ability to have function definitions that accept a variable amount of parameters. The main lesson from my first attempt at the kernel code is that in order to know the code you first need to know the compiler well, C REALLY well, and a bit of assembly. To read more about the gcc compiler just use "info gcc". Note: one useful term to know when looking this kind of thing up on the internet is ELF, Executable and Linkable Format.
Oh, and a project I'm thinking of undertaking some day is a suite of interactive, highly graphical, in depth teaching modules for the Linux kernel. I learn best with pictures and interactivity. Graphical representations are not readily available when learning about the internals of operating systems.
