The idea for a plasma bolt to go through the air is to create a vacuum to send a very high power laser through without the problems of blooming. The plasma bolt itself would not itself be what causes all the damage.
I use PsPad because I can turn off coloring and just use bold and italics (and some other non color modifications). It is really nice when I need to print out the code to hand it in.
"Nreuuoms pmeeononnhs peossss uiapocmltecnd etaaoilxnpn; nwttdtsniinoahg, the pdseuo-snfiiiectc spssliiimtm is not snfiiiectc and eieecndvs are oetfn mdanleiisg"*.
Though it may be (almost) true, there is little evidence that an English university actually did studies that show this. For more information visit http://www.mrc-cbu.cam.ac.uk/~mattd/Cmabrigde/
If you use GTK# then Mono already is basically a stand in replacement for.NET. The largest unfinished portion of Mono is Windows.forms (but as the team of the op is a VB group they might not even actually know how to write Windows GUI, instead relying on the drag and drop interfaces provided by VB).
Look at everything that comes with the 17-inch MBP at 3099.00 (up ram to 2GB, switch to 7200 RPM drive)
Compare to a Inspiron E1705 after you have switched: to the 2.16Ghz processor to Windows XP Pro to the UXGA screen to 2GB DDR 667 ram to 100GB 7200 RPM drive and added the XP Pro reinstall disk and the internal bluetooth
After this the regular price for Dell is 3277.0 (on sale this week for 2556, and was 2970 last week).
After configuring the Dell to have almost the same configuration as the MacBook Pro at almost the same price. The main difference is that the MBP looks better.
Apple isn't that expensive, it just doesn't give you the cheap (low quality) way out.
As I read this, it seems quite analogous to objects in C++ (or any other OOL). All kernel interfaces could publish the data they want to have public, and hide the data that is private to the implementation of the feature.
I would suggest that this will eventually make its way into kernel systems (just like any other good idea that has come from the programming language fields).
By the way, I like the paper. I have wondered if anyone had decided to actually tried to do some of the very things that the paper discusses.
We investigate a multigrain parallelization approach for clusters built from: (1) conventional, single-thread, single-core processors, (2) low-end, commercially available SMTs and (3) simulated SMTs using modest and realistic architectural extensions for fine-grain synchronization and thread spawning
Having not finished reading the paper yet (only on the second page), is there a discussion in there about implementing multiple threads that share variables each individual computer (dual xeon HT, so 4 SMP threads should be able to run in tandem) and using message passing to send to other nodes in the cluster (a node now being a set of 4 threads on a machine) (that is what I am reading it to suggest in the italics above)? Does this yeild advantages over a system with 4 actual processors rather than 2?
if the cost of communication overwhelms the gain from doing the computation in parallel, then it doesn't scale.
Then the computation shouldn't be done in parallel. Instead, multiple instances of the computation should be done with different inputs.
I think we are talking about 2 different aspects of parallel computing. When I first read above I took it as if you are trying to solve parallel problems with shared variable computations (problems where the process of computing a set of results from a set of inputs is independant). Instead it appears that you are talking about using multiple processors to solve single instances of a parallel problem.
If this is the case, then you really are not looking for scalibility at all, the number of aspects of the problem that can be done in parallel is fixed for the problem. This being the case, shared memory is likely to be a very suitable aid in solving the problem.
You should never have to share an amount of data that it becomes impractical to send.
Message passing parallelism is not shared variable parallelism. They have different goals: Message passing is to do as much independant work as possible and then report on what happenned. Shared variable is to do as many instructions at the same time as possible.
Most of the shared variable algorithms I have come across are message passing in disguise. These implementations work very well for limited numbers of processors, and for limited amounts of data. After a certain point (depending on the algorithm) the shared variable implementations tend to be overtaken by the message passing implementations.
However this could just be my experience of implementing the algorithms on an 18 machine (dual xeon 3Ghz) cluster interconnected with a gigabit ethernet switch. The parallel "computer" isn't exactly designed so every processor has access to every byte of the 72GB of ram. If I was running on whatever today's equivalant to the Cray X-MP is I may have a different opinion.
Funny, I have yet to come across an algorithm that cannot be altered to scale very well with message passing (or be replaced with an algorithm that is better for large n and does scale with message passing). The algorithm may fair poorly when given only 2 or 3 threads in parallel or with less than say 10000 things that need to be done, but really that isn't much of a parallel problem at all.
Could you point me to some algorithm that doesn't scale and has no better replacement? I would really like to understand why it doesn't.
My AES code encrypts and decrypts perfectly without any mistakes (I have proven it to be exactly compliant with the published algorithm). But that isn't the point.
The point was if you need to ask slashdot about whether to trust a FIPS assured commercial vender or a heavily peer reviewed open source implementation there is something wrong (and I doubt you need the encryption at that point).
Encryption is based on the fact that you want certain people to hear you and others not to. To have people hear you you need to trust them (to some extent).
Acidently writing passphrases to swap/tmp is one such example
If this affects the integrity of the encrypted information, then you are already comprimised. Still, it is something to guard against (along with many other considerations) because it helps make other holes bigger.
You need to trust someone with securing your information so that the people you choose can see it.
You have several choices of who you are going to trust with this: 1: The commercial supplier in combination with the government 2: Open source developers and their claimed peer reviewers* 3: Yourself 4: Slashdot
The poster went straight to 4. I intended to question this with my post.
I do agree that an uninformed person would have a very difficult time getting the encryption economy working correctly the first time and because that is so, he/she aught to realize that there are other people in the world who they should trust. After all, the whole trust question could easily beg "Can the algorithm itself (and its designer) be trusted?" There was a whole philosophical idea that just went completely over the heads of most of the people who read this.
* Which, by the way, I do believe exist (other than myself). That is, I am fairly certain I am not the only one who has a decent grasp on the ideas, and I am not the only one of such people who have looked into various open source implementations. "Claimed" is there only because the hypothetical person asking the question would need to phrase it in such a way.
That's what I did (although I had to for a class assignment). The standards are all available, and it isn't hard at all to implement some of them, AES for instance is actually suprisingly simple to understand. My implementations (I wrote DES, 3DES, AES) are likely not secure against implementation attacks like time-attacks, but those attacks essentially require my system to already be comprimised.
Besides, this way you truly understand the algorithm.
If you have trouble deciding what type of implementation you are going to trust, you likely have far worse problems than which encryption method to trust (with both Open Source and FIPS compliant you are required to trust someone else, or to spend so much time pouring over the code to understand it, you might as well have written it yourself). However with Open Source you will at least be able to make the assumption that it was peer reviewed.
AFIAK, there is no actual exploit in the code provided. The virus only does things that a regular program should be able to do, given the correct permissions.
The virus, written in assembly, calls the kernel via a depreciated interface (int 0x80 instead of syscall). It happens to have a value in the ebx register that it needs after the (buggy) system call.
The bug in the kernel is due to the fact that gcc assumes the system call doesn't change user registers (which the kernel isn't suppossed to as a policy) so gcc forms code to make the system call in less time (less instructions, less overhead) by not caring about user registers. The fix for the bug simply restores the value of the ebx register to what it was before the system call, hence the bug now works (as it has the correct value in the ebx register).
Slashdot Mirror
The idea for a plasma bolt to go through the air is to create a vacuum to send a very high power laser through without the problems of blooming. The plasma bolt itself would not itself be what causes all the damage.
yeah, nano is so much better than pico!
(I have never noticed a difference, but then again all I use nano for is to make small changes to xorg.conf when I screw something up)
I use PsPad because I can turn off coloring and just use bold and italics (and some other non color modifications). It is really nice when I need to print out the code to hand it in.
http://www.pspad.com/
or even 2006-06-06 20:06.06+06
"Nreuuoms pmeeononnhs peossss uiapocmltecnd etaaoilxnpn; nwttdtsniinoahg, the pdseuo-snfiiiectc spssliiimtm is not snfiiiectc and eieecndvs are oetfn mdanleiisg"*.
Though it may be (almost) true, there is little evidence that an English university actually did studies that show this. For more information visit http://www.mrc-cbu.cam.ac.uk/~mattd/Cmabrigde/
If you use GTK# then Mono already is basically a stand in replacement for .NET. The largest unfinished portion of Mono is Windows.forms (but as the team of the op is a VB group they might not even actually know how to write Windows GUI, instead relying on the drag and drop interfaces provided by VB).
You should have a windows ME book in there too.
I don't think you read that right:
Look at everything that comes with the 17-inch MBP at 3099.00 (up ram to 2GB, switch to 7200 RPM drive)
Compare to a Inspiron E1705 after you have switched:
to the 2.16Ghz processor
to Windows XP Pro
to the UXGA screen
to 2GB DDR 667 ram
to 100GB 7200 RPM drive
and added the XP Pro reinstall disk and the internal bluetooth
After this the regular price for Dell is 3277.0 (on sale this week for 2556, and was 2970 last week).
After configuring the Dell to have almost the same configuration as the MacBook Pro at almost the same price. The main difference is that the MBP looks better.
Apple isn't that expensive, it just doesn't give you the cheap (low quality) way out.
No, the allure of the mac also has a lot to do with its pretty box.
Go to Dell and configure a laptop to be the same as a Macbook pro and compare the prices. There is very little differences there.
I am glad I am not the only one who read that.
As I read this, it seems quite analogous to objects in C++ (or any other OOL). All kernel interfaces could publish the data they want to have public, and hide the data that is private to the implementation of the feature.
I would suggest that this will eventually make its way into kernel systems (just like any other good idea that has come from the programming language fields).
By the way, I like the paper. I have wondered if anyone had decided to actually tried to do some of the very things that the paper discusses.
We investigate a multigrain parallelization approach
for clusters built from: (1) conventional, single-thread, single-core
processors, (2) low-end, commercially available SMTs and (3) simulated
SMTs using modest and realistic architectural extensions for
fine-grain synchronization and thread spawning
Having not finished reading the paper yet (only on the second page), is there a discussion in there about implementing multiple threads that share variables each individual computer (dual xeon HT, so 4 SMP threads should be able to run in tandem) and using message passing to send to other nodes in the cluster (a node now being a set of 4 threads on a machine) (that is what I am reading it to suggest in the italics above)? Does this yeild advantages over a system with 4 actual processors rather than 2?
if the cost of communication overwhelms the gain from doing the computation in parallel, then it doesn't scale.
Then the computation shouldn't be done in parallel. Instead, multiple instances of the computation should be done with different inputs.
I think we are talking about 2 different aspects of parallel computing. When I first read above I took it as if you are trying to solve parallel problems with shared variable computations (problems where the process of computing a set of results from a set of inputs is independant). Instead it appears that you are talking about using multiple processors to solve single instances of a parallel problem.
If this is the case, then you really are not looking for scalibility at all, the number of aspects of the problem that can be done in parallel is fixed for the problem. This being the case, shared memory is likely to be a very suitable aid in solving the problem.
You should never have to share an amount of data that it becomes impractical to send.
Message passing parallelism is not shared variable parallelism. They have different goals:
Message passing is to do as much independant work as possible and then report on what happenned.
Shared variable is to do as many instructions at the same time as possible.
Most of the shared variable algorithms I have come across are message passing in disguise. These implementations work very well for limited numbers of processors, and for limited amounts of data. After a certain point (depending on the algorithm) the shared variable implementations tend to be overtaken by the message passing implementations.
However this could just be my experience of implementing the algorithms on an 18 machine (dual xeon 3Ghz) cluster interconnected with a gigabit ethernet switch. The parallel "computer" isn't exactly designed so every processor has access to every byte of the 72GB of ram. If I was running on whatever today's equivalant to the Cray X-MP is I may have a different opinion.
Funny, I have yet to come across an algorithm that cannot be altered to scale very well with message passing (or be replaced with an algorithm that is better for large n and does scale with message passing). The algorithm may fair poorly when given only 2 or 3 threads in parallel or with less than say 10000 things that need to be done, but really that isn't much of a parallel problem at all.
Could you point me to some algorithm that doesn't scale and has no better replacement? I would really like to understand why it doesn't.
or get greasemonkey and the "Slashdot: italics swap, topic skin" (http://www.userscripts.com/scripts/show/2530)
Then edit the GM script whenever you feel like it.
Gentoo portage is bery BSD-ish (and I am almost certain you can build a Gentoo box on a BSD kernel or Darwin for that matter)
My AES code encrypts and decrypts perfectly without any mistakes (I have proven it to be exactly compliant with the published algorithm). But that isn't the point.
The point was if you need to ask slashdot about whether to trust a FIPS assured commercial vender or a heavily peer reviewed open source implementation there is something wrong (and I doubt you need the encryption at that point).
Encryption is based on the fact that you want certain people to hear you and others not to. To have people hear you you need to trust them (to some extent).
Acidently writing passphrases to swap/tmp is one such example
If this affects the integrity of the encrypted information, then you are already comprimised. Still, it is something to guard against (along with many other considerations) because it helps make other holes bigger.
No, it is about trust (the question, not FIPS).
You need to trust someone with securing your information so that the people you choose can see it.
You have several choices of who you are going to trust with this:
1: The commercial supplier in combination with the government
2: Open source developers and their claimed peer reviewers*
3: Yourself
4: Slashdot
The poster went straight to 4. I intended to question this with my post.
I do agree that an uninformed person would have a very difficult time getting the encryption economy working correctly the first time and because that is so, he/she aught to realize that there are other people in the world who they should trust. After all, the whole trust question could easily beg "Can the algorithm itself (and its designer) be trusted?" There was a whole philosophical idea that just went completely over the heads of most of the people who read this.
* Which, by the way, I do believe exist (other than myself). That is, I am fairly certain I am not the only one who has a decent grasp on the ideas, and I am not the only one of such people who have looked into various open source implementations. "Claimed" is there only because the hypothetical person asking the question would need to phrase it in such a way.
Thats kinda neat.
They are close. I suppose you could write a patch to make them pre compliant.
That's what I did (although I had to for a class assignment). The standards are all available, and it isn't hard at all to implement some of them, AES for instance is actually suprisingly simple to understand. My implementations (I wrote DES, 3DES, AES) are likely not secure against implementation attacks like time-attacks, but those attacks essentially require my system to already be comprimised.
Besides, this way you truly understand the algorithm.
If you have trouble deciding what type of implementation you are going to trust, you likely have far worse problems than which encryption method to trust (with both Open Source and FIPS compliant you are required to trust someone else, or to spend so much time pouring over the code to understand it, you might as well have written it yourself). However with Open Source you will at least be able to make the assumption that it was peer reviewed.
AFIAK, there is no actual exploit in the code provided. The virus only does things that a regular program should be able to do, given the correct permissions.
The virus, written in assembly, calls the kernel via a depreciated interface (int 0x80 instead of syscall). It happens to have a value in the ebx register that it needs after the (buggy) system call.
The bug in the kernel is due to the fact that gcc assumes the system call doesn't change user registers (which the kernel isn't suppossed to as a policy) so gcc forms code to make the system call in less time (less instructions, less overhead) by not caring about user registers. The fix for the bug simply restores the value of the ebx register to what it was before the system call, hence the bug now works (as it has the correct value in the ebx register).
I buy my PCs in pieces; they get nothing from me.
eh, /quantom/quantum/ ... Too bad I didn't preview.