So called e-cinema or electronic cinematography seems to be moving toward two HDTV standards: 24p (24-frame progressive) and 60i (60-field interlaced). Those who are after the "film look" prefer 24p, especially since the progressive approach results in fewer artifacts (aberrations) and higher resolution. The 24 fps speed is also the same as film--even though the extra sharpness of video sets it apart from film. However, compared to 24p, 60i (30 fps) does a better job of tracking motion, which means that zooms and camera movements--especially when done rapidly--appear smoother. (These must be done slower with film or 24p video.) Either of these standards can be converted to film. With the proper equipment and electronic setup, either of these standards become almost indistinguishable from film when projected. (If there is any "fault" with digital video it's that seems "too sharp and clear" compared to film. Of course, I guess we can all get used to better quality if we really have to!) At the same time we are seeing the beginning of a move to e-theaters, or movie theaters that use video projection equipment. A dozen or so major theaters around the country use digital projection now. Several digital feature "films" are in the works now. The studio production standards we've cited are not to be confused with the broadcast standards listed below.
The press release is here. ActiveState joined Microsoft's Visual Studio Integration Program. Visual Studio will contain a full-featured VB/VC++-like IDE. Visual Python will also be included.
This is mostly from Chapter 8 of Programming Perl.
Use hashes instead of linear searches. Instead of iterating over @keywords to see if $_ is a keyword, construct a hash with it: my %keywords; for (@keywords) { ++$keywords{$_}; } Then test $keywords{$_} for a nonzero value to see if $_ is a keyword.
Consider using foreach, shift, or splice rather than subscripting.
Use use integer.
Avoid goto
Avoid printf if print will work
Avoid $&, $`, and $'
Avod using eval on a string. Eval of a string forces recompilation every time the program is ran. In particular, symbolic references instead fo using eval to to construct variable names: ${$pkg . '::' . $varname} = &{ "fix_" . $varname}($pkg)
Avoid eval inside a loop. Put the loop into eval instead, to avoid redundant recompilations of the code.
Avoid run-time-compiled patterns, that is,/$pattern/. Use the/pattern/o (once only) pattern modifier to avoid pattern recompilations when the pattern doesn't change over the life of the process. For patterns that change occasionally, you can use the fact that a null pattern refers back to the previous pattern, like this: "foundstring" =~/$currentpattern/; # Dummy match, must suceed while () { print if//; }
Short-circuit alternation is often faster than the corresponding regular expressions. So: print if/one-hump/ ||/two/; is likely to be faster than: print if/one-hump|two/; at least for certain values of one-hump and two. This is because the optimizer likes to hoist ceertain simple matching operations up into higher parts of the syntax tree and do very fast matching with a Boyer-Moore algorithm. Complicated patterns defeat this.
Reject common cases early with next if inside a loop. As with simple regular expressions, the optimizer likes this. You can typically discard comment lines and blank lines even before you do a split or chop: while () { next if/^#/; next if/^$/; chop; @line = split(/,/);
Avoid regular expressions with many quantifiers, or with big {m,n} numbers on parenthesized expressions.
Maximize length of any non-optional literal strings in regular expressions. This is counterintuitive, but longer patterns often match faster than shorter patterns. That's because the optimizer looks for constant strings and hands them off to a Boyer-Moore search, which benefits from longer strings. Compile your pattern with the -Dr debugging switch to see what Perl thinks the longest literal is.
Avoid expensive subroutine calls in tight loops.
Avoid getc, use sysread instead (for single-character I/O only). . To get all the non-dot files within a directory, say something like this: opendir(DIR, "."); @files = sort grep(!/^\./, readdir(DIR)); closedir(DIR);
Avoid frequent substr on long strings
Use pack and unpack instead of multiple substr invocations.
Use substr as an lvalue rather than concatenating substrings.
Use s/// rather than concatenating substrings.
Use modifiers and equivalent and and or, instead of full-blown conditionals. Statement modifiers and logical operators avoid the overhead of entering and leaving a block. They can often be more readable too.
Don't test things you know won't match. Use last or elsif to avoid falling through to the next case in your switch statement.
Use special operators like study, logical string operations, unpack 'u' and pack '%' formats.
Beware of the tail wagging the dog. Misresembling ()[0] and 0.. 2000000 can cause Perl much unnecessary work. In accord with UNIX philsophy, Perl gives you enough rope to hang yourself.
Factor operations out of loops.
Slinging strings can be faster than slinging arrays.
my variables are normally faster than local variables.
tr/abc//d is faster than s/[abc]//g
Print with a comma separator may be faster than concatenating strings.
Prefer join("",...) to a series of concatenated strings.
Split on a fixed string is generally split on a pattern. That is, use split(//,...) rather than split(/ +,...).
system("mkdir...") may be fsater on multiple directories if mkdir(2) isn't available.
Cache entries from passwd and group and so on.
Avoid unnecessary system calls.
Avoid unecessary system() calls.
Keep track of your working directory rather than calling pwd each time.
Avoid shell matacharacters in commands -- pass lists to system and exe where appropriate.
Set the sticky bit on the Perl interpreter on machines without demand paging. chmod +t/usr/bin/perl
Using defaults doesn't make your program faster
The same chapter also lists Space Efficiency, Programmer Efficiency, Maintainer Efficincy, Porter Efficiency, and User Efficinecy. Each section contradicts each other.
Plan 9's GUI is 8½. 8½ is so great because of it's compact size and simplicity in programming. A complete Hello World program is only 26K: #include u.h #include libc.h #include libg.h
San Jose - To a crowd of tech reporters and industry heavyweights Sisqo Systems unveiled its newest thong router - the NTNG2000. NTNG2000 is designed as a gateway for the millions of thong packets flying through cyberspace. Thong Song crooner and CEO Sisqo said, "Baby, this is the hottest router in the world. It's routing the vida loca."
"Thong packets are the hottest segment of the market," said industry analyst Bob Smeckins. "Sisqo once again proves to be the industry leader."
Neutral thong packet usage has been growing at a rate of 34% a month for the last year since its development by R & B stars Dru Hill. A competing format by Microsoft - G-STRING has been announced but has yet to be seen. "We don't see G-STRING as a threat to neutral thong packets, and we are working closely with Microsoft to develop G-STRING routers also. If they decide not to cooperate then we will kick there bu-butts," said Sisqo while busting some phat moves on the stage.
The NTNG2000 is housed in a black box with silver metallic trim. The target market appears to be the yet untapped inner city youth demographic.
/usr/share/misc/bsd-family-tree
on
The Roots Of BSD
·
· Score: 1
Time tolerance +/- 6 month, depend on which book/article you read; if it was the announcement in Usenet or if it was available as tape.
[44B] McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. [DOC] README, COPYRIGHT on tape. [QCU] Salus, Peter H. A quarter century of UNIX. [U25] Peter H. Salus. Unix at 25. [USE] Usenet announcement. [KSJ] Michael J. Karels, Carl F. Smith, and William F. Jolitz. Changes in the Kernel in 2.9BSD. Second Berkeley Software Distribution UNIX Version 2.9, July, 1983. [KB] Keith Bostic. BSD2.10 available from Usenix. comp.unix.sources, Volume 11, Info 4, April, 1987. [KKK] Mike Karels, Kirk McKusick, and Keith Bostic. tahoe announcement. comp.bugs.4bsd.ucb-fixes, June 15, 1988. [SMS] Steven M. Schultz. 2.11BSD, UNIX for the PDP-11. [FBD] FreeBSD Project, The. [NBD] NetBSD Project, The. [OBD] OpenBSD Project, The. [dmr] Dennis Ritchie, via E-Mail
Multics 1965 Unix Summer 1969 DEC PDP-7 First Edition 1971-11-03 [QCU] DEC PDP-11/20, Assembler Second Edition 1972-06-12 [QCU] 10 Unix installations Third Edition 1973-02-xx [QCU] Pipes, 16 installations Fourth Edition 1973-11-xx [QCU] rewriting in C effected, above 30 installations Fifth Edition 1974-06-xx [QCU] above 50 installations Sixth Edition 1975-05-xx [QCU] port to DEC Vax Seventh Edition 1979-01-xx [QCU] first portable Unix Eight Edition 1985-02-xx [QCU] VAX 11/750, VAX 11/780 [dmr] descended from 4.1c BSD [dmr] descended from 4.1 BSD [44B] scooping-out and replacement of the character-device and networking part by the streams mechanism
Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman. The Design and Implementation of the 4.3BSD UNIX Operating System. Reading, Mass. Addison-Wesley, 1989. ISBN 0-201-06196-1
Salus, Peter H. A quarter century of UNIX. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5
McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. Addison-Wesley, 1996. ISBN 0-201-54979-4
Doug McIlroy. Research Unix Reader.
Michael G. Brown. The Role of BSD in the Development of Unix. Presented to the Tasmanian Unix Special Interest Group of the Australian Computer Society, Hobart, August 1993. URL: http://www.dpac.tas.gov.au/~mgb/papers/bsdrole.htm l
Peter H. Salus. Unix at 25. Byte Magazin, October 1994. URL: http://www.byte.com/art/9410/sec8/art3.htm
Andreas Klemm, Lars Köller. If you're going to San Francisco... Die freien BSD-Varianten von Unix. c't April 1997, page 368ff. URL: http://www.heise.de
The performance overhead of SCSI over IDE comes from structure of the bus, not the drive. The nature of the SCSI bus allows it much better performance when doing data hungry tasks such as multi-tasking. The SCSI bus controller is capable of controlling the drives without any work by the processor. Also, all drives on a SCSI chain are cable of operating at the same time. With IDE, one is limited to two drives in a chain, and these drives cannot work at the same time. In essence, they must "take turns".
For most people, IDE is just fine and offers very good performance. The reason I believe one does not need to get SCSI, though, is that most users do not use their system in a way that would actually justify the SCSI bus. While the nature of the bus is faster, it takes certain situations to actually need it. Couple this with the significantly higher price, one can see that they can easily live with IDE.
Some excerpts from the FreeBSD vs. Linux page at http://www.futuresouth.com/~fullermd/freebsd/bsdvl in.html page:
Subject: Re: Why FreeBSD?
Any response to a question like this is bound to upset someone. I'll answer with the caveat that this is my opinion that developed over the past three years following them both as well as other commercial OSs. Those of you offended in any way by this, please cat flames >/dev/null.
That said -- the differences between FreeBSD and Linux can best be understood in the context of American politics. There are essentially two philosophies: Republican (FreeBSD) and Democrat (Linux).
The FreeBSD organization is a republican structure -- we have our say as users, but the final decisions devolve to the core team who take the final responsibility for their decisions. FreeBSD takes a conservative approach. In other words, better things should work correctly at the expense of a minorities desires, than to please all of the people all of the time and have unexpected components of the OS breaking on a regular basis. We are free to vote our approval or disapproval by changing our OS.
Linux is a democratic group. There is no single authority to accept final responsibility except for Linus as it relates to the kernel. Linux adopted early on a consensus approach (POSIX, etc.). In a sense, Linux is much like current Democratic politics -- the mob pretty much rules. The end result is that there is really no such thing as Linux -- there are distributions that use the Linux kernel and from then on you have essentially different operating systems. Slackware, for example, doesn't look at all like Red Hat. Describing Linux is much like describing Mach. (There isn't much - both are just micro kernels. _Anything_ can be implemented over them.)
So as I see it, it comes down to this: vote for the philosophy that appeals to you. I use FreeBSD because I rely on my machine for many other uses besides tinkering with operating systems. FreeBSD doesn't change the world on me every 6 months. Linux is in constant change. New things are showing up all the time. If you like tinkering with operating systems and having things that used to work break, Linux may be your answer. If you don't know Unix -- pick one and get started. You'll learn how to pick the best choice. No matter which one you pick, it will be infinitely better that Micros**t anything.
Enjoy.
-- Jay
---------- Subject: Re: Why FreeBSD?
And the clouds parted on 21 Mar 97, and Jeff Roberts said:
>On Fri, 21 Mar 1997, Bob Dole wrote: > >> Hi, I plan on changing to UNIX and I wonder wether I should take Linux or >> FreeBSD... >> Both seem to be an excellent choice, so you can't say one is better than >> the other. But in what are they different, in what is each specialized? >
Then try them both: they're both "free", but you'll have to pay something for you Internet connection or CDROM distribution, depending on your circumstances. The following is not impartial, as I don't play with Linux much, but when I did I wasn't as happy as I am now 8).
[opinions on]
Linux is SysV-flavored (barely); FreeBSD is BSD-flavored (definitely).
Linux's kernel is authored by one person (Linus Torvalds); FreeBSD is authored by (essentially) the core team.
Linux addons come from pretty much everywhere; FreeBSD's get submitted from a lot of places also, but have to pass review to be included as part of the release.
Linux has multiple releases (based on who's packaging), all somewhat different from each other, and somewhat inoperative as well. There's only one release to FreeBSD (per major version)
Linux tends to be more cutting-edge and trendy, and tends to work with more hardware (to some degree), partly because of the "arrangements" made with vendors. FreeBSD requires that source code be freely obtainable for (nearly?) all it's parts, which scares some vendors into not cooperating, or at least not as well. The hardware that _is_ supported tends to be done pretty robustly.
Linux is snappier for low-user-count systems, depending on what you're trying to do. FreeBSD tends to shine under real load (like WWW/FTP servers), and I don't really know if any major sites base such Internet services on Linux; quite a few seem to be using FreeBSD, particularly Walnut Creek CDROM, which carries quite a load on a consistent basis.
There are far more books on Linux than FreeBSD per se, something I draw no conclusions on.
The support on the Linux list(s) is something I haven't any personal experience with; the support on the FreeBSD lists is exemplary.
[opinions off]
Please correct any sins of commission and ommission you find above; I don't do this often enough to be any good at it.
your mileage may vary, and best wishes, larry
-------- Subject: linux vs freebsd testimonial
A few weeks ago, my single linux box fried. I replaced both the hard drive (with an identicle one) and linux with freebsd 2.1.5.
The machine runs majordomo, ftp, apache, and an irc server.
The performance is way up there! Under linux it would frequently slug down to a crawl. under FreeBSD it just keeps zipping along.
There is a very definite noticable difference in response and load handling. ------- ubject: Re: linux vs freebsd testimonial
Since we've gotten along fairly well in our migration from Linux, I thought I'd share my experiences as well...
We currently run on FBSD:
1 Shell/user www (was NetBSD 1.0) 1 DNS/mail/dialup auth/syslog (these two are sharing mail spool over NFS) 1 utility/backup/freebies 1 DNS/mail for seperate, wacky project 2 virt www servers (3 are still Linux) 2 co-locate www servers (www.firstview.com 3.6G/day, www.villagevoice.com)
These have been the most trouble-free machines we've worked with. Some of the recent security problems were a bit tough (lots of cvsup-ing), but nothing compared to the nasty Slackware Linux Bug-o-the-month. The only reboots *any* of these machines have seen were intentional, which is something I just can't say about Linux. Performance is much better, and the "out of box" configuration is a lot more sensible than Slackware. A few of these machines really get beat on hard, and they just ask for more.
We have to keep one Linux web server for compatibility with some odd sourceless C cgi's, but the other two will be history soon. Our news server is running Linux, but it's being replaced with a machine to be named "fridge" which will have 3 SCSI busses and 15 drives, and of course be running FBSD.
I must say, this has made my job much easier. Linux is just too unpredictable when you don't have the time to play the "kernel-of-the-week" game. One of the Linux boxes still does the routine of freezing with no log entries or other hints; which is extremely frustrating. FBSD just seems like it was meant to be in a production environment...
Journaled File System Technology for Linux Overview IBM's journaled file system technology, currently used in IBM enterprise servers, is designed for high-throughput server environments, key to running intranet and other high-performance e-business file servers. IBM is contributing this technology to the Linux open source community with the hope that some or all of it will be useful in bringing the best of journaling capabilities to the Linux operating system. Work is currently underway to complete the port of this technology to Linux.
A worm with minimal malicious activity is infecting Gnutella users at an alarming rate. Gnutella is similar to Napster in that it allows peer to peer filesharing. The worm, which has as many as twenty file names, contains a message from the author "if I was a naughty boy, I could use scripting to get name, email, whatever files." Users are cautioned to be wary of files within Gnutella that have.vbs extensions.
Pike tries very hard to be C, too hard in my humble opinion. Programming languages are tools -- they should be useful instead of trying to imitate popular programming languages. Why not use C instead?
Wheel mouse is now fully functionnal with most applications (netscape, gnome, KDE, etc.)
Better powersaving support on Laptop computers
Enhanced USB support for modems, printers, Zip drives
Better symmetrical multi processing support
All Helix Code GNOME improvements incorporated
Enhanced default settings for GNOME & KDE environments
Modified Qt library (foundation of KDE applications) supporting Chinese, Korean, Japanese
New menu system. Menus look now the same under every graphical environments and updates automatically when new packages are installed.
System organization benefits from reordered packages in coherent groups, usable by most package-management tools, including RpmDrake.
DrakBoot allows for easy graphical configuration of boot loader (lilo and grub)
DrakBootdisk, a new graphical boot-floppy creation tool.
PrinterDrake (printer configuration) now supports more printer types and options.
DrakX now fully handles multiple-CD installation.
Linux4Win now runs automatically when CDROM is inserted under Windows (autorun)
DrakX user interface has been improved to ease installation : User can now choose an icon representing his/her user under Linux-Mandrake, more powerfull packages selection options, etc.
Installation can now detect high resolution video modes and use them during install
Urpmi, the text-mode rpm tool now handles local rpm installation.
If Windows is present on the computer, DrakFont gives the user access to his Windows fonts under Linux.
Distribution is now shipped with a fully functionnal rescue floppy.
Grub is now supported as the default bootloader, no more 1024-cylinder limit.
Now includes brand new XFree 4.0 servers, with new modular architecture.
For professional environments, the new journalized file system ReiserFS is included
Main distribution is now on 2 CDROMs, the second one also including contribs.
Slashdot Mirror
- Industrial processes
- Environmental toxins and pollutants
- Space station air quality
- Medicine / body functions
- Food processing
- Military enviromnent
- Toxicology
From the JPL Electronic Nose page. Some other interesting resources:More information on the DTV Standards is available.
CmdrTaco: The first link to EETimes is broken.
The press release is here. ActiveState joined Microsoft's Visual Studio Integration Program. Visual Studio will contain a full-featured VB/VC++-like IDE. Visual Python will also be included.
- Use hashes instead of linear searches. Instead of iterating over @keywords to see if $_ is a keyword, construct a hash with it:
- Consider using foreach, shift, or splice rather than subscripting.
- Use use integer.
- Avoid goto
- Avoid printf if print will work
- Avoid $&, $`, and $'
- Avod using eval on a string. Eval of a string forces recompilation every time the program is ran. In particular, symbolic references instead fo using eval to to construct variable names: ${$pkg . '::' . $varname} = &{ "fix_" . $varname}($pkg)
- Avoid eval inside a loop. Put the loop into eval instead, to avoid redundant recompilations of the code.
- Avoid run-time-compiled patterns, that is,
/$pattern/. Use the /pattern/o (once only) pattern modifier to avoid pattern recompilations when the pattern doesn't change over the life of the process. For patterns that change occasionally, you can use the fact that a null pattern refers back to the previous pattern, like this: /$currentpattern/; # Dummy match, must suceed //;
- Short-circuit alternation is often faster than the corresponding regular expressions. So:
/one-hump/ || /two/; /one-hump|two/; - Reject common cases early with next if inside a loop. As with simple regular expressions, the optimizer likes this. You can typically discard comment lines and blank lines even before you do a split or chop:
/^#/; /^$/;
- Avoid regular expressions with many quantifiers, or with big {m,n} numbers on parenthesized expressions.
- Maximize length of any non-optional literal strings in regular expressions. This is counterintuitive, but longer patterns often match faster than shorter patterns. That's because the optimizer looks for constant strings and hands them off to a Boyer-Moore search, which benefits from longer strings. Compile your pattern with the -Dr debugging switch to see what Perl thinks the longest literal is.
- Avoid expensive subroutine calls in tight loops.
- Avoid getc, use sysread instead (for single-character I/O only). . To get all the non-dot files within a directory, say something like this:
- Avoid frequent substr on long strings
- Use pack and unpack instead of multiple substr invocations.
- Use substr as an lvalue rather than concatenating substrings.
- Use s/// rather than concatenating substrings.
- Use modifiers and equivalent and and or, instead of full-blown conditionals. Statement modifiers and logical operators avoid the overhead of entering and leaving a block. They can often be more readable too.
- Use $foo = $a || $b || $c instead of:
- Set default values with $pi ||= 3;
- Don't test things you know won't match. Use last or elsif to avoid falling through to the next case in your switch statement.
- Use special operators like study, logical string operations, unpack 'u' and pack '%' formats.
- Beware of the tail wagging the dog. Misresembling ()[0] and 0
.. 2000000 can cause Perl much unnecessary work. In accord with UNIX philsophy, Perl gives you enough rope to hang yourself. - Factor operations out of loops.
- Slinging strings can be faster than slinging arrays.
- my variables are normally faster than local variables.
- tr/abc//d is faster than s/[abc]//g
- Print with a comma separator may be faster than concatenating strings.
- Prefer join("",
...) to a series of concatenated strings. - Split on a fixed string is generally split on a pattern. That is, use split(/
/, ...) rather than split(/ +, ...). - system("mkdir
...") may be fsater on multiple directories if mkdir(2) isn't available. - Cache entries from passwd and group and so on.
- Avoid unnecessary system calls.
- Avoid unecessary system() calls.
- Keep track of your working directory rather than calling pwd each time.
- Avoid shell matacharacters in commands -- pass lists to system and exe where appropriate.
- Set the sticky bit on the Perl interpreter on machines without demand paging. chmod +t
/usr/bin/perl - Using defaults doesn't make your program faster
The same chapter also lists Space Efficiency, Programmer Efficiency, Maintainer Efficincy, Porter Efficiency, and User Efficinecy. Each section contradicts each other.my %keywords;
for (@keywords) {
++$keywords{$_};
}
Then test $keywords{$_} for a nonzero value to see if $_ is a keyword.
"foundstring" =~
while () {
print if
}
print if
is likely to be faster than:
print if
at least for certain values of one-hump and two. This is because the optimizer likes to hoist ceertain simple matching operations up into higher parts of the syntax tree and do very fast matching with a Boyer-Moore algorithm. Complicated patterns defeat this.
while () {
next if
next if
chop;
@line = split(/,/);
opendir(DIR, ".");
@files = sort grep(!/^\./, readdir(DIR));
closedir(DIR);
if ($a) { $foo = $a; }
elsif ($b) { $foo = $b; }
elsif ($c) { $foo = $c; }
Plan 9's GUI is 8½. 8½ is so great because of it's compact size and simplicity in programming. A complete Hello World program is only 26K:
/* clear */
/* initialize graphics library */ /* initialize event library */
/* wait for release of button */
#include u.h
#include libc.h
#include libg.h
void ereshaped(Rectangle r)
{
Point p;
screen.r = r;
bitblt(&screen, screen.r.min, &screen, r, Zero);
p.x = screen.r.min.x + Dx(screen.r)/2;
p.y = screen.r.min.y + Dy(screen.r)/2;
p = sub(p, div(strsize(font, "hello world"), 2));
string(&screen, p, font, "hello world", S);
}
main(void)
{
Mouse m;
binit(0, 0, 0);
einit(Emouse);
ereshaped(screen.r);
for(;;){
m = emouse();
if(m.buttons & RIGHTB)
break;
if(m.buttons & LEFTB){
string(&screen, m.xy, font, "hello world", S);
do; while(emouse().buttons & LEFTB);
}
}
}
"Thong packets are the hottest segment of the market," said industry analyst Bob Smeckins. "Sisqo once again proves to be the industry leader."
Neutral thong packet usage has been growing at a rate of 34% a month for the last year since its development by R & B stars Dru Hill. A competing format by Microsoft - G-STRING has been announced but has yet to be seen. "We don't see G-STRING as a threat to neutral thong packets, and we are working closely with Microsoft to develop G-STRING routers also. If they decide not to cooperate then we will kick there bu-butts," said Sisqo while busting some phat moves on the stage.
The NTNG2000 is housed in a black box with silver metallic trim. The target market appears to be the yet untapped inner city youth demographic.
FreeBSD ships with a BSD Family Tree / Unix History chart located in /usr/share/misc/bsd-family-tree:
i smo v .#366 + -------------* | .............| | .............| | .............| | ...........BSDI.1.0 S D.Alpha......| | .............| S D............| | .............| | .............| | .............| | .............| | .............| S D.Lite.-->.BSDI.2.0 | .............| | ...........BSDI.2.0.1 | .............| S D.Lite2.->.BSDI.2.1 | ....|.\......|
m l
...
/ src/share/misc/bsd-family-tree
First.Edition.(V1)
.....|
Second.Edition.(V2)
.....|
Third.Edition.(V3)
.....|
Fourth.Edition.(V4)
.....|
Fifth.Edition.(V5)
.....|
Sixth.Edition.(V6).-----*
.......\................|
........\...............|
.........\..............|
Seventh.Edition.(V7)....|
............\...........|
.............\........1BSD
.............32V........|
...............\......2BSD---------------*
................\..../...................|
.................\../....................|
..................\/.....................|
.................3BSD....................|
..................|......................|
...............4.0BSD...............2.7.9BSD
..................|......................|
.......*------.4.1BSD.-------------->.2.8BSD
....../...........|......................|
Eighth.Edition.....|.................2.8.1BSD
.....|............|......................|
.....|........4.1aBSD.-----------\.......|
.....|............|................\.....|
.....|........4.1bBSD................\...|
.....|............|....................\.|
.....|........4.1cBSD.-------------->.2.9BSD
.....|............|......................|
.....|............|...................2.9BSD-Se
.....|............|......................|
.....+----.2.10BSD
.....|............|.............../......|
Ninth.Edition.....|............../.2.10.1BSD
.....|.........4.3BSD.Tahoe-----+........|
.....|............|..............\.......|
.....|............|................\.....|
.....v............|..................2.11BSD
Tenth.Edition.....|......................|
..................|..................2.11BSD.re
...............4.3BSD.NET/1..............|
..................|......................v
...............4.3BSD.Reno
..................|
...*----------.4.3BSD.NET/2.-------------------
...|....................|......................
386BSD.0.0..............|......................
...|....................|......................
386BSD.0.1.------------>+......................
...|.....\..............|..................4.4B
...|.....386BSD.1.0.....|......................
...|....................|..................4.4B
...|....................|..................../.
...|....................|...4.4BSD-Encumbered..
...|.................NetBSD.0.8................
...|....................|......................
FreeBSD.1.0..........NetBSD.0.9................
...|....................|............-----.4.4B
FreeBSD.1.1.............|........../.../.......
...|....................|........./.../........
FreeBSD.1.1.5........---|--------'.../.........
...|.............../....|.........../......4.4B
FreeBSD.1.1.5.1.../.....|........../....../....
...|............./...NetBSD.1.0.
Time
----------------
Time tolerance +/- 6 month, depend on which book/article you read; if
it was the announcement in Usenet or if it was available as tape.
[44B] McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
and John Quarterman. The Design and Implementation of
the 4.4BSD Operating System.
[DOC] README, COPYRIGHT on tape.
[QCU] Salus, Peter H. A quarter century of UNIX.
[U25] Peter H. Salus. Unix at 25.
[USE] Usenet announcement.
[KSJ] Michael J. Karels, Carl F. Smith, and William F. Jolitz.
Changes in the Kernel in 2.9BSD. Second Berkeley Software
Distribution UNIX Version 2.9, July, 1983.
[KB] Keith Bostic. BSD2.10 available from Usenix. comp.unix.sources,
Volume 11, Info 4, April, 1987.
[KKK] Mike Karels, Kirk McKusick, and Keith Bostic. tahoe announcement.
comp.bugs.4bsd.ucb-fixes, June 15, 1988.
[SMS] Steven M. Schultz. 2.11BSD, UNIX for the PDP-11.
[FBD] FreeBSD Project, The.
[NBD] NetBSD Project, The.
[OBD] OpenBSD Project, The.
[dmr] Dennis Ritchie, via E-Mail
Multics 1965
Unix Summer 1969
DEC PDP-7
First Edition 1971-11-03 [QCU]
DEC PDP-11/20, Assembler
Second Edition 1972-06-12 [QCU]
10 Unix installations
Third Edition 1973-02-xx [QCU]
Pipes, 16 installations
Fourth Edition 1973-11-xx [QCU]
rewriting in C effected,
above 30 installations
Fifth Edition 1974-06-xx [QCU]
above 50 installations
Sixth Edition 1975-05-xx [QCU]
port to DEC Vax
Seventh Edition 1979-01-xx [QCU]
first portable Unix
Eight Edition 1985-02-xx [QCU]
VAX 11/750, VAX 11/780 [dmr]
descended from 4.1c BSD [dmr]
descended from 4.1 BSD [44B]
scooping-out and replacement of the character-device
and networking part by the streams mechanism
Ninth Edition 1986-09-xx [QCU]
Tenth Edition 1989-10-xx [QCU]
1BSD late 1977
1978-03-09 [QCU]
PDP-11, Pascal, ex(1)
30 free copies of 1BSD sent out
35 tapes sold for 50 USD [QCU]
2BSD mid 1978 [QCU]
75 2BSD tapes shipped
2.7.9BSD ?? [SMS]
2.8BSD 1981-07-xx [KSJ]
2.8.1BSD 1982-01-xx [QCU]
set of performance improvements
2.9BSD 1983-07-xx [KSJ]
2.9.1BSD 1983-11-xx
2.9BSD-Seismo 1985-08-xx [SMS]
2.10BSD 1987-04-xx [KKK]
2.10.1BSD 1989-01-xx [SMS]
2.11BSD 1992-02-xx [SMS]
2.11BSD rev #366 1997-02-xx [SMS]
32V 1978-1[01]-xx [QCU]
3BSD late 1979 [QCU]
virtual memory, page replacement,
demand paging
4.0BSD 1980-10-xx
4.1BSD 1981-06-xx
4.1aBSD 1982-04-xx
alpha release, 100 sites, networking [44B]
4.1bBSD internal release, fast filesystem [44B]
4.1cBSD late 1982
beta release, IPC [44B]
4.2BSD 1983-09-xx [QCU]
4.3BSD 1986-06-xx [QCU]
1986-04-xx [KB]
4.3BSD Tahoe 1988-06-xx [QCU]
4.3BSD NET/1 1988-11-xx [QCU]
4.3BSD Reno 1990-06-xx [QCU], [DOC]
4.3BSD NET/2 1991-06-xx [QCU]
386BSD 0.0 1992-02-xx [DOC]
386BSD 0.1 1992-07-xx [DOC]
4.4BSD Alpha 1992-07-07
NetBSD 0.8 1993-04-20 [NBD]
4.4BSD 1993-06-01 [USE]
NetBSD 0.9 1993-08-23 [NBD]
FreeBSD 1.0 1993-11-xx [FOO]
4.4BSD Lite 1994-03-01 [USE]
FreeBSD 1.1 1994-04-xx [FBD]
FreeBSD 1.1.5.1 1994-07-xx [FBD]
supersedes 1.1.5 3 days after release.
NetBSD 1.0 1994-10-26 [NBD]
386BSD 1.0 1994-11-12 [USE]
FreeBSD 2.0 1995-01-xx [FBD]
FreeBSD 2.0.5 1995-06-xx [FBD]
4.4BSD Lite Release 2 1995-06-xx [44B]
the true final distribution from the CSRG
NetBSD 1.1 1995-11-26 [NBD]
FreeBSD 2.1 1995-12-xx [FBD]
FreeBSD 2.1.5 1996-08-xx [FBD]
NetBSD 1.2 1996-10-04 [NBD]
OpenBSD 2.0 1996-10-18 [OBD]
FreeBSD 2.1.6 1996-12-xx [FBD]
FreeBSD 2.1.7 1997-02-xx [FBD]
FreeBSD 2.2.1 1997-04-xx [FBD]
NetBSD 1.2.1 1997-05-20 [NBD] (patch release)
OpenBSD 2.1 1997-06-01 [OBD]
FreeBSD 2.2.2 1997-06-xx [FBD]
NetBSD 1.3 1998-01-04 [NBD]
FreeBSD 2.2.5 1997-11-xx [FBD]
OpenBSD 2.2 1997-12-01 [OBD]
FreeBSD 2.2.6 1998-03-xx [FBD]
NetBSD 1.3.1 1998-03-09 [NBD] (patch release)
OpenBSD 2.3 1998-05-19 [OBD]
NetBSD 1.3.2 1998-05-29 [NBD] (patch release)
FreeBSD 2.2.7 1998-07-xx [FBD]
FreeBSD 3.0 1998-10-16 [FBD]
FreeBSD-3.0 is a snapshot from -current,
while 3.1 and 3.2 are from 3.x-stable which
was branched quite some time after 3.0-release
FreeBSD 2.2.8 1998-11-29 [FBD]
OpenBSD 2.4 1998-12-01 [OBD]
NetBSD 1.3.3 1998-12-23 [NBD] (patch release)
FreeBSD 3.1 1999-02-15 [FBD]
NetBSD 1.4 1999-05-12 [NBD]
FreeBSD 3.2 1999-05-17 [FBD]
OpenBSD 2.5 1999-05-19 [OBD]
NetBSD 1.4.1 1999-08-26 [NBD] (patch release)
FreeBSD 3.3 1999-09-17 [FBD]
OpenBSD 2.6 1999-12-01 [OBD]
FreeBSD 3.4 1999-12-20 [FBD]
Bibliography
------------------------
Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John
Quarterman. The Design and Implementation of the 4.3BSD UNIX Operating
System. Reading, Mass. Addison-Wesley, 1989. ISBN 0-201-06196-1
Salus, Peter H. A quarter century of UNIX. Addison-Wesley Publishing
Company, Inc., 1994. ISBN 0-201-54777-5
McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John
Quarterman. The Design and Implementation of the 4.4BSD Operating
System. Reading, Mass. Addison-Wesley, 1996. ISBN 0-201-54979-4
Doug McIlroy. Research Unix Reader.
Michael G. Brown. The Role of BSD in the Development of Unix.
Presented to the Tasmanian Unix Special Interest Group of the
Australian Computer Society, Hobart, August 1993.
URL: http://www.dpac.tas.gov.au/~mgb/papers/bsdrole.ht
Peter H. Salus. Unix at 25. Byte Magazin, October 1994.
URL: http://www.byte.com/art/9410/sec8/art3.htm
Andreas Klemm, Lars Köller. If you're going to San Francisco
Die freien BSD-Varianten von Unix. c't April 1997, page 368ff.
URL: http://www.heise.de
BSD Release Announcements collection.
URL: http://www.de.FreeBSD.ORG/de/ftp/releases/
BSD Hypertext Man Pages
http://www.freebsd.org/cgi/man.cgi
Acknowledgments
---------------
Josh Gilliam for suggestions, bugfixes, and finding very old
original BSD announcements from Usenet or tapes.
Steven M. Schultz for providing 2.8BSD, 2.10BSD, 2.11BSD manual pages.
--
Copyright (c) 1997-1999 Wolfram Schneider
URL: ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current
$FreeBSD: src/share/misc/bsd-family-tree,v 1.21 2000/03/12 21:54:18 wosch Exp $
The performance overhead of SCSI over IDE comes from structure of the bus, not the drive. The nature of the SCSI bus allows it much better performance when doing data hungry tasks such as multi-tasking. The SCSI bus controller is capable of controlling the drives without any work by the processor. Also, all drives on a SCSI chain are cable of operating at the same time. With IDE, one is limited to two drives in a chain, and these drives cannot work at the same time. In essence, they must "take turns".
For most people, IDE is just fine and offers very good performance. The reason I believe one does not need to get SCSI, though, is that most users do not use their system in a way that would actually justify the SCSI bus. While the nature of the bus is faster, it takes certain situations to actually need it. Couple this with the significantly higher price, one can see that they can easily live with IDE.
IDE vs. SCSI
There's a more recent, less in-depth review comparision of FreeBSD vs. Linux vs. Windows NT here. Why Yahoo! Uses FreeBSD is also interesting.
Some excerpts from the FreeBSD vs. Linux page at http://www.futuresouth.com/~fullermd/freebsd/bsdvl in.html page:
/dev/null.
Subject: Re: Why FreeBSD?
Any response to a question like this is bound to upset someone. I'll
answer with the caveat that this is my opinion that developed over the
past three years following them both as well as other commercial OSs.
Those of you offended in any way by this, please cat flames >
That said -- the differences between FreeBSD and Linux can best be
understood in the context of American politics. There are essentially two
philosophies: Republican (FreeBSD) and Democrat (Linux).
The FreeBSD organization is a republican structure -- we have our say as
users, but the final decisions devolve to the core team who take the final
responsibility for their decisions. FreeBSD takes a conservative approach.
In other words, better things should work correctly at the expense of a
minorities desires, than to please all of the people all of the time and
have unexpected components of the OS breaking on a regular basis. We are
free to vote our approval or disapproval by changing our OS.
Linux is a democratic group. There is no single authority to accept final
responsibility except for Linus as it relates to the kernel. Linux adopted
early on a consensus approach (POSIX, etc.). In a sense, Linux is much
like current Democratic politics -- the mob pretty much rules. The end
result is that there is really no such thing as Linux -- there are
distributions that use the Linux kernel and from then on you have
essentially different operating systems. Slackware, for example, doesn't
look at all like Red Hat. Describing Linux is much like describing Mach.
(There isn't much - both are just micro kernels. _Anything_ can be
implemented over them.)
So as I see it, it comes down to this: vote for the philosophy that
appeals to you. I use FreeBSD because I rely on my machine for many other
uses besides tinkering with operating systems. FreeBSD doesn't change the
world on me every 6 months. Linux is in constant change. New things are
showing up all the time. If you like tinkering with operating systems and
having things that used to work break, Linux may be your answer. If you
don't know Unix -- pick one and get started. You'll learn how to pick the
best choice. No matter which one you pick, it will be infinitely better
that Micros**t anything.
Enjoy.
-- Jay
----------
Subject: Re: Why FreeBSD?
And the clouds parted on 21 Mar 97, and Jeff Roberts
said:
>On Fri, 21 Mar 1997, Bob Dole wrote:
>
>> Hi, I plan on changing to UNIX and I wonder wether I should take Linux or
>> FreeBSD...
>> Both seem to be an excellent choice, so you can't say one is better than
>> the other. But in what are they different, in what is each specialized?
>
Then try them both: they're both "free", but you'll have to pay something
for you Internet connection or CDROM distribution, depending on your
circumstances. The following is not impartial, as I don't play with Linux
much, but when I did I wasn't as happy as I am now 8).
[opinions on]
Linux is SysV-flavored (barely); FreeBSD is BSD-flavored (definitely).
Linux's kernel is authored by one person (Linus Torvalds); FreeBSD is
authored by (essentially) the core team.
Linux addons come from pretty much everywhere; FreeBSD's get submitted from
a lot of places also, but have to pass review to be included as part of the
release.
Linux has multiple releases (based on who's packaging), all somewhat
different from each other, and somewhat inoperative as well. There's only
one release to FreeBSD (per major version)
Linux tends to be more cutting-edge and trendy, and tends to work with more
hardware (to some degree), partly because of the "arrangements" made with
vendors. FreeBSD requires that source code be freely obtainable for
(nearly?) all it's parts, which scares some vendors into not cooperating,
or at least not as well. The hardware that _is_ supported tends to be done
pretty robustly.
Linux is snappier for low-user-count systems, depending on what you're
trying to do. FreeBSD tends to shine under real load (like WWW/FTP
servers), and I don't really know if any major sites base such Internet
services on Linux; quite a few seem to be using FreeBSD, particularly
Walnut Creek CDROM, which carries quite a load on a consistent basis.
There are far more books on Linux than FreeBSD per se, something I draw no
conclusions on.
The support on the Linux list(s) is something I haven't any personal
experience with; the support on the FreeBSD lists is exemplary.
[opinions off]
Please correct any sins of commission and ommission you find above; I don't
do this often enough to be any good at it.
your mileage may vary, and best wishes,
larry
--------
Subject: linux vs freebsd testimonial
A few weeks ago, my single linux box fried. I replaced both the hard
drive (with an identicle one) and linux with freebsd 2.1.5.
The machine runs majordomo, ftp, apache, and an irc server.
The performance is way up there! Under linux it would frequently slug
down to a crawl. under FreeBSD it just keeps zipping along.
There is a very definite noticable difference in response and load
handling.
-------
ubject: Re: linux vs freebsd testimonial
Since we've gotten along fairly well in our migration from Linux, I
thought I'd share my experiences as well...
We currently run on FBSD:
1 Shell/user www (was NetBSD 1.0)
1 DNS/mail/dialup auth/syslog (these two are sharing mail spool over NFS)
1 utility/backup/freebies
1 DNS/mail for seperate, wacky project
2 virt www servers (3 are still Linux)
2 co-locate www servers (www.firstview.com 3.6G/day, www.villagevoice.com)
These have been the most trouble-free machines we've worked with. Some of
the recent security problems were a bit tough (lots of cvsup-ing), but
nothing compared to the nasty Slackware Linux Bug-o-the-month. The only
reboots *any* of these machines have seen were intentional, which is
something I just can't say about Linux. Performance is much better, and
the "out of box" configuration is a lot more sensible than Slackware. A
few of these machines really get beat on hard, and they just ask for more.
We have to keep one Linux web server for compatibility with some odd
sourceless C cgi's, but the other two will be history soon. Our news
server is running Linux, but it's being replaced with a machine to be
named "fridge" which will have 3 SCSI busses and 15 drives, and of course
be running FBSD.
I must say, this has made my job much easier. Linux is just too
unpredictable when you don't have the time to play the
"kernel-of-the-week" game. One of the Linux boxes still does the routine
of freezing with no log entries or other hints; which is extremely
frustrating. FBSD just seems like it was meant to be in a production
environment...
Thanks to all involved,
-------
Pike tries very hard to be C, too hard in my humble opinion. Programming languages are tools -- they should be useful instead of trying to imitate popular programming languages. Why not use C instead?
This link has images of the DR70 test in progress: How the DR70 test works.
I wonder how well this would underclock?