Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
Yes, in some cases we (not me, I was just a contractor) loaded development tools, including an full IDE, onto the medical devices for development. The devices that go out to the customer do not have these tools loaded, of course.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
That's a valid concern, but the flipside is that DVCS allows you to commit early, and commit often. I often make small changes in my code, trying out different things, adding a function here, and it is not crucial for other developers to see these small changes immediately. However, they do see the changes -- every one of them, committed individually as I made them -- when I push to the server once I'm done working on a certain feature for the time being (at least once a day).
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
This isn't always possible. The company I worked for produced software that ran on medical instruments, unable to access the network for security reasons. You couldn't use centralized version control because you couldn't access a central server.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 3, Informative
Monotone's inode prints (which, incidentially, Linus was a major contributor of) can speed up some things, but the initial pull of a large repository is still unacceptably slow. The Pidgin developers have worked around this performance bottleneck by supplying bzip2'd Monotone databases via http, which the developer then can sync with the latest repository on pidgin.im to obtain an up-to-date database with the latest changes. Partial pulls should partially fix this problem in a future release of Monotone, or so I hear.
For what it's worth, I use Monotone daily and find the performance acceptable. For the record, Linus used Monotone at a particularly bad time it its development cycle, when it was very slow and the main designer was on vacation. Nonetheless, the Monotone developers emphasize correctness and integrity over speed, and Mercurial and Git were direct responses to the performance of Monotone. Still, the performance of Monotone is always improving.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
Exactly. With a centralized version control system (PVCS, which is not coincidentially listed as the riskiest bet on the Forrester Source Code Management comparison) I've used in the past at a large company, everyone ended up making several different local copies of the code with various changes, in order to revert if necessary. I was dumbfounded - isn't that what version control is for, to keep track of changes?
Re:Well, speaking from my own experience...
on
Linus on GIT and SCM
·
· Score: 5, Informative
Its been over a year so I don't remember the details of GIT, but I remember having to do a lot of things "twice". Need to do a checkout? Two commands. Need to commit? Two commands. It was a bitch to use and I am glad I'm done with it. SVN, on the other hand, I felt very comfortable with from the start
Most distributed version control systems exhibit this phenomena, because by "checking out" you are actually doing two operations: pulling the latest changes from someone else, and updating your workspace. For example, in Monotone you would type (I imagine git operates similarly):
mtn pull mtn update
The first command retrieves revisions from the server, and the second updates your workspace with those new changes. To "commit" a change, in a distributed version control system you first 1) commit the change to your local repository and then 2) push it to someone else:
mtn commit mtn push
It is often useful to keep these operations separate. For example, you can commit without pushing. Make a bunch of changes, commit each one separately, and only push once you're satisfied with the result. Other developers can still see each change you made individually, but only after you've pushed, so they won't be stuck with an incomplete in-progress version of the tree.
Similarly, by being able to update without pulling, you can revert to any revision you would like without contacting the network. Likewise, since commit does not require network access, it is no extra effort to work offline. Once an Internet connection is available, you can synchronize your repositories, but in the meantime you can make any change you want - even with no network connection.
The main disadvantage of a decentralized version control system is that it requires workflow changes to get the most out of it. If you are only familiar with centralized version control systems, it will take some time getting used to. But I'm glad to say, an increasing number of projects are making the change to distributed version control, among them, Mozilla and Pidgin. They are not using Git (but Mercurial and Monotone, respectively) but they're all distributed. Git is being used by the Beryl project, among others. Subversion has momentum in FOSS because it is familiar for those used to centralized version control (everyone knows CVS), and SourceForge provides free SVN hosting. Once a free open source hosting site provides hosting for a distributed version control system, I expect more low-resource open source projects to use it.
Re:Lemme check my last home appraisal...
on
Linus on GIT and SCM
·
· Score: 4, Informative
You hit the nail on the head. Distributed version control often comes with superior merging, making the process less painful and encouraging it to occur frequently. Monotone employs a 3-way merge, Codeville has an innovative merging algorithm, and some may even support 5-way merging ("left's immediate ancestor, left, merged, right, right's immediate ancestor") in the future.
In my experience, nearly all merges occur automatically and cleanly. Only if two developers modified code in conflicting areas of the source code do you have to merge manually--and even then, only one person has to do it. It is much better to have merging operate automatically and transparently when possible, than to have to have two people manually coordinate each and every one of their changes beforehand.
Distributed version control gaining ground in FOSS
on
Linus on GIT and SCM
·
· Score: 5, Informative
The ultimate reason why Linus dislikes SVN, CVS, etc. is that it is centralized. Everyone checks out source from a central server and commits their changes to the same centralized area. This has problems: your workspace is not versioned. By this I mean, you cannot track local changes to your workspace without committing them to the central server.
A common pattern in development is to try one approach, test it, tweak it, and possibly try another approach if the first did not work out, perhaps reverting to a prior approach. With decentralized version control, you can commit your changes to a local repository and work from there. All the locally changes you make are versioned, and be committed, checked out, examined all without contacting a central repository. This is ideal, because you often want to try various options to find the one that works best, before pushing your changes to the rest of the world. In centralized version control, you can use a branch for this purpose, but often branches in these systems are difficult to either create, merge, or maintain, so they are rarely used. The end result is that with centralized version control, developers version their workspace in their head. DVCS systems remove the mental burden.
Fortunately, FOSS developers are realizing the usefulness of DVCS and major projects are converting to some form of DVCS. Mozilla is switching to Mercurial. The Pidgin project, which just released 2.0.1, is using Monotone. (Linus favorably mentioned both of these distributed version control systems in his Git talk, as they are both are distributed).
Once you accept that DVCS is better than the centralized model (which may not be true for some situations), only a few (but growing number of) version control systems are viable. This is currently a hot area in open source development, with software such as GNU Arch, Monotone, Mercurial, Git, Darcs, Bazaar, and more paving the way. Many open source DVCS's are still in development and not ready for general usage. I can't speak for Mercurial, but Monotone doesn't have the greatest performance, instead preferring integrity over speed. This led Linus to write git, since speed is very crucial for a large project like the Linux kernel.
Whatever the actual program (git, Mercuial, or Monotone), more and more open source developers are realizing the advantages that distributed version control can offer. I encourage all developers that haven't used any DVCS to try it -- once you do, you won't go back.
cfq/ionice is for reads only. "Due to the complex path writes take to get to the io scheduler there is no ionice support for writes yes so they are all treated equally." It'll happen...
-What is "Backup HDDVD" for? It can do backup copies of HD DVD movies that YOU OWN! I don't want anyone to do piracy here! This software is a good way to protect your investment, because I have notice that this type of media seems very fragile, if it's scratched a little or dirty, it won't play. It seems less tolerent than DVD format. (Higher density!)
-What "Backup HDDVD" is doing exactly? This is a java based command line utility that decrypt video files (.evo) from a HD DVD disk that you own, to your hard drive and you can play them back with a HD DVD player software.
-What are the system requirements to use "Backup HDDVD" 1 - A Windows based system 2 - A HDDVD disk drive 3 - A HDDVD player software (like PowerDVD) 4 - A HDDVD movie(s) 5 - Java rutime 1.5 6 - The possibility to access the content of the disk with a drive letter under windows. (you may need UDF 2.5 file system driver for this) 7 - A lot of free hard disk space to backup your movies!
-Was your first HDDVD movie hard to decrypt?
It took me around a week to do. But I have wasted few days trying to work on too complicated approach. In fact, it is very simple.
-How do you do that?
The program itself has nothing special. It simply implement the AACS decyption protocol. I have followed the freely available documents about AACS Have a look at: www.aacsla.com The trick, is to find what they call the "Title keys". So I figure out how to extract them.
-How do you extract the "Title keys"?
I won't explain it in detail. Read the AACS doc first. You will understand. The title keys are located on the disk in encrypted form, but for a content to be played, it has to be decrypted! So where is the decrypted version of the title key? Think about it...
-What kind of crypto algorithms are involved? Standards algorithms:
ECC-160
AES-128 Look in the AACS doc for more details.
-What is the TKDB.cfg file? This is the Title key Database file. It holds the decryption keys for the movies.
-What is the format of this file? Field 1: SHA1 Hash of the VTKF000.AACS file on your HDDVD disk. Next fields are pipe "|" delimited. -Movie Title -A variable number of Title key, pipe delimited
You have a key number followed by the key value like:
12-08A3DC61910280F2...
Key values are 128 bits long, so 16 bytes, or 32 hexadecimal characters long.
-The TKDB.cfg file provided with your program is empty or incomplete, what can I do? Here is my TKDB.cfg:
CE6339246F34087AB355681DEB656D23DCD5BD86=Full Metal Jacket | 1-0000000000000000000000 0000000000 486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-0000000000000000000000 0000000000 3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-0000000000000000000000 0000000000
-What do you think of the technical aspects of AACS?
The design is not that bad, but it's too easy to have an insecure player implementation somewhere. And just one bad implementation is all it needs to get the keys! There will always be insecure implementations of a player somewhere! And the "Revocation system" is totaly useless if you use the Title key directly.
-Is there any known problems with the decryption? Yes. I call this problem the "Nav chain" bug. I realize that I have a lot of frame skipping at playback after the decryption, so I hunted down the problem. To avoid the frame skipping, I patch the video file. This fix allows smooth playback of the movie, but there are some side effects.
-What are the side effects of the "Nav chain" bug fix?
You cannot do fast forward, or backward using the round dial, but you can still use the progress bar to navigate through the film. So it's not that bad... For some reason, the sub-titles don't seems to work anymore. It may be a side
my $dbh = DBI->connect('DBI:mysql:database=reports;host=batg irl.gsu.edu','miker','poopie');
They're also using PostgreSQL, as described in the FAQ, but the FAQ has no mention of MySQL. Someone should probably change the MySQL password on batgirl.gsu.edu, if they haven't already.
Probably the most interesting features to programmers are the addition of the SQLite engine, and significant JavaScript enhancements heavily borrowed from Perl and Python. You can use generators (yield statement), Pythonic iterators, array comprehensions, and what the Mozilla people call "destructuring assignment". Some examples from the article for the curious:
/* Destructuring assignment example - swap two values */ [a, b] = [b, a];
/* You can return multiple values from functions now */ function f() { return [1, 2, 3]; } var [a, , b] = f(); document.write ("A is " + a + " B is " + b + "<BR>\n");
/* Easier fibonacci sequences with generators */ function fib() {
var i = 0, j = 1;
while (true) {
yield i;
var t = i; i = j; j += t;
} }
/* Array comprehensions */ var evens = [i for (i in range(0, 21)) if (i % 2 == 0)];
/* New scoping semantics with 'let' expression/definition/declaration */ if (x > y) {
let const k = 37;
let gamma : int = 12.7 + k;
let i = 10;
let function f(n) { return (n/3)+k; }
return f(gamma) + f(i); }
Try the Connelly Case (with pictures!)... I've been making them for all my CDs and DVDs since I came across that site in '04 and have been very satisified with the results.
The real way to do this is to write a MediaWiki extension, of course (look at ParseFunctions for an example of something simple), which is then accessed through the usual hooks, like {{foo:...}}, but don't ask me, I don't know that much about MW's internal structure. I just know bad ideas when I see them. =)
The {{foo}} (variables) syntax is possible to extend, but does not, as far as I have been able to tell, support parameters. So {{foo:...}} won't work. See the UserNameMagic extension for how to add a MediaWiki variable--it involves adding three or four hooks and callbacks.
The tag extensions are much easier. Call $wgParser->setHook("tag", "handleTag") and your function handleTag($input,$argv) will be called whenever <tag param1=value1 param2=value2...>$input</tag> is encountered.
Provided it's difficult to falsify RFID tags (and I think that's the idea)
AFAIK, that currently isn't the idea. Most newer tags can be reprogrammed and reused very easily. Reusing tags can save a lot of money and is a major goal in RFID technology. For example, in one application, high-temperature tags are embedded in a combustion engine during testing. The calibration/QA system reads the tags and performs tests accordingly. If everything checks out, the tag is removed and can be reused for the next unit.
Granted, when tags are cheap enough that reusing them is not worth it, reprogrammability may go out the window. But even then, it would take some serious effort to make tamper-proof RFID tags. Who knows--smart cards are already fairly secure; maybe future tags will include embedded processors with challenge/response authentication (difficult with the passive power requirements, but low-power chips and active tags are getting better). But for now, RFID tags are just a bag of bits.
Of course I've heard of tar, but it avoids the problem--it does not solve it. The AIM protocol fully supports transferring multiple files, and a good Linux AIM client would support this valuable feature.
A strong magnet is only one component of a cyclotron. Cyclotron's also require an electric field, produced by an alternating current of frequency f=qB/(2pi*m) (where q=the charge of the particle, B=magnetic field strength, m=mass). The electric field accelerates the charged particles at a=qE/m into a magnetic field, causing a curvature of radius r=mv/(qB). The particle will curve back and the electric field will accelerate it in the opposite direction. As the electric field accelerates the particles faster and faster, the radius of curvature will increase until the radius is large enough for the particle to exit the cyclotron and smash into something. Better particle accelerators have been developed for studying particle physics, however, as this article indicates, cyclotrons are still used in the field of nuclear physics. I, for one, would have no problem with a cyclotron in my back yard.
The absolute most important feature of any IM client is to allow entire directories to be transferred, rather than only individual files. All Linux AIM clients only allow single files to be transferred at once. This is a major flaw in every non-official AIM client on Linux.
... rather than the honeynet project who have better tools, and far more experience at this sort of thing?
I'd suspect that they are not involved because the original purpose of the Honeynet project is to study the attacker's tactics, NOT to report them to law enforcement. They even stated they do not intend to report the attackers, though I can't find the statement.
Slashdot Mirror
Yes, in some cases we (not me, I was just a contractor) loaded development tools, including an full IDE, onto the medical devices for development. The devices that go out to the customer do not have these tools loaded, of course.
That's a valid concern, but the flipside is that DVCS allows you to commit early, and commit often. I often make small changes in my code, trying out different things, adding a function here, and it is not crucial for other developers to see these small changes immediately. However, they do see the changes -- every one of them, committed individually as I made them -- when I push to the server once I'm done working on a certain feature for the time being (at least once a day).
This isn't always possible. The company I worked for produced software that ran on medical instruments, unable to access the network for security reasons. You couldn't use centralized version control because you couldn't access a central server.
Monotone's inode prints (which, incidentially, Linus was a major contributor of) can speed up some things, but the initial pull of a large repository is still unacceptably slow. The Pidgin developers have worked around this performance bottleneck by supplying bzip2'd Monotone databases via http, which the developer then can sync with the latest repository on pidgin.im to obtain an up-to-date database with the latest changes. Partial pulls should partially fix this problem in a future release of Monotone, or so I hear.
For what it's worth, I use Monotone daily and find the performance acceptable. For the record, Linus used Monotone at a particularly bad time it its development cycle, when it was very slow and the main designer was on vacation. Nonetheless, the Monotone developers emphasize correctness and integrity over speed, and Mercurial and Git were direct responses to the performance of Monotone. Still, the performance of Monotone is always improving.
Exactly. With a centralized version control system (PVCS, which is not coincidentially listed as the riskiest bet on the Forrester Source Code Management comparison) I've used in the past at a large company, everyone ended up making several different local copies of the code with various changes, in order to revert if necessary. I was dumbfounded - isn't that what version control is for, to keep track of changes?
Most distributed version control systems exhibit this phenomena, because by "checking out" you are actually doing two operations: pulling the latest changes from someone else, and updating your workspace. For example, in Monotone you would type (I imagine git operates similarly):
The first command retrieves revisions from the server, and the second updates your workspace with those new changes. To "commit" a change, in a distributed version control system you first 1) commit the change to your local repository and then 2) push it to someone else:
It is often useful to keep these operations separate. For example, you can commit without pushing. Make a bunch of changes, commit each one separately, and only push once you're satisfied with the result. Other developers can still see each change you made individually, but only after you've pushed, so they won't be stuck with an incomplete in-progress version of the tree.
Similarly, by being able to update without pulling, you can revert to any revision you would like without contacting the network. Likewise, since commit does not require network access, it is no extra effort to work offline. Once an Internet connection is available, you can synchronize your repositories, but in the meantime you can make any change you want - even with no network connection.
The main disadvantage of a decentralized version control system is that it requires workflow changes to get the most out of it. If you are only familiar with centralized version control systems, it will take some time getting used to. But I'm glad to say, an increasing number of projects are making the change to distributed version control, among them, Mozilla and Pidgin. They are not using Git (but Mercurial and Monotone, respectively) but they're all distributed. Git is being used by the Beryl project, among others. Subversion has momentum in FOSS because it is familiar for those used to centralized version control (everyone knows CVS), and SourceForge provides free SVN hosting. Once a free open source hosting site provides hosting for a distributed version control system, I expect more low-resource open source projects to use it.
You hit the nail on the head. Distributed version control often comes with superior merging, making the process less painful and encouraging it to occur frequently. Monotone employs a 3-way merge, Codeville has an innovative merging algorithm, and some may even support 5-way merging ("left's immediate ancestor, left, merged, right, right's immediate ancestor") in the future.
In my experience, nearly all merges occur automatically and cleanly. Only if two developers modified code in conflicting areas of the source code do you have to merge manually--and even then, only one person has to do it. It is much better to have merging operate automatically and transparently when possible, than to have to have two people manually coordinate each and every one of their changes beforehand.
The ultimate reason why Linus dislikes SVN, CVS, etc. is that it is centralized. Everyone checks out source from a central server and commits their changes to the same centralized area. This has problems: your workspace is not versioned. By this I mean, you cannot track local changes to your workspace without committing them to the central server.
A common pattern in development is to try one approach, test it, tweak it, and possibly try another approach if the first did not work out, perhaps reverting to a prior approach. With decentralized version control, you can commit your changes to a local repository and work from there. All the locally changes you make are versioned, and be committed, checked out, examined all without contacting a central repository. This is ideal, because you often want to try various options to find the one that works best, before pushing your changes to the rest of the world. In centralized version control, you can use a branch for this purpose, but often branches in these systems are difficult to either create, merge, or maintain, so they are rarely used. The end result is that with centralized version control, developers version their workspace in their head. DVCS systems remove the mental burden.
Fortunately, FOSS developers are realizing the usefulness of DVCS and major projects are converting to some form of DVCS. Mozilla is switching to Mercurial. The Pidgin project, which just released 2.0.1, is using Monotone. (Linus favorably mentioned both of these distributed version control systems in his Git talk, as they are both are distributed).
Once you accept that DVCS is better than the centralized model (which may not be true for some situations), only a few (but growing number of) version control systems are viable. This is currently a hot area in open source development, with software such as GNU Arch, Monotone, Mercurial, Git, Darcs, Bazaar, and more paving the way. Many open source DVCS's are still in development and not ready for general usage. I can't speak for Mercurial, but Monotone doesn't have the greatest performance, instead preferring integrity over speed. This led Linus to write git, since speed is very crucial for a large project like the Linux kernel.
Whatever the actual program (git, Mercuial, or Monotone), more and more open source developers are realizing the advantages that distributed version control can offer. I encourage all developers that haven't used any DVCS to try it -- once you do, you won't go back.
For anyone looking to just see Kishan's talk about protected processes, it starts at about 34:00 in this hour-long video.
He follows up with: "Except if you're in kernel mode, of course."
cfq/ionice is for reads only. "Due to the complex path writes take to get to the io scheduler there is no ionice support for writes yes so they are all treated equally." It'll happen...
B a c k u p H D - D V D F A Q
-What is "Backup HDDVD" for?
It can do backup copies of HD DVD movies that YOU OWN! I don't want anyone to do piracy here! This software is a good way to protect your investment, because I have notice that this type of media seems very fragile, if it's scratched a little or dirty, it won't play. It seems less tolerent than DVD format. (Higher density!)
-What "Backup HDDVD" is doing exactly?
This is a java based command line utility that decrypt video files (.evo) from a HD DVD disk that you own, to your hard drive and you can play them back with a HD DVD player software.
-What are the system requirements to use "Backup HDDVD"
1 - A Windows based system
2 - A HDDVD disk drive
3 - A HDDVD player software (like PowerDVD)
4 - A HDDVD movie(s)
5 - Java rutime 1.5
6 - The possibility to access the content of the disk with a drive letter under windows.
(you may need UDF 2.5 file system driver for this)
7 - A lot of free hard disk space to backup your movies!
-Was your first HDDVD movie hard to decrypt?
It took me around a week to do. But I have wasted few days
trying to work on too complicated approach. In fact, it is very simple.
-How do you do that?
The program itself has nothing special. It simply implement the AACS decyption protocol. I have followed the freely available documents about AACS
Have a look at: www.aacsla.com The trick, is to find what they call the "Title keys". So I figure out how to extract them.
-How do you extract the "Title keys"?
I won't explain it in detail. Read the AACS doc first. You will understand. The title keys are located on the disk in encrypted form, but for a
content to be played, it has to be decrypted! So where is the decrypted version of the title key? Think about it...
-What kind of crypto algorithms are involved?
Standards algorithms:
ECC-160
AES-128
Look in the AACS doc for more details.
-What is the TKDB.cfg file?
This is the Title key Database file. It holds the decryption keys for the movies.
-What is the format of this file?
Field 1: SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.
Next fields are pipe "|" delimited.
-Movie Title
-A variable number of Title key, pipe delimited
You have a key number followed by the key value like:
12-08A3DC61910280F2...
Key values are 128 bits long, so 16 bytes, or 32 hexadecimal characters long.
-The TKDB.cfg file provided with your program is empty or incomplete, what can I do?
Here is my TKDB.cfg:
CE6339246F34087AB355681DEB656D23DCD5BD86=Full Metal Jacket | 1-0000000000000000000000
0000000000
486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-0000000000000000000000
0000000000
3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-0000000000000000000000
0000000000
-What do you think of the technical aspects of AACS?
The design is not that bad, but it's too easy to have an insecure player implementation somewhere. And just one bad implementation is all it needs
to get the keys! There will always be insecure implementations of a player somewhere! And the "Revocation system" is totaly useless if you use
the Title key directly.
-Is there any known problems with the decryption?
Yes. I call this problem the "Nav chain" bug. I realize that I have a lot of frame skipping at playback after the decryption, so I hunted down the problem. To avoid the frame skipping, I patch the video file. This fix allows smooth playback of the movie, but there are some side effects.
-What are the side effects of the "Nav chain" bug fix?
You cannot do fast forward, or backward using the round dial, but you can still use the progress bar to navigate through the film. So it's not that bad... For some reason, the sub-titles don't seems to work anymore. It may be a side
from /Evergreen-ILS-1.0.1/Evergreen/src/extras/import/d rain-batgirl-charge.pl:
g irl.gsu.edu','miker','poopie');
#!/usr/bin/perl
use strict;
use DBI;
my $dbh = DBI->connect('DBI:mysql:database=reports;host=bat
They're also using PostgreSQL, as described in the FAQ, but the FAQ has no mention of MySQL. Someone should probably change the MySQL password on batgirl.gsu.edu, if they haven't already.
Good stuff.
Try the Connelly Case (with pictures!)... I've been making them for all my CDs and DVDs since I came across that site in '04 and have been very satisified with the results.
The {{foo}} (variables) syntax is possible to extend, but does not, as far as I have been able to tell, support parameters. So {{foo:...}} won't work. See the UserNameMagic extension for how to add a MediaWiki variable--it involves adding three or four hooks and callbacks.
The tag extensions are much easier. Call $wgParser->setHook("tag", "handleTag") and your function handleTag($input,$argv) will be called whenever <tag param1=value1 param2=value2...>$input</tag> is encountered.
AFAIK, that currently isn't the idea. Most newer tags can be reprogrammed and reused very easily. Reusing tags can save a lot of money and is a major goal in RFID technology. For example, in one application, high-temperature tags are embedded in a combustion engine during testing. The calibration/QA system reads the tags and performs tests accordingly. If everything checks out, the tag is removed and can be reused for the next unit.
Granted, when tags are cheap enough that reusing them is not worth it, reprogrammability may go out the window. But even then, it would take some serious effort to make tamper-proof RFID tags. Who knows--smart cards are already fairly secure; maybe future tags will include embedded processors with challenge/response authentication (difficult with the passive power requirements, but low-power chips and active tags are getting better). But for now, RFID tags are just a bag of bits.
The processor encodes the audio, not the CD drive. Good CD ripping programs will pipeline the encoding and ripping.
Inhalation of elemental mercury vapor is the most common route of exposure. When liquid mercury is spilled or allowed to come in contact with air, it evaporates.
Can you not get satellite TV because of regulations or some other reason?
A strong magnet is only one component of a cyclotron. Cyclotron's also require an electric field, produced by an alternating current of frequency f=qB/(2pi*m) (where q=the charge of the particle, B=magnetic field strength, m=mass). The electric field accelerates the charged particles at a=qE/m into a magnetic field, causing a curvature of radius r=mv/(qB). The particle will curve back and the electric field will accelerate it in the opposite direction. As the electric field accelerates the particles faster and faster, the radius of curvature will increase until the radius is large enough for the particle to exit the cyclotron and smash into something. Better particle accelerators have been developed for studying particle physics, however, as this article indicates, cyclotrons are still used in the field of nuclear physics. I, for one, would have no problem with a cyclotron in my back yard.
The absolute most important feature of any IM client is to allow entire directories to be transferred, rather than only individual files. All Linux AIM clients only allow single files to be transferred at once. This is a major flaw in every non-official AIM client on Linux.
I'd suspect that they are not involved because the original purpose of the Honeynet project is to study the attacker's tactics, NOT to report them to law enforcement. They even stated they do not intend to report the attackers, though I can't find the statement.