With the advent of Java, a lot of young programmers finally saw a way of running their OS-specific programs on other platforms. Unfortunately, the limitation was that a Java VM had to be ported to the platform that they wanted to run their code upon. This Java VM was written in C or C++. Sadly, the distraught Java programmer could not contribute to the effort to port the Java VM to their favorite platforom because they did not understand the intricacies of such things as memory management. Thus, their code did not run on their favorite platform.
These programmers, being passionate about their art, resolved to learn the skillz they needed to port the Java VM to their favorite platform. As they learned the necessary knowledge to run their code, realized that they could have gotten their code to run on any platform much more easily if they wrote it in a compiled-to-machine-code language. These programmers are no longer Java programmers.
Why write code in a scripting language that runs on fewer platforms than other scripting languages? The main advantage of a scripting language is (arguably) the ability to run your code on multiple platforms. A scripting language should be ubiquitous; tying your code to both a compiler that some guy created and the Java VM is not a good idea(tm).
I've been spending a lot of time at work lately working with machines that are running RedHat Enterprise Linux. At home I use my own variant of Linux From Scratch. In the past year or so, I've been noticing a surprising trend... My home machines (running stock kernel.org versions) are remarkably more stable than the machines at the office running RedHat's "stablelized" kernel.
In general, Linux vendors really need to make more of an effort in making sure that their kernels are as stable if not more so than the ones released on kernel.org... I have absolutely no faith that the programmers at RedHat/SuSe/YourLinuxVendor are able to do a better job with the kernel than Linus and the rest of the core kernel developers.
I personally let the compiler writers worry about this type of thing. I'd rather have my code be more readable than fast. That being said, there are many times that I switch back and forth between pointer arithmetic and array indexing within the same program. I'll primarily use the pointer arithmetic for things like simple string processing where it just leads to more compact code, and I'll use the array indexing when I have an actual bonafide array...
In any event, my point is that you should be programming in a way that is maintainable and readable; you shouldn't be worried about shaving tens of clock cycle off of such simple loops. In more complex loops, you probably will not be able to shave nearly as much time off, because your indexes won't always be sitting in a register and the data that the index points to will most likely not even fit into a register. In this case, I don't think anyone will argue with the assertion that this:
I've been through this sort of exercise several times in my career so far. 500k LOC is too much for a small team to get a handle on in any reasonable amount of time, so don't feel too helpless... You're professor is throwing you guys to the wolves and seeing what you are able to accomplish.
As for the actual suggestions, read on:
First, you'll need a tool to generate some form of cross reference for the entire codebase... I'd recommend Doxygen (hack the config file to generate the inheritance and call graphs). This will speed up your ability read the code; being able to look up the interface to any class with a couple of clicks in a web browser will make life a lot less painful.
Next, find a text editor/IDE that's good at navigating large projects. This is a must. I personally do this with vi and ctags (although many people will tell you that there are better alternatives). Being able to look at more than one source file at a time is a good thing (tm).
These are the two primary tools that you'll need. There are some other pointers that I can give too:
Become intimately acquainted with the project's build system. The separation of components into separate directories/libraries/modules will give you a great deal of insight into the overall program's structure. You'll be able to accomplish a lot of this by watching a complete build of the project progress. The other place to look is in the project's Makefile(s). I'd bank on the fact that most code stuck in bottom level subdirectories is code that you'll be able to treat as black boxes.
As you become more familiar with the codebase, you'll find that you keep coming back to certain source files to look something up. Understand that these files are the ones that are probably the most important. It may help you to keep a web browser pointed to the crossreference material for these files, or memorize their content.
Don't get bogged down in understanding every bit of the source. Probably 90 percent of the code in the project is used to do things that you really don't have to ever care about. A good example of this is a project I recently inherited, comprised of about 20,000 LOC. Four thousand lines of code in this project was there just to read XML config files into very simple data structures.
If you are having a difficult time figuring out how a piece of the code works, you may want to try running it in a debugger and stepping through the execution. I'm not a huge fan of doing this, but I know people who swear by it.
Import the source for the project into some form of version control system. This will afford you the luxury of being able to modify the code without fear of breaking anything too badly.
If you have access to the developer's source code repository, sometimes commit histories can give you a lot of insight into why things in the code are the way they are.
Both should display kernel messages from boot-up. Kernel boot messages usually contain the information you need to track down IRQ conflicts.
MemTest86
Not really a Linux program, but something I usually stick as a boot option in grub. Does a great job at detecting bad Ram. MemTest86 can also be booted from a floppy.
BadBlocks
This utility can be used to find bad blocks on a disk partition. I've used it before to check disks.
You might also want to check out some system monitoring utility like Gkrealm, since that gives a generally complete picture IRQ/Interupt usage, Bandwidth utilization, memory and cpu utilization.
I don't think I've ever had a hardware problem that couldn't be diagnosed using the aforementioned utilities.
This post is an agregate of posts that I've read in this discussion, filtered through MY filter based on MY experience. Take it as that.
As a systems engineer, you will be doing a lot of writing. This writing will be specifying how systems will work. In order to do this job competently, you will need a lot of experience with how the system has worked in the past. In order to write the correct stuff, you will need experience that you have not yet had.
My advise is to tough it out with a real-world company (i.e. not government contract work) for a bit and see what real-world engineering entails. After you get sick of that, go back to the government contracts and change the way they waste money.
Private industry teaches you a lot that you will not learn working at Boeing/Lockheed/whoever.
After following the SCO->IBM lawsuit for the past several months, it just occured to me how to demand that SCO itemize the code in the Linux kernel that is infringing on their IP:
IANAL, but doesn't it seem kinda funny that SCO is so concerned about the IP/source that is in the Linux kernel that they seem to think is there, yet they have not filed for an injuctive order halting sites from distributing the Linux kernel. I believe that this would represent a lack of concern for their IP, thus meaning that they have not clearly demonstrated that they are concerned with the 'trade secret' status of their supposed 'know how' in the UNIX environment.
If there is a lawyer out there that reads this comment (and is in a position to comment), please, please please tell me if this makes sense.
Get ten programmers together and ask them to each write a hello world program
Get two groups of programmers together and ask each group to write an operating system that implements the POSIX spec.
Of course there's going to be code that is remarkably similar between SCO and Linux.
The UNIX intellectual property rights were forfeited by the writing of the POSIX spec. Give it up, SCO.
To belabor the point, imagine the following:
Microsoft releases the standard for the Word Document format, an OSS project implements a reader/writer of this format. Microsoft sues the writers for IP infringement.
would anyone want to waste an expensive machine on FreeBSD?
Seriously, this isn't trying to be flamebait... I think FreeBSD is a great OS, but it has been lagging behind in the hardware support department. If you buy a machine that can support more than 4Gb of ram, chances are the following statements are true:
You can afford such a machine because it is going into a datacenter,
Your employer is paying the bill.
The vendor that you bought the machine from will only provide support if you are running windows or linux.
You don't have the time or desire to troubleshoot stupid hardware or driver problems.
FreeBSD has lost the battle... I'm not saying that it's dead, but noone in their right mind would run it on entireprise-class hardware.
It might be my sadistic side, but I prefer for working exploits to be posted by the security sites... It gives you a way of checking to see if you are vulnerable.
In the case of M$ bugs, it also puts more pressure on the company to come up with a fix for the problem quickly.
Speaking as someone who has an opinion that MacOS X is slower than Linux, I'd like to tell people why I think this and explain some of the underlying technical details of why it is...
But first, let me explain a couple of things...
Speed of Number-Crunching
This has nothing to do with the speed of the OS. Unless the data that is being recieved is coming from another program, or being read from disk (as opposed to already being resident in memory); the processor is the bottleneck and a P4 at 2ghz will probably inch-out a G4. Live with it; Intel throws an incredible ammount of money at research pushing the x86 architecture to the limits in terms of speed.
Graphics
MacOS X uses a very computationally intensive windowing system. Yes, things will be slow to draw, but X windows is also equally as slow if you use some of the transparency things that KDE/Gnome/Enlightenment use. Incidentally, This is why I don't use KDE/Gnome/Enlightenment. Let's throw the speed of graphics issues out the window, as they're also fairly subjective. We'll touch on a piece of this issue later.
OS Functions
If you strip out complaints about the speed of user-level processes and the complaints about speed of rendering eye-candy, what is left?
The answer to this question is: The Kernel!!!
This is the piece of the OS that is at the heart of the debate about whether MacOS X is acceptable in terms of performance.
Without getting into an academic discussion about what a Kernel should do (people can get into lengthy arguments about this); I'll list the basic set of things that Unix-like kernels should do:
Pre-emptively schedule tasks (i.e. Allow multiple programs to run concurrently).
Provide memory protection for tasks (i.e. Isolate one programs memory space from another's).
Provide for interprocess communication.
Provide an abstracted interface for using hardware devices (i.e. provide a way for a program to write to a disk).
I believe MacOS X to be slow in all of the above categories. Why? Because it uses a microkernel.
Microkernels are inherently slow at the above tasks because they need to do many, many 'context swaps'. A context swap occurs when a the Operating System or a user-level process takes control of the processor...
Since microkernels are designed to put most device access methods into user-space processes, device access is slow.
Since Interprocess Communication is handled by a user-space process, IPC is slow.
The result is that MacOS X does not scale. You see this when running more than one computationally intensive program. You see this when you run a 'find' command while doing other stuff. You see this when you switch between open windows.
A benchmark that I would really like to see is how much Apache's throughput differ between MacOS X and Linux running on the same piece of hardware. I'll bet that linux wins by a 2-to-1 margin.
There are several main genres in electronic music. They are:
House
Jungle/Drum'n'Base
Breaks
Trance
Down-Tempo/Experimental
Hip Hop
Advocates of specific sub-genres may feel that their tastes may not fit into one of the above categories, and for that I am sorry. I break the genres down the way I do bacause you can generally classify music into one of the above categories based on the descriptions that I go through below. I'll also list some good discs or artists to listen to for each genre. We'll start with house.
House
House is typically what you think of when you hear the term 'Electronic Music'. It has been around forever and has a very regular 4/4 up-down-up-down beat. Derrick Carter, and Charles Feelgood are probably artists to check out if you find yourself interested in house.
Jungle
Most Jungle has a very fast snare line on top of a much slower very deep, broken bass line. This is the stuff I really like. Some artists to listen to are LTJ Bukem, DB, Dieselboy, and Andy C.
Breaks
Breaks derived their name from the generic term 'BreakBeats', meaning that even though most tracks are structure on top of a 4/4 framework, not every beat is emphasized. Although I really like breaks, I find them very difficult to dance to. Some artists to consider would be Simply Jeff, (old) DJ Dan, and Icey.
Trance
Trance in recent years has been becoming much more popular at clubs and in more pop-culture oriented venues. Like house, it is typically a standard 4/4 2-up, 2-down beat, but with a lot of cheesy rise and fall crecendos of sound that play on your emotions. Check out Sandra Collins if you like this stuff.
Down-Tempo/Experimental
This is the stuff that really doesn't fit into any of the above categories... This stuff varies greatly from artist to artist. It's typically people trying to do interesting things by infusing other types of music into the four genres mentioned above. Some of this stuff is really interesting. Anything on the Ninja Tune record label would probably be a good place to start listening.
Hip Hop
While not typically thrown into the 'Electronic Music' category, I feel that it is worth mentioning that there are DJ's out there that mix sets of Hip Hop tracks. If you don't know what Hip Hop is, or who to listen to, go back to the 70's.
Actually, a klein bottle is a 3d figure... it is an example of a figure which has no orientation (i.e. the inside is the same as the outside. Nothing impossible here, just a neat curiosity.
Be very careful in evaluating various unix flavors... There are some major differences in the way the big SVR4 vendors implement many pieces of the operating system.
You'll probably be looking at four or five versions of UNIX:
Solaris
AIX
HP-UX
Linux
Irix
Of these, my experience with any Unixes other than Solaris, Linux, and Irix have been awful. Stay as far away from HP-UX as is possible. AIX is crufty and the machines that it runs on are generally rather slow (despite IBM's claims). Irix isn't very stable, but it's a dream to use. Linux and Solaris are very easy to configure and administrate.
Another consideration for you is whether or not the applications you use have been ported to the other versions of unix. Many application vendors only port their software to certain versions (i.e. Oracle, Informix, etc.)
Like any other technology, the STL has several upsides and downsides. Since I didn't see many negative comments, I'm going to address some of the problems I've encountered using the STL.
My experience has been primarily writing and porting code in the UNIX environment, so keep in mind that I am fairly ignorant of the state of things in the Microsoft world.
The most obvious downside to using the STL is that the generated object code ends up being rather large. This is primarily due to the inlining of member functions of templated classes. While most developers don't really care about this type of thing, it does become a rather significant concern in the embedded world.
Another rather large problem with the STL is that some pieces of the library interface are rather inconsistent with each other. Some of the container classes throw exceptions, others don't. You may not think of this as a serious problem, but consider the following:
An uncaught exception results in a core dump
A Standards compliant version of the STL must throw exceptions (it's part of the standard)
Usually exception handling is a feature neglected during the design of a large system's architecture, primarily due to people's lack of experience with C++
Wily-Nily exception handling results in a very messy architecture
Steering ourselves away from exceptions for a couple of minutes, let's tackle the subject of inheritance... First the STL container class don't get along very well with class hierarchies; what I mean by that is that the following is a mistake:
class Base { ... };
class Derived : public Base { ... };
Base b; Derived d; std::vector<Base> v;
v.push_back(b); v.push_back(d);
The rational as to why you can find in Scott Meyer's book Effective C++ . The short explanation is that an array of classes can not be properly treated polymorphically. I highly recommend that book to anyone looking to either write C++ or designing a program that will be implemented with C++.
Another issue that can crop up and bite you is that of memory management. The auto_ptr helps a lot with this one, but you must be careful with any non-intrinsic datatype that you store in an STL containers.
A couple other random things to consider:
The string class that is almost part of the STL should be avoided. It is extremely inefficient to use, does not implement reference counting, and will generally cause many more problems than it is worth.
Several assemblers (most notably older versions of Solaris's) have problems with the extremely long function names that get generated by the mangling process.
Learn the functions/functors provided in <algorithm>
Life can be a lot simpler if you make a habit of qualifying STL functions with their namespace (i.e. prefixing names with 'std::' instead of relying on the global 'using std;' directive).
A compiler that supports the export keyword may help bring code size down.
Remember that there is no compiler in existence that actually implements the C++ standard correctly... Being proactive in this regard can sometimes save a lot of agravation if a time comes that you need to port your application to new platforms.
While the STL is extremely efficient at generic algorithms, hand-written code generally is leaner and faster.
If working as part of a large team, take the time to educate people on how to use the STL, so the code doesn't seem foriegn to them.
Always pass containers by reference or const-reference.
The STL is a fantastic programming tool if used correctly, however there is a steep learning curve and quite a few gotcha's. I hope some of my thoughts help.
Hmm... Why not cover one percent of the earth's surface with solar panels and save the inefficiency of transmission? I'm sure that the roof tops of people's houses/offices/any other construction makes up for at least one percent of the earth's surface.
Why do people always try to make things harder than they really are?
I Wonder how long it will be before the human race starts object to such lunacy... The man who wrote that article apparently never took the correspondence course in sylogistic logic... Oh wait, reading ideas by philosophers like Plato and Socrates is also a sin. Sigh.
Even if you believe in creationism (not a subject I want to even try tackling here), you should be able to spot the blatant flaws in this guys argument. If it were up to this guy, we would still be in the dark ages, dying of the plague.
Anyone who leads people around with such blatantly false arguments should be forced to have a full frontal lobotomy, after all, he doesn't seem to be using that fore-brain anyway...
Smalltalk has all of the features your looking for, unfortunately, it's an interpreted language without much support for integration with modern technologies (i.e. cgi, sql, etc).
Just to let you know, I tried your strategy and several others, none of them have seemed to work for me... I should probably just post the problem with some carefully constructed benchmarking code to the lkml and see what they have to say. Anyway, this thread of discussion is really going nowhere... I was kind of hoping to get some insight from the kernel developers which hasn't happened. Thanks for the suggestions, but I've already tried every way I know of hacking around the problem without any success.
I'm sorry that I wasn't clearer in the original post... With all three kernel versions, what I experienced was not only performance degradation, but a change in runtimes from about 15 minutes to over 8 hours. Unfortunately, I never managed to really quantify times or run a thorough set of benchmarks, but it seems that such a drastic difference in runtimes would imply that the VM's in all of these kernels are not handling a worst-case scenario correctly.
Slashdot Mirror
The Linux From Scratch project, while not really a distribution is very well suited to this type of task
With the advent of Java, a lot of young programmers finally saw a way of running their OS-specific programs on other platforms. Unfortunately, the limitation was that a Java VM had to be ported to the platform that they wanted to run their code upon. This Java VM was written in C or C++. Sadly, the distraught Java programmer could not contribute to the effort to port the Java VM to their favorite platforom because they did not understand the intricacies of such things as memory management. Thus, their code did not run on their favorite platform.
These programmers, being passionate about their art, resolved to learn the skillz they needed to port the Java VM to their favorite platform. As they learned the necessary knowledge to run their code, realized that they could have gotten their code to run on any platform much more easily if they wrote it in a compiled-to-machine-code language. These programmers are no longer Java programmers.
Why write code in a scripting language that runs on fewer platforms than other scripting languages? The main advantage of a scripting language is (arguably) the ability to run your code on multiple platforms. A scripting language should be ubiquitous; tying your code to both a compiler that some guy created and the Java VM is not a good idea(tm).
I've been spending a lot of time at work lately working with machines that are running RedHat Enterprise Linux. At home I use my own variant of Linux From Scratch. In the past year or so, I've been noticing a surprising trend... My home machines (running stock kernel.org versions) are remarkably more stable than the machines at the office running RedHat's "stablelized" kernel.
In general, Linux vendors really need to make more of an effort in making sure that their kernels are as stable if not more so than the ones released on kernel.org... I have absolutely no faith that the programmers at RedHat/SuSe/YourLinuxVendor are able to do a better job with the kernel than Linus and the rest of the core kernel developers.
Premature optimization is the root of all evil.
I personally let the compiler writers worry about this type of thing. I'd rather have my code be more readable than fast. That being said, there are many times that I switch back and forth between pointer arithmetic and array indexing within the same program. I'll primarily use the pointer arithmetic for things like simple string processing where it just leads to more compact code, and I'll use the array indexing when I have an actual bonafide array...
In any event, my point is that you should be programming in a way that is maintainable and readable; you shouldn't be worried about shaving tens of clock cycle off of such simple loops. In more complex loops, you probably will not be able to shave nearly as much time off, because your indexes won't always be sitting in a register and the data that the index points to will most likely not even fit into a register. In this case, I don't think anyone will argue with the assertion that this:
is less readable than this:
I've been through this sort of exercise several times in my career so far. 500k LOC is too much for a small team to get a handle on in any reasonable amount of time, so don't feel too helpless... You're professor is throwing you guys to the wolves and seeing what you are able to accomplish.
As for the actual suggestions, read on:
First, you'll need a tool to generate some form of cross reference for the entire codebase... I'd recommend Doxygen (hack the config file to generate the inheritance and call graphs). This will speed up your ability read the code; being able to look up the interface to any class with a couple of clicks in a web browser will make life a lot less painful.
Next, find a text editor/IDE that's good at navigating large projects. This is a must. I personally do this with vi and ctags (although many people will tell you that there are better alternatives). Being able to look at more than one source file at a time is a good thing (tm).
These are the two primary tools that you'll need. There are some other pointers that I can give too:
Anyway, good luck!
Both should display kernel messages from boot-up. Kernel boot messages usually contain the information you need to track down IRQ conflicts.
MemTest86
Not really a Linux program, but something I usually stick as a boot option in grub. Does a great job at detecting bad Ram. MemTest86 can also be booted from a floppy.
BadBlocks
This utility can be used to find bad blocks on a disk partition. I've used it before to check disks.
You might also want to check out some system monitoring utility like Gkrealm, since that gives a generally complete picture IRQ/Interupt usage, Bandwidth utilization, memory and cpu utilization.
I don't think I've ever had a hardware problem that couldn't be diagnosed using the aforementioned utilities.
This post is an agregate of posts that I've read in this discussion, filtered through MY filter based on MY experience. Take it as that.
As a systems engineer, you will be doing a lot of writing. This writing will be specifying how systems will work. In order to do this job competently, you will need a lot of experience with how the system has worked in the past. In order to write the correct stuff, you will need experience that you have not yet had.
My advise is to tough it out with a real-world company (i.e. not government contract work) for a bit and see what real-world engineering entails. After you get sick of that, go back to the government contracts and change the way they waste money.
Private industry teaches you a lot that you will not learn working at Boeing/Lockheed/whoever.
Fuck Them
After following the SCO->IBM lawsuit for the past several months, it just occured to me how to demand that SCO itemize the code in the Linux kernel that is infringing on their IP:
IANAL, but doesn't it seem kinda funny that SCO is so concerned about the IP/source that is in the Linux kernel that they seem to think is there, yet they have not filed for an injuctive order halting sites from distributing the Linux kernel. I believe that this would represent a lack of concern for their IP, thus meaning that they have not clearly demonstrated that they are concerned with the 'trade secret' status of their supposed 'know how' in the UNIX environment.
If there is a lawyer out there that reads this comment (and is in a position to comment), please, please please tell me if this makes sense.
These are two seemingly unrelated ideas:
Of course there's going to be code that is remarkably similar between SCO and Linux.
The UNIX intellectual property rights were forfeited by the writing of the POSIX spec. Give it up, SCO.
To belabor the point, imagine the following:
Microsoft releases the standard for the Word Document format, an OSS project implements a reader/writer of this format. Microsoft sues the writers for IP infringement.
I really hope that IBM counter-sues.
would anyone want to waste an expensive machine on FreeBSD?
Seriously, this isn't trying to be flamebait... I think FreeBSD is a great OS, but it has been lagging behind in the hardware support department. If you buy a machine that can support more than 4Gb of ram, chances are the following statements are true:
FreeBSD has lost the battle... I'm not saying that it's dead, but noone in their right mind would run it on entireprise-class hardware.
It might be my sadistic side, but I prefer for working exploits to be posted by the security sites... It gives you a way of checking to see if you are vulnerable.
In the case of M$ bugs, it also puts more pressure on the company to come up with a fix for the problem quickly.
Speaking as someone who has an opinion that MacOS X is slower than Linux, I'd like to tell people why I think this and explain some of the underlying technical details of why it is...
But first, let me explain a couple of things...
Speed of Number-Crunching
This has nothing to do with the speed of the OS. Unless the data that is being recieved is coming from another program, or being read from disk (as opposed to already being resident in memory); the processor is the bottleneck and a P4 at 2ghz will probably inch-out a G4. Live with it; Intel throws an incredible ammount of money at research pushing the x86 architecture to the limits in terms of speed.
Graphics
MacOS X uses a very computationally intensive windowing system. Yes, things will be slow to draw, but X windows is also equally as slow if you use some of the transparency things that KDE/Gnome/Enlightenment use. Incidentally, This is why I don't use KDE/Gnome/Enlightenment. Let's throw the speed of graphics issues out the window, as they're also fairly subjective. We'll touch on a piece of this issue later.
OS Functions
If you strip out complaints about the speed of user-level processes and the complaints about speed of rendering eye-candy, what is left?
The answer to this question is: The Kernel!!! This is the piece of the OS that is at the heart of the debate about whether MacOS X is acceptable in terms of performance.
Without getting into an academic discussion about what a Kernel should do (people can get into lengthy arguments about this); I'll list the basic set of things that Unix-like kernels should do:
I believe MacOS X to be slow in all of the above categories. Why? Because it uses a microkernel.
Microkernels are inherently slow at the above tasks because they need to do many, many 'context swaps'. A context swap occurs when a the Operating System or a user-level process takes control of the processor...
Since microkernels are designed to put most device access methods into user-space processes, device access is slow.
Since Interprocess Communication is handled by a user-space process, IPC is slow.
The result is that MacOS X does not scale. You see this when running more than one computationally intensive program. You see this when you run a 'find' command while doing other stuff. You see this when you switch between open windows.
A benchmark that I would really like to see is how much Apache's throughput differ between MacOS X and Linux running on the same piece of hardware. I'll bet that linux wins by a 2-to-1 margin.
Just my $.02. Please ignore rationality.
Developers are extremely fickle about their development environment (I am personally a die-hard vi user).
In order to get developers to use your product, you need to get them to use it and see why your product is better than what they've been using.
A good example of this is the bitkeeper program that Linus adopted for kernel C.F.
Unless you give us the chance to use your product without monetary commitment, we will never use it.
There are several main genres in electronic music. They are:
Advocates of specific sub-genres may feel that their tastes may not fit into one of the above categories, and for that I am sorry. I break the genres down the way I do bacause you can generally classify music into one of the above categories based on the descriptions that I go through below. I'll also list some good discs or artists to listen to for each genre. We'll start with house.
House
House is typically what you think of when you hear the term 'Electronic Music'. It has been around forever and has a very regular 4/4 up-down-up-down beat. Derrick Carter, and Charles Feelgood are probably artists to check out if you find yourself interested in house.
Jungle
Most Jungle has a very fast snare line on top of a much slower very deep, broken bass line. This is the stuff I really like. Some artists to listen to are LTJ Bukem, DB, Dieselboy, and Andy C.
Breaks
Breaks derived their name from the generic term 'BreakBeats', meaning that even though most tracks are structure on top of a 4/4 framework, not every beat is emphasized. Although I really like breaks, I find them very difficult to dance to. Some artists to consider would be Simply Jeff, (old) DJ Dan, and Icey.
Trance
Trance in recent years has been becoming much more popular at clubs and in more pop-culture oriented venues. Like house, it is typically a standard 4/4 2-up, 2-down beat, but with a lot of cheesy rise and fall crecendos of sound that play on your emotions. Check out Sandra Collins if you like this stuff.
Down-Tempo/Experimental
This is the stuff that really doesn't fit into any of the above categories... This stuff varies greatly from artist to artist. It's typically people trying to do interesting things by infusing other types of music into the four genres mentioned above. Some of this stuff is really interesting. Anything on the Ninja Tune record label would probably be a good place to start listening.
Hip Hop
While not typically thrown into the 'Electronic Music' category, I feel that it is worth mentioning that there are DJ's out there that mix sets of Hip Hop tracks. If you don't know what Hip Hop is, or who to listen to, go back to the 70's.
junkbusters.com
Actually, a klein bottle is a 3d figure... it is an example of a figure which has no orientation (i.e. the inside is the same as the outside. Nothing impossible here, just a neat curiosity.
Be very careful in evaluating various unix flavors... There are some major differences in the way the big SVR4 vendors implement many pieces of the operating system.
You'll probably be looking at four or five versions of UNIX:
- Solaris
- AIX
- HP-UX
- Linux
- Irix
Of these, my experience with any Unixes other than Solaris, Linux, and Irix have been awful. Stay as far away from HP-UX as is possible. AIX is crufty and the machines that it runs on are generally rather slow (despite IBM's claims). Irix isn't very stable, but it's a dream to use. Linux and Solaris are very easy to configure and administrate.Another consideration for you is whether or not the applications you use have been ported to the other versions of unix. Many application vendors only port their software to certain versions (i.e. Oracle, Informix, etc.)
Thank God!
Just my $0.02
Like any other technology, the STL has several upsides and downsides. Since I didn't see many negative comments, I'm going to address some of the problems I've encountered using the STL.
My experience has been primarily writing and porting code in the UNIX environment, so keep in mind that I am fairly ignorant of the state of things in the Microsoft world.
The most obvious downside to using the STL is that the generated object code ends up being rather large. This is primarily due to the inlining of member functions of templated classes. While most developers don't really care about this type of thing, it does become a rather significant concern in the embedded world.
Another rather large problem with the STL is that some pieces of the library interface are rather inconsistent with each other. Some of the container classes throw exceptions, others don't. You may not think of this as a serious problem, but consider the following:
Steering ourselves away from exceptions for a couple of minutes, let's tackle the subject of inheritance... First the STL container class don't get along very well with class hierarchies; what I mean by that is that the following is a mistake:
The rational as to why you can find in Scott Meyer's book Effective C++ . The short explanation is that an array of classes can not be properly treated polymorphically. I highly recommend that book to anyone looking to either write C++ or designing a program that will be implemented with C++.
Another issue that can crop up and bite you is that of memory management. The auto_ptr helps a lot with this one, but you must be careful with any non-intrinsic datatype that you store in an STL containers.
A couple other random things to consider:
The STL is a fantastic programming tool if used correctly, however there is a steep learning curve and quite a few gotcha's. I hope some of my thoughts help.
Hmm... Why not cover one percent of the earth's surface with solar panels and save the inefficiency of transmission? I'm sure that the roof tops of people's houses/offices/any other construction makes up for at least one percent of the earth's surface.
Why do people always try to make things harder than they really are?
Even if you believe in creationism (not a subject I want to even try tackling here), you should be able to spot the blatant flaws in this guys argument. If it were up to this guy, we would still be in the dark ages, dying of the plague.
Anyone who leads people around with such blatantly false arguments should be forced to have a full frontal lobotomy, after all, he doesn't seem to be using that fore-brain anyway...
Smalltalk has all of the features your looking for, unfortunately, it's an interpreted language without much support for integration with modern technologies (i.e. cgi, sql, etc).
Just to let you know, I tried your strategy and several others, none of them have seemed to work for me... I should probably just post the problem with some carefully constructed benchmarking code to the lkml and see what they have to say. Anyway, this thread of discussion is really going nowhere... I was kind of hoping to get some insight from the kernel developers which hasn't happened. Thanks for the suggestions, but I've already tried every way I know of hacking around the problem without any success.
I'm sorry that I wasn't clearer in the original post... With all three kernel versions, what I experienced was not only performance degradation, but a change in runtimes from about 15 minutes to over 8 hours. Unfortunately, I never managed to really quantify times or run a thorough set of benchmarks, but it seems that such a drastic difference in runtimes would imply that the VM's in all of these kernels are not handling a worst-case scenario correctly.