I was curious to try and see Ridge A in Google Earth. GE didn't seem to know it. The images of Antarctica are for the most part really low rez. But, there are some interesting anomalies in GE. Firstly, there is a big white "frying pan" over the south pole, secondly, if I go to 90,90 (north pole) GE seems to have floating point problems. -90,90 seems to work. I get a kaleidoscope of blue vectors when I scroll in or out. Thirdly, if I try to go "to here", (Antarctica) from Cupertino, CA it says "We could not understand your search." Bummer.
I had never heard of last.fm. I checked out their site briefly. Why don't sites clearly say how they work instead of making someone work their way through a lame FAQ?
Anyway, here is a quote from their Terms of Use agreement.
"It is important for you to refer to these Terms of Use from time to time to make sure that you are aware of any additions, revisions, or modifications that we may have made to these Terms of Use. Your continued use of the Website constitutes your acceptance of the new Terms of Use."
Is this a common practice. One has to agree to something that can change and you are obligated to adhere to these changes, too? How can this be legal?
There also spell out later their claim to intellectual property rights. Including "database rights." Is that a real right or are they just making that up?
They also state "You are responsible for... restricting access to your computer so that others may not access any password-protected portion of the Website or other Properties using your name..."
Yuck. Yuck. Yuck. Is this really worth their service?
The brief description in the article sounds suspicious and incompetent.
1. A common killer in parallelization is false sharing. That is, threads on two processors fight over a cache-line even though they are accessing independent variables. A cache-line is typically bigger than an individual variable. The approach of using adjacent elements of an array for parallelism sounds naive. One needs to pad the array.
2. Updating a shared variable, especially a non-scaler, in an inner loop is naive. One should reference local scalers in inner loops when parallelizing. Just once, should the thread update the shared variable. Don't reference non-scalers or shared variables in an inner loop. Don't lock in the inner loop, either, if you can avoid it.
If it is not an inner loop then the locking is probably not a big issue any way.
Related to this story is a follow-up: http://tierneylab.blogs.nytimes.com/2008/04/10/the-psychology-of-getting-suckered/#more-264
In this you read
"In fact, when we presented probability puzzles including a version of Monty Hall and the Mr. Smith problem to 327 MBA students who had all been trained to use such computations, they were almost seven times as likely to rely on some form of the partition-edit-count strategy than an explicit computation. Strikingly, none of the MBA students who tried to compute the answer to these puzzles arrived at a correct solution."
Anyone surprised?
There is quite a lot of training available about the Linux kernel. There is of course more to learn than can be possibly be taught in any courses, or can even be known by any one person.
A common issue in training is folks requesting training that covers more material than can be covered in the alloted time. However, when negotiating for training with a training provider, it is valuable to discuss the topic outline in advance and ask about changes. Since the topic of Linux kernel training is so broad, you should be able to narrow down the subjects that are most valuable to you.
A stock kernel course will have a mix of what the authors felt was most widely applicable. Or at least most applicable to their audience.
The week long course from Red Hat (actually developed by Axian) covers much of the kernel.
Also, remember, it is the combination of training materials plus instructor that make the class. Who developed the materials? Who is the instructor?
For something like the Linux kernel, an instructor with a strong Linux programming background and education in computer science - say an advanced degree in computer science and 10 years or more of working with UNIX and five or more years with Linux is something to expect. Also, get an instructor when you want training. Get a practicing engineer when you want engineering.
Also, the materials should be organized for training. You should get a book that has slides and notes. Slides plus notes are what make training materials. Ask to look at a sample chapter. A course-book that is organized like an ordinary book with pages just full of text and no slides was not written for instructor-led training. Despite what some training vendors think.
A good instructor can teach you something new about the Linux kernel with a pointy stick and a spot of sand, but, the whole key to good training is to use your time in the most efficient manner possible. That's why there are organized training materials.
Training is about saving time. One could always learn the topic on their own. You are paying to have someone help you to learn, the topics that will help you the most, in much less time than it will take you on your own.
Training requires doing. Look at the exercises. The most important features of a great training class are the exercises. After all, the objective of training is to be able to *do something new* when you are done. Is "talking about the kernel" the new thing you want to do when you're done or is it to actually be able to write some code?
Linux has capabilities, and has had them as an integral feature for years. Root does not, necessarily have all powers on Linux system. That is just the way almost everyone does it.
A quick perusal of almost any kernel source will show that capabilities are queried throughout. It is not that one must be root - one must have the appropriate capability.
Linux is primitive as compared to some other UNIX(-like) systems in that it does not provide a convient mechanism for manipulating capabilites. But, they are there, and they work. I have created processes that were UID=0 (root) and they lacked many capabilities. This is more secure than the usual SUID and root has all capabilities situation that the vast majority of Linux systems have.
Also, many sites use "sudo" to avoid giving away a root password and as a means to limiting what commands individuals can run as root. This is almost fairly helpful, and avoids somewhat the need for a superuse.
Slashdot Mirror
I was curious to try and see Ridge A in Google Earth. GE didn't seem to know it. The images of Antarctica are for the most part really low rez. But, there are some interesting anomalies in GE. Firstly, there is a big white "frying pan" over the south pole, secondly, if I go to 90,90 (north pole) GE seems to have floating point problems. -90,90 seems to work. I get a kaleidoscope of blue vectors when I scroll in or out. Thirdly, if I try to go "to here", (Antarctica) from Cupertino, CA it says "We could not understand your search." Bummer.
Anyway, here is a quote from their Terms of Use agreement.
"It is important for you to refer to these Terms of Use from time to time to make sure that you are aware of any additions, revisions, or modifications that we may have made to these Terms of Use. Your continued use of the Website constitutes your acceptance of the new Terms of Use."
Is this a common practice. One has to agree to something that can change and you are obligated to adhere to these changes, too? How can this be legal?
There also spell out later their claim to intellectual property rights. Including "database rights." Is that a real right or are they just making that up?
They also state "You are responsible for... restricting access to your computer so that others may not access any password-protected portion of the Website or other Properties using your name..."
Yuck. Yuck. Yuck. Is this really worth their service?
1. A common killer in parallelization is false sharing. That is, threads on two processors fight over a cache-line even though they are accessing independent variables. A cache-line is typically bigger than an individual variable. The approach of using adjacent elements of an array for parallelism sounds naive. One needs to pad the array.
2. Updating a shared variable, especially a non-scaler, in an inner loop is naive. One should reference local scalers in inner loops when parallelizing. Just once, should the thread update the shared variable. Don't reference non-scalers or shared variables in an inner loop. Don't lock in the inner loop, either, if you can avoid it.
If it is not an inner loop then the locking is probably not a big issue any way.
3. Java, really, Java?
Related to this story is a follow-up: http://tierneylab.blogs.nytimes.com/2008/04/10/the-psychology-of-getting-suckered/#more-264 In this you read "In fact, when we presented probability puzzles including a version of Monty Hall and the Mr. Smith problem to 327 MBA students who had all been trained to use such computations, they were almost seven times as likely to rely on some form of the partition-edit-count strategy than an explicit computation. Strikingly, none of the MBA students who tried to compute the answer to these puzzles arrived at a correct solution." Anyone surprised?
A common issue in training is folks requesting training that covers more material than can be covered in the alloted time. However, when negotiating for training with a training provider, it is valuable to discuss the topic outline in advance and ask about changes. Since the topic of Linux kernel training is so broad, you should be able to narrow down the subjects that are most valuable to you.
A stock kernel course will have a mix of what the authors felt was most widely applicable. Or at least most applicable to their audience.
Here's a 2-day course from K Computing that selects what are widely held to be interesting topics: http://www.kcomputing.com/pdf/kernelinternals.pdf
The week long course from Red Hat (actually developed by Axian) covers much of the kernel.
Also, remember, it is the combination of training materials plus instructor that make the class. Who developed the materials? Who is the instructor?
For something like the Linux kernel, an instructor with a strong Linux programming background and education in computer science - say an advanced degree in computer science and 10 years or more of working with UNIX and five or more years with Linux is something to expect. Also, get an instructor when you want training. Get a practicing engineer when you want engineering.
Also, the materials should be organized for training. You should get a book that has slides and notes. Slides plus notes are what make training materials. Ask to look at a sample chapter. A course-book that is organized like an ordinary book with pages just full of text and no slides was not written for instructor-led training. Despite what some training vendors think.
A good instructor can teach you something new about the Linux kernel with a pointy stick and a spot of sand, but, the whole key to good training is to use your time in the most efficient manner possible. That's why there are organized training materials.
Training is about saving time. One could always learn the topic on their own. You are paying to have someone help you to learn, the topics that will help you the most, in much less time than it will take you on your own.
Training requires doing. Look at the exercises. The most important features of a great training class are the exercises. After all, the objective of training is to be able to *do something new* when you are done. Is "talking about the kernel" the new thing you want to do when you're done or is it to actually be able to write some code?
Linux has capabilities, and has had them as an integral feature for years. Root does not, necessarily have all powers on Linux system. That is just the way almost everyone does it. A quick perusal of almost any kernel source will show that capabilities are queried throughout. It is not that one must be root - one must have the appropriate capability. Linux is primitive as compared to some other UNIX(-like) systems in that it does not provide a convient mechanism for manipulating capabilites. But, they are there, and they work. I have created processes that were UID=0 (root) and they lacked many capabilities. This is more secure than the usual SUID and root has all capabilities situation that the vast majority of Linux systems have. Also, many sites use "sudo" to avoid giving away a root password and as a means to limiting what commands individuals can run as root. This is almost fairly helpful, and avoids somewhat the need for a superuse.