The evolution of VM from CP/67 to z/VM has resulted in some of the virtualization function being pushed down into the hardware.

With the introduction of XA architecture in the late 80's, IBM moved some of the virtualization technology down into the hardware, they created a new instruction, SIE - Start Interpretive Execution that could tap into this facility. This facility ended up being the heart of both LPARs and VM/XA (which grew into current z/VM). Conceptually the SIE instruction, or the LPAR facility saves the current processor context, and starts a new context. The "guest" system (or the LPAR) now runs in this new context until some condition has been met (e.g. certain timer pops, certain state changes, etc, as defined by the meta-system (z/VM or the base system managing the LPARs). The movement of this function down into hardware was a logical extension of what used to be called hardware VM assists in pre-XA days.

Basically the base hardware provides LPARs (in fact for quite some time IBM mainframes can only run in LPAR mode, even if one has only one system image). LPARs allow sharing of the physical processors, sharing of physical I/O devices, and partitioning of physical memory. With an LPAR you cannot exceed the physical resources available, meaning that you cannot define an LPAR image with more processors then are physically available, or give an LPAR image more memory then is physically available. This is where z/VM comes in.

z/VM provides the ability to virtualize the physical resources. You can define a VM guest with more memory then is physically available, or more processors then are physically available. In addition z/VM can provide virtualized I/O devices, or provide more fine grained partitioning of physical devices (e.g. carving a disk volume into a collecting of smaller volumes in what is called mini-disks -- which are not the same as a disk partition).

The whole purpose of comments is to explain the code so that future maintainers (including the author of the code) can easily understand what is going on. If done right, a maintainer can pick up a module and come up to speed as to what the code does, why it does it, and any thing else that might trip them up. Comments need to capture the developers thoughts from when the code was being designed and written. The reasoning and ideas behind an algorithm that took several months to design cannot be truly captured with a 3 line comment and 25 lines of code.

I feel that comments can be broken into four types:

1. Boiler plate front matter. These are the comments that are required by the coding standards of the shop. Usually contains copyright notices, author's name, list of changes, etc.
2. Specification and reference comments. A list of the external references, such as the formal specification for the code, a bibliography for the algorithms used, etc.
3. Block comments. These should describe the intent of a larger block of code. The reader should be able to take all the block comments from a program and have a good understanding what the entire program does. Block comments should describe the what and why. Block comments should also describe any gotchas, or special conditions that the maintainer needs to be aware of.
4. Line comments. Should describe the purpose of a small number of statements. Line comments should not merely echo the action of the code itself, but describe what is happening and how the particular action relates to the rest of the program.

   i += 4; /* Increment i by 4 */ BAD comment
   
   i += 4; /* Ignore the first 4 fields */ Better

You really don't understand what a monopoly is do you?

the USB IF acts to maintain the USB standard - and it features vendor ID codes that are assured (by the specification) to be unique to each individual vendor who uses them.

They *must* act to prevent other companies from just deciding to use a Vendor ID *that does not belong to them* (read: have not licenced to use because the ID has been licenced by someone else, namely Apple).

How on earth did this get +1 informative?

The sole reason the USB IF exists in the first place is to prevent (or correct) issues like this arising, when one company breaks the spec for their own ends.

I disagree. Leaving aside the squatters and ad-pumpers (I wish we could :-) the "ordinary user" should not be able to hide their identity. Hiding physical address details is an unfortunate but acceptable security restriction today; but hiding email, phone, and other contact data is just wrong. It's abused by thousands of companies to prevent people contacting them when their poxy products fail, or to hide their true ownership and identity. Registering a personal domain is one thing; registering a domain as a business should bring with it the responsibility to publish valid contact information and keep it up to date. It should be illegal for registrars to hide the identity of their business registrants.

Tesla actually demonstrated it. He just never got the chance to scale it up. So.. before going around and saying that this has just been invented, go check Tesla's patents.

Several years ago I read (and wish I remembered where) a technique that I thought was quite interesting. It was a rule based authentication scheme. Each account on a system would have it's own set of rules that only the user would know. For example.

Here I might have set up the rule to say whenever there is a mathematical equation, with an even result and it's in the morning enter "cat", if it's in the afternoon enter "river", if the result is odd and it's monday then enter "blue", tuesday enter ... you get the idea.

The response has nothing to do mathematically with the question, but relies on the fact that I know what the proper response should be. And even is someone was watching my response. Each time I log in a different rule would be used (maybe the next question would be "what color are roses?")

Personally if I were to make the decisions on hiring someone, and give the choice between a person who knew only one language inside and out and a person who was exposed to 4 or 5 different language but needed a quick peek at a reference book to make sure they got the syntax right or some such, I would pick the 2nd person without even blinking.

You see, to the first person, he has only one tool in his tool box (a hammer), and to him everything will look like a nail.

Programming is so much more then just simply banging out a bunch of lines of code. It's looking at the requirements and picking the best tool for the job. In addition things are never static. A little tool may be needed and python may just fit the bill, then there will be that web application that needs enhanced and that is written in PHP, and the boss just dropped by and said that corporate just got a new application in and it has it's own scripting interface and it needs in interface to the application that you are responsible for.

Sure... if you are working on a big project, that project may have decided to use just one language and you will spend the next 3 years looking at java, but knowing how a computer really works (from that assembly class - even though you've never code a single line of assembly) you can make some wise decisions on how to implement something, or maybe just maybe you might come back and say - you know right here it would be beneficial to call out to a routine written in C because Java just isn't going to cut it right here.

Ah... the constitution does not enumerate the rights that we have, but lists what rights the government has. The bill of rights explicitly spells out those things that the government cannot take away. The 9th and 10th amendments spell this out

I'd give her a little more credit... I don't know all the details but reading the "Caroline's story" it does sound like she was capturing and processing the images herself (with some assistence in getting going and learning what to do). It might have been "Dad's" observatory and such.. but it still looks like she was doing the work. The co-discovery might simply have been the "hey let me check my data as well..".

The setup that some of these SN hunters is fairly automated, they maintain a list of objects that they will check on a routine basis. A group of SN hunters will sometimes pool their resources, share lists, coordinate what objects they are going to check, etc. The scopes can be automated to jump from object to object, take some exposures, then move on to the next object. The processing of the exposures can be partially automated, but it still requires going through them to determine if it's real or an imaging artifict or a cosmic ray on the image. This used to be done by using an optical blink comparitor (an old school optical box set up where you can quickly flip from viewing one photographic plate to another)

Anyway -- Kudos to Caroline. It's a fun hobby that has been keeping me busy since I was 12 and had access to a 10" Newtonian.

Within the amateur and professional astronomy circles there is a fairly wide known and standard method of reporting astronomical stuff (see http://www.cfa.harvard.edu/iau/cbat.html )

Many deepsky objects (galaxies, nebulae, star clusters) become "well known friends" by amateur astronomers. For example, when ever I'm out observing I will usually do a quick peek at M13 in Hercules, M81, M82 in Ursa Major, or parts of the Veil nebulae in Cygnus when they are visible (just to name a few). I suspect if there was a new supernova in M81 or M82, there is a chance that I would "catch it" by noticing something "odd" (think of it like noticing a new pimple on a friends face). Once something "odd" is noticed, the next step would be to check recent and older photographs of that region. If it's suspected to be "new" then the information is submitted to the IAU Central Bureau for Astronomical Telegrams according to the instructions listed above. Usually the next step that happens is that the pros might get involved to verify the finding.

There are "rules" on who discovers the object, based mainly on the chronological time that IAU receives the information. Co-discovery of the same object can happen, usually the cut-off is when the IAU sends out the notice that there is a potential new object. In other words, say that I notice a new brightness in M81, I record the information and at 10:15 GMT send it in to the IAU CBAT. Someone else also notices the same object and sends in the information at 10:30 GMT. There is a CBAT notice sent out to subscribers at 10:35 GMT. Any observation after 10:35 would not be considered a discovery.

BTW if you go out to http://www.cfa.harvard.edu/iau/lists/RecentSupernovae.html and look for 2008ha, you will find that there where 2 other people who are listed as discoverers of the same supernova, and it looks like Caroline Moore has been "working" with the same folks because she is also listed with at least one of them on two other recent supernova discoveries.

The fact is, there is an enormous base of existing tested FORTRAN code that is still in use and still being developed within the scientific community. The issue is not simply writing new code in a newer language, the problem is setting up a new tested base in the new language.

Lets say that you are working on a project to evaluate the effects of theoretical gravity waves through a nebulae. You have a choice

1. Use 3 college interns to modify some code that you have been working on using a library of subroutines that have you and your prior researchers have been building up and using over the last 40 years
2. -or- Use 3 college interns to write new code from scratch in a new language that the compiler/interpreter was just released 2 years ago.

And oh, you have to publish results in 2 months in order to get your next NSF grant.

Yes, the new code might be all object orienty, and you can use the latest IDE to develop in, and you can hire a bunch of fresh young (cheap) grad students that are familiar with the latest python, perl, C#, etc. development and they can bang out thousands of lines of code a day. But are you really really sure that that freshly written eigenvalue routine produces the correct result? Has that new compiler been tested on the super-computer you have limited access to, can it even take advantage of all the power of that system?

I'm not saying that FORTRAN compilers are not bug free, but I suspect that the chances of finding a basic compiler or runtime library bug is lower in FORTRAN then in say Perl 6.

A couple of years ago my son spent some time doing some intern coding work for a private atmospheric research group. The group was/is doing bleeding edge research. My son was helping out one of the researchers in updating code that handled 2D models to 3D models. All the code was in FORTRAN and there was no desire to move away from it.

The problem isn't only in the US government. It's also in the IT (and probably many other) industries. In the rush to make more profit, the people who know how things really work under the covers are let go (because that component is working well enough). In the meantime there is a huge amount of new work sitting on top of of all this old stuff. As long as nothing under the cover breaks everything is just fine.

From your own reference...

No... the Electoral college votes are supposed to represent the individual state. The fact that the state legislatures have delegated the selection to the people is a state choice.

Using Wikipedia and looking at the US population values:

Without the Electoral College the popular vote would go to: New York City, Los Angeles, Chicago, Houston, Phoenix, Philadelphia, San Antonio, San Diego and Dallas. The total of these (around 238 million) are over 70% of the total US population (around 300 million)

The populations of: Wyoming (~500,000), South Dakota (~800,000), North Dakota (~600,000) and Iowa (~3,000,000) would not equal the population of New York City (~8,000,000).

If this trends continues, Iowa and any "small state" will never see a presidential candidate campaign again, they would be too small and their vote would no longer matter anymore.

Remember that under the US Constitution, the appointment of the President is by the States (via the appointment of the electors)