I still have some files from 1973 of BASIC programs that I wrote on punched tape. They seemed "fine" the last time I looked (within a couple of years). I'm sure I could scan them and OCR them if I had to, and I still have access to a teletype if I really wanted it (though I'd have to make a current-loop to RS-232 converter). HOWEVER -- you can just look at the tape and copy the data, if you REALLY need to. Tedious, but possible...
Get the MS. It will never be easier or cheaper. Both a BS and an MS are simply credentials that prevent your resume from being rejected early. Where I currently work, they don't consider candidates without an MS. Play the game, get the degree. Make contacts, never burn bridges...
First linux I downloaded was early 1.x Slackware. Many floppies. The first I recall messing with was Yggdrasil. I ran minix on my Atari ST at the time, and UNIX at work so got my *nix fix there. When I bought an x86 machine for home, I started with NetBSD 0.9, then FreeBSD 1.*, 2.*,OS/2 Merlin, Warp, Solaris x86, Redhat 5,SuSE 7.x,Fedora, and now Ubuntu (under Vmware on the Mac). Next step is Angstrom on the Beagleboard....
It has nothing to do with how secure the OS is.
Rather, they just don't want to maintain their own
OS any more. Something like this is "good enough"
for the research tinkering they do. This is NOT
the first OS like this they've funded.
Having participated in the development of a "secure OS" for the only people that commission such things, I think I can safely say that it will never happen; nor is it necessary. Things like CMW are adequate for the everyday military use, and the tougher stuff would probably be more appropriately done using an "A1 router" and single-level networks. You don't get A1 for an OS -- you get it for a turnkey system. It's possible to abuse any useful system to create covert channels (cf. the recent posting on timing-based channels in Multics). So, you must code around those problems and establish procedures so that the box can't be abused in that way -- a very non-general-purpose box. To convince yourself that you have really covered things you can either stare at the code or believe the paper generated by the designers. For any kind of general-purpose machine this is infeasible. The OS we built had a 44BSD programmer API, but > 250,000 permissions in its database for a simple application. No way is a normal person (inside joke here) going to be able to come up with that and believe it is correct. So, you build simple, proprietary, reduced-function systems that you can reason about. A general-purpose "secure OS" is a pipe-dream (IMO, of course). Hardware is cheap -- why bother...
If I recall correctly, you can't "redirect" the installation prefix at the last minute (after compiling). Perl (and I think trn) compile-in pathnames, so you're stuck. What you have to do seems to be to just install the program, keep a log and watch where everything goes, then hand-build a package prototype file. It's much simpler to simply "install" to a subdirectory that looks like the "real" filesystem, then just put all the files in the directory in the package.
Note, this says nothing about perl and trn as programs, once installed. I'm only saying that I prefer the "other" kind of "configure" scripts (that make Makefiles that let you change the installation directory on the 'make install' step).
tar xvfz package.tar.gz cd package ./configure make install
This sequence actually causes me headaches. It would be most useful to be able to do the following, instead:
tar zxf foo-1.9.tar.gz cd foo-1.9 ./configure make make install prefix=temp makepkg foo-1.9 temp pkginstall foo-1.9.pkg
The best reason is that I can then do:
pkguninstall foo-1.9
and I'm not left with a system full of miscellaneous crap spread all about. I have scripts to do this for most packages (on Solaris), but things like perl and trn suck for this. To even be on a par with Windoze for ease of use, an easy "uninstall" is a basic requirement.
To clarify the BIOS as a non-issue, simply presume that the disk has been removed, dropped in ones backpack, and taken home to be perused on ones own machine. To guard against this sort of thing, it is best to encrypt the data on the way to the media. This requires support from the storage device and/or the driver. A PCI-based encrypting IDE controller that uses (requires) a crypto-card plugged-in and activated could help here. You are vulnerable at the bus level, still, but to take advantage of that takes more skill. In general, though, if you have time, then you have a much higher probability of getting access if you have physical proximity...
Slashdot Mirror
I still have some files from 1973 of BASIC programs that I wrote on punched tape. They seemed "fine" the last time I looked (within a couple of years). I'm sure I could scan them and OCR them if I had to, and I still have access to a teletype if I really wanted it (though I'd have to make a current-loop to RS-232 converter). HOWEVER -- you can just look at the tape and copy the data, if you REALLY need to. Tedious, but possible...
Get the MS. It will never be easier or cheaper. Both a BS and an MS are simply credentials that prevent your resume from being rejected early. Where I currently work, they don't consider candidates without an MS. Play the game, get the degree. Make contacts, never burn bridges...
First linux I downloaded was early 1.x Slackware. Many floppies. The first I recall messing with was Yggdrasil. I ran minix on my Atari ST at the time, and UNIX at work so got my *nix fix there. When I bought an x86 machine for home, I started with NetBSD 0.9, then FreeBSD 1.*, 2.*,OS/2 Merlin, Warp, Solaris x86, Redhat 5,SuSE 7.x,Fedora, and now Ubuntu (under Vmware on the Mac). Next step is Angstrom on the Beagleboard....
It has nothing to do with how secure the OS is.
Rather, they just don't want to maintain their own
OS any more. Something like this is "good enough"
for the research tinkering they do. This is NOT
the first OS like this they've funded.
Having participated in the development of a "secure OS" for the only people that commission such things, I think I can safely say that it will never happen; nor is it necessary. Things like CMW are adequate for the everyday military use, and the tougher stuff would probably be more appropriately done using an "A1 router" and single-level networks. You don't get A1 for an OS -- you get it for a turnkey system. It's possible to abuse any useful system to create covert channels (cf. the recent posting on timing-based channels in Multics). So, you must code around those problems and establish procedures so that the box can't be abused in that way -- a very non-general-purpose box. To convince yourself that you have really covered things you can either stare at the code or believe the paper generated by the designers. For any kind of general-purpose machine this is infeasible. The OS we built had a 44BSD programmer API, but > 250,000 permissions in its database for a simple application. No way is a normal person (inside joke here) going to be able to come up with that and believe it is correct. So, you build simple, proprietary, reduced-function systems that you can reason about.
A general-purpose "secure OS" is a pipe-dream (IMO, of course). Hardware is cheap -- why bother...
If I recall correctly, you can't "redirect" the installation prefix at the last minute (after compiling). Perl (and I think trn) compile-in pathnames, so you're stuck. What you have to do seems to be to just install the program, keep a log and watch where everything goes, then hand-build a package prototype file. It's much simpler to simply "install" to a subdirectory that looks like the "real" filesystem, then just put all the files in the directory in the package.
Note, this says nothing about perl and trn as programs, once installed. I'm only saying that I prefer the "other" kind of "configure" scripts (that make Makefiles that let you change the installation directory on the 'make install' step).
tar xvfz package.tar.gz
./configure
cd package
make install
This sequence actually causes me headaches. It would be most useful to be able to do the following, instead:
tar zxf foo-1.9.tar.gz
cd foo-1.9
./configure
make
make install prefix=temp
makepkg foo-1.9 temp
pkginstall foo-1.9.pkg
The best reason is that I can then do:
pkguninstall foo-1.9
and I'm not left with a system full of miscellaneous crap spread all about. I have
scripts to do this for most packages (on Solaris), but things like perl and trn suck for this. To even be on a par with Windoze for ease of use, an easy "uninstall" is a basic requirement.
To clarify the BIOS as a non-issue, simply presume that the disk has been removed, dropped in ones backpack, and taken home to be perused on ones own machine. To guard against this sort of thing, it is best to encrypt the data on the way to the media. This requires support from the storage device and/or the driver. A PCI-based encrypting IDE controller that uses (requires) a crypto-card plugged-in and activated could help here. You are vulnerable at the bus level, still, but to take advantage of that takes more skill. In general, though, if you have time, then you have a much higher probability of getting access if you have physical proximity...