That's really, really, crucial here. The people who gain from peer review are _not_ really the experts. Ok, there's a gain by a first winnowing, but that's not really that much, if you look at what does get published.
For example, there is not a paper in my field (thin layer magnetism) where it matters one whit if it's been peer reviewed or not. Why? Because if it's a load of cobblers, I'll spot it. I don't need other peoples opinions.
Now, outside my field, I'll accept that peer review has some merit to me. The most notable one for me is the mathematical proofs, to be checked by other mathematicians [0]. On the other hand, in the abscence of a formal peer review stage pre publication, any errors would result in a Comment publication in response. I accept that that's a time lag - but I don't think that that time lag would be any greater than the formal peer review stage as is.
No, the people who gain from peer review are not the experts. They are the general public, and those learning, or branching out. A lack of a peer review step would make it more difficult for those people.
You'll find that the drive to opening of papers is primarily driven by the experts. I think that replacing the peer review step with a structed system of comments, and keeping those comments accesable with the paper, would benefit.
The counter point to this, is that by having greater access to papers, with comments, would give benefit to all, general public and experts alike. The end point would be a net gain for experts, and probably a gain for the general public - as more reading would be needed, but all that reading would be easily accessable.
Let me close this by re-iterating that the experts don't need peer review - which is why arXive.org and pre-prints are the stock in trade of many an expert.
[0] There are, of course, similar sections of related research for all fields.
Well, having been in a related situation, here's my story:
I was mugged, and the PIN to my debit card beaten out of me.
The bank pointed out that they had the PIN, therefore the bank wasn't liable. In addition, they argued, the crime wasn't reported to the police until after the money was removed. [0]
I accept that this is a different situation, in so much as it was a debit card, not a credit card. However, the legal situation is exactly the same - insofar as the argument of authorisation applies.
In the end, the bank gave me part of the money back, as a 'goodwill' gesture. Making it quite clear they didn't have to.
Note that this is a specific case of PIN being forcibly extracted - other forms of fraudulaent use will be covered as before.
Also note that if my signature had been forged, then that would have been clearly fraudulent. Because it was a number, it was considered authorised. This was despite injuries sustained in attepting not to reveal it.
As far as the law stands (UK), you give out the PIN, you are liable. Period.
[0] No shit, Sherlock. One went off with the card and PIN, whilst his (armed) mates stayed with me.
I've been there. I was mugged a few years ago, and my debit cards were taken. The muggers then demanded my PIN number.
So, I gave then a false number, and hoped to get away. Alas, one guy went off with the card, and I was push off the path to an underpass, pretty much out of sight of everywhere. I'll add that I was 25m from one University building, and 50m from the other, at this point.
Guy returns, I get a set of bruises, and then I give them the real PIN.
I'll further note that this was not an uncommon tactic, as the police were often heard to recommend getting the cash limit on the cards reduced, to minimise the loss in such an occasion.
Oh, if if you're mugged, they have taken your cell phone, so forget about that.
The abreviation of user you're looking for is/home. The names are shortened because there was a maximum length on filenames in UFS - 12 characters I think, or there abouts.
If I note that sbin means system binaries (i.e. the minimal set of programs to get booted, and administration programs), then the existance of/sbin and/usr/sbin should be clearer. That is,/sbin contains those special programs (e.g. init) and administrative programs (e.g. fsck) that would be reasonably needed before mounting another partition in the bootup process. Once/usr was mounted, the majority of the system binaries were in/usr/sbin.
That's not to say that it was a good idea, or that it is a good idea, but that's why it's the way it is.
The one good thing about such a standard is that I can get put infront of any flavour of Unix (or unix-like system), and do basic sysadmin stuff, like configure a network, install sshd &c. This was very useful when we were getting a lot of odd machines for work - I've used 8 different 'Nix varients in anger, without any documentation save sometimes some man pages installed. That's what any new filesystem layout must compete with - portable knowledge (same sort of thing that helps keep X11 around).
To end, I'll agree that the current windows set up for where files go is, indeed, very nice. The problem is the few applications that don't care, and user hardcoded paths. Those (legacy apps, if you will) cause a lot of pain, and is why most people I know are administrator on thier boxes all the time. It's been caught by, essentially, lazy programmers. I expect that similar problems (although hopefully disimilar solutions) will arise with any Linux distro that moves paths around.
It does mean that if StupidWebForum.cgi is compromised, and the data it stores in the database is compromised, the data columns that SecurePayrollApp use are still encrypted.
In other words, yes, if you break an app, you get _it's_ data, but you don't get any data that other apps might have in the database. That's a significant win if you have a few applications, with only a small shared data set between them, as now sloppy code elsewhere _isn't_ your problem.
'Course, if you've got everything in one table, then your still screwed, but roll on thrid cannonical form, and fine grained encryption.
GPL does not allow for revocation, nor for additional clauses to be added at a later date [0].
Now, if SCO are in breach of the liscence, then that's one thing, and then the copyright holder is entiled to seek relief. However, until and unless they break the liscence (or the law), they can continue to use the software.
This was intentional in the design of the the GPL. It doesn't allow for picking and choosing of who can benefit. That's the breaks for choosing Free software. If it could be revoked, then it's not Free.
[0] There is the question of the 'or later version' clause, but that's at the option of the liscence, I believe. And that has to be a version that the FSF publishes, presumably on the understanding they wouldn't endanger the Freedoms granted in the liscence.
This is online as a historical document, not as a new summons. Complience with it is now a moot point (unless there was something really freaky going on that we're not aware of), given they were due by 21st Nov 2003.
If speakers are of an active (powered) kind, then initialising the DAC's without setting the volume to zero results in an audable click or pop on the speaker, if they are on. For a large amp / speaker combo, this can, in principle do some damage to the cones or the hearing of someone listening [0].
Secondly, if the volume is not set to zero, where should it be set to? That's not answerable. You can take a guess, but it's might well be too high, or too low. Too low is less of a problem than too high, hence leaving it at zero.
So, the kernel sound drivers leave the system muted, and place the volume setting in the hands of the init scripts, or equivelent. That way, the values can be adjusted without changeing the kernel, which makes much sense.
I agree that the distro aught to do something sensible with the volume settings - at install time, set the sliders to 0, and unmute, then prompt the user to tweak to the settings they want, or something like that. This, of course, depends on the distro.
[0] Although anyone playing with such a system who didn't take precautions is pretty stupid. (large, in this context, is around 1-5 kW or bigger)
This has a major and significant differnece from the previous attempts.
It does not rely on the host's immune system.
Let me repeat that: This method will work on an infected host that has _no_ immune system. This is a totally radical approach - modern disease treatments use microbiology to harrass the disease, to weaken it so the host immune system cleans it up (e.g. antibiotics), or train the immune system to target the disease (that's your vacines and serums, and probably other things too).
If HIV didn't wreck the host's immune system, it'd would be at least partially controlled by now, either by vaccine, symtomatic stasis or maybe even a cure.
This apporach fights HIV with the same resources that HIV uses, thus where ever HIV can thrive, it can be fought. That's a major step forward.
The main reason the scientist wouldn't be too worried about mutation is that it would be cheap to develop a new counter-virus. If it takes $200,000 from cold, well, that's trival on the scale of big pharma - and would come down. I can't see the mutation rate being an issue - if it mutates, develop another strain to handle that.
I agree with you on the controllable front. However, it's not going to be spread differently from HIV. So, if you introduce it to HIV sufferers, then the containment protocol will be the same as they already have to maintain. That's not a big issue. The only problem is a mutation that turns this into virulent virus - but then again, HIV is already fatal. If it ends up killing 1% of those treated with it, those are odd I'd take, if I had HIV. Hell, I'd take it at a 7-10% fatality rate, depending on the overall results.
Compile Jave to J-code, Java to native, and J-code to native. Is GPL'd. With libgcj to provide the API's.
Besides, I think your comment about closed-source language are off base. A language must be well specified to be useful, and thus an opensource compiler/interpeter can be written, always. The only issue with this would be patents, and I would agree that using a patented language would be a problem.
It was Windscale -> Sellafield, not the other way around. Another old name for it was Calder Hill (technically, a site that's next door to the Windscale reactors).
Thorp is a particular plant at the site, and is quite distinct from the reactors there. Got it's own set of foibles, to be sure, but a different set. See, e.g. http://www.zetron.com/pages/english/realw/real09 3. html
One of the biggest differences between MPEG4 and MPEG2 codecs is the seek times - that's the time between keyframes or I-frames (same thing, different terms).
The typcial keyframe rate in MPEG4 stuff is around 8-10 seconds. In MPEG2 it tends to be around 2-5 ms, which is about as good as the eye gets, apparently. So, if you watch it from start to finish, that's fine - but if you want to do anything non-linear, MPEG2 gives a good win.
In terms of broadcasting, you need to add the seek time onto the total 'tune in to pictures' latency. Remember that this is applied everytime that you change channel, and it's pretty clear that 8-10 seconds is way too much.
Also, MPEG4 is a much more complex beast, with things like motion compensation much greater than MPEG2. This is where MPEG2 wins ove MPEG4. Consider a slowly panning camera, over a scene that changes slowly, with a foreground object - think left to right pan over a nature scene with birds and gentle breeze, with the presenter in the foreground. In the low bandwidth limit, MPEG4 will approximate this to a static background, and just move it. However, as the bandwidth improves, it uses this a baseline, and records deltas to it. In the high bandwidth limit, it can be seen that this is a lot more work than just recordsing the background as a much simpler object, rather than all the moving, and altering. Doing it the way that works at low bandidth is actually more expensive, then, for the high bandwidth situation. MPEG4 _can_ drop all that, and just to it the simple way (as MPEG2 would do), but doesn't have to.
There are many more, similar, examples. The short answear is that if you set the keyframe interval short, and give it lots of bandwidth, MPEG4 can be as good as MPEG2 - but can also be much worse (in terms of picture quality vs bandwidth, and CPU required). MPEG2 is a lot more dependable in this case. Plus, if you set the keyframe intervals to match, I have a sneaky feeling that MPEG2 will have a slight win here.
I take your point - most of this application, like many, is in principle doable independant of the underlying OS.
However, there are a few pluses on the side of Linux for this application.
2 GB+ files. Some versions of Win32 can do them, some can't. Some can only do it with a following wind. When you're talking scientific data, such file sizes can crop up often, if not a regular feature.
Network independance. This is less of an issue for display, but on the processing side, being able to coordinate multiple tasks, spread across many servers, from one desktop is a big win. Particualrly when it's a 'free' side effect (requires no extra programming). Four boxes are cheaper than a quad box - by quite a sizeable margin.
Which leads us on to the scheduler - with Win2K, a background number crunch task will take longer than on Linux, and impact interactive response more. That's not off the top of my head - that's based off my Linux/KDE desktop and my office mates Win2K systems doing the same tasks (computational chemistry, so essentially big matrix sums).
There's also library support. Not such a big one, as they can be ported, but it's more work that way. By libraries, I mean things like FFTW, LAPACK and BLAS.
So, that's a few areas with modest wins for unix/KDE. I'll add that headless admin for Unix is simpler than for Windows, which helps with the headless cruncher boxes, and conclude that there is a reason that unix is popular in universities, as it's got a slight edge.
Yes, it may well have been as easy to write for Win32 as KDE [0] - but in use, the linux is better for the number crunching.
[0] I wouldn't agree to that personally, but there's a degree of personal preference in there, so that's not objective.
The reason such things are expensive (and will likely remain so), is because with no moving parts, you have to have connectors to each bit of storage. That's a lot of interconnects requires, which takes up space, adding to the cost. Once you have a large enough array of bits, the routing of the data and address lines becomes the dominant factor in the construction.
Although this may sound similar at the level of description given in the articles, don't let the journalists deep and impressive knowledge of this technology blind you.
The devices that are being talked about work in profoundly different ways to the old ST506 disks. Plus that fact that spintronics has been expanded to cover anyhting with magnets doesn't help clarification much.
For example, despite zdnets claims that IBM use GMR heads in their hard disks - that's not true, they are spin valves. These show a change in elecrical resistance in the prescence of a magnetic field - but no where near the magnitude of effect of a GMR device. That's fundementally different from the older method used in the read heads, which was to have a coil of wire, and detect the current induced in that coil.
If you can align the spin of electrons (do-able), then you can orient the spin, and thus have two independant channels within a single wire (horizontal and vertical, or whatever you want to call them). That's pretty novel.
The origin of the problems is typical heavy metal toxicity - lead has many available electron orbitals that can form weak bonds with proteins. At the active sites of enzymes, where there are many ligands on the protein, the heavy metal can sit in there, and bind tighter than the intended species. This essentially blocks the action of those affected enzymes. Different heavy metals have different affinities for different enzymes [0], so have different effects, but that's the general mechanism for heavy metal poisioning.
The next problem is that because the metals bind to proteins, they stay there, so that as each plant or animal is consumed, there is a concentrating action as you move up the food chain. Thus, for example, herbivourus fish might collect a small quantiy of mercury, the fish that eat them have more, and the tuna that eat those have even more. Ok, that's not lead, but I can't reacall a specific example for lead at the moment - the principle still holds. It's worth noting that the typical human diet puts them at the top of the food chain.
There is a difference between lead as a metal, and lead in a compound. It should be clear that the lead that is the problem is bioavailable lead - a solid lump of the metal might not be the biggest source of lead - although I suspect that chewing on a block of lead would be as bad, or worse than the paint.
With lead in a fish tank, I suspect that the lead forms a thin layer of an oxide or similar, that reduces the rate the metal dissolves at. This is similar to aluminum and chromium, but I think it's less efective. The small lead released would probably be less damaging to the fish that the effect of other metals (for example, iron would make the tank acidic, aluminium would make it alkaline, and so on). That's a case of minisming hard (although I'd suggest that a plastic would probably be better).
[0] Non enzyme proteins tend not have that many bindable sites, and those that do generally don't suffer much. It's principly enzyme blocking that's a problem, in general.
With a strong enough, light enough magnet and efficient enough servos, you could make a difference in power on the drive shaft greater than the input electricity.
I assert that you cannot, on the basis of thermodynamic principles. Do you have calculations to back up your point of view? (I'd scribble down some numbers, but there are an infinite possible arrangements, so I can't disprove your point without calculating for all of them. You'd only have to produce a single example - therefore, the burden of proof must fall to your side in this case).
I think that you are wrong. Note that you will need a detailed model on the rate of demagnetisation of your permenant magnets - the maximum rate of energy extractable is related to the rate of demangetisation, right? Yet you havent actually showen where it fits in to your device - this strikes me as a serious flaw in your theory. Still, until you produce a detailed enough model to do calculations with, I'm afriad I can say no more.
Note that the above calculates the total energy involved in the magentic states, and shows that even if all that energy was extractable, then it would be insufficent.
A similar argument applied to the chemical energy in (say) iron would give a number that is around 1000 times greater than the energy that is extratactable by chemical reactions (such as burning or other oxidation reactions). Were there a method for extracting the magnetic energy [0], then I would be very surprised if the accesable portion of the magnetic energy was a significantly greater part than that.
This is not important to my argument above, but might be relevent if you try to use the above back-of-envelope sums for anything else.
[0] I'll repeat myself - I'm not aware of any, and this would be of import in my research area.
Yes, those magnets are exerting a force on each other.
No, that force doesn't 'come from nowhere' any more that the between my desk and my monitor 'comes from nowhere'
Yes, a permentant magnet will lose the observed properties (the macroscopic dipole). Eventually the magnetic domains will end up cancelling each other out. It's a relativly slow process (years typically to noticability, at room temperature), even in the situation you give (opposed magnets).
The fallacy in your logic is to assume that a static force and a force with motion are the same thing. They are not.
Consider the monitor on my desk (or yours, if that's simpler). There is a force from the desk on the monitor holding it up (other wise, it would fall to the earth, due to gravity). Work done is force * distance [0, and thus, as the monitor is not moving, no work is being done. Now, if you move that monitor, work is being done.
Thus it is with magnets - In this case, if the magnets are permentant, there is as much total force forward as backwards, during a full rotation. If the elecromagnets are use to push the ring round, then that is the source of energy.
Magnets, particulalry permenant magnets, are indeed a reservoir of magnetic potential energy.
This energy is small. Like, really small. I'm involved with calculations on magnetic materials, and we typically use units of meV (milli electron Volts) for a magnetic interaction coefficent. That's 1.602 x 10^-22 Joules. Values are typically between around 2 up to maybe 30. Might be higher with the special rare-earths, dunno.
Iron has 8 interactions per atom. Thus, a magnetic energy of the order of 2 * 10^-20 J per atom. One mole of iron will therefore have of the order of 2 * 10^-20 * Avagadro's number = 2 * 10^-20 * 6 * 10^23 = 12 * 10^3 J. That's 12 kJ of magnetic energy, in 55g of the stuff. [0]
So, a post about says that the moter has a discrepancy of 1.2 W (can't get to the article myself). With 55g of iron permenant magnets then, that's enough to run that system for 10 000 seconds. Might sound a lot, but that's 2.7 hours. If I'm within an order of magnitude, that's a runtime of the system of around a day at most, assuming 100% conversion of the magnetic energy into rotational energy. [1]
No. There is not enough magnetic energy in the parmenant magnets.
[0] In fact, I think that you could only get 1/2 of that out. Still, I'm ignoring that, cos I think that this is only within an order of magnitude.
[1] Which I doubt. A lot. In fact, I've never seen any suggested method for doing that.
Take the source IP, add a password, take a one way hash. Include this hash in the knocking packets.
Now, if you've sniffed the packets, then you won't know the password. So, you can spoof the source IP, in which case the port will be opened _for that IP only_, or you can send the knocking packets from you IP, in which case, you need that password, or you've just advertised yourself as a hacking attempt.
In order to prevent a single password for everyone situation, it's not hard to include a user ID in the packets.
Does need the application or firewall to allow connections to and from specific IP's only - but I really can't see that being an issue.
Nuclear reactors have a lot of design time to make sure they work. They're also made to exacting tolerances - thus things like the surface roughness are precisly known and controlled.
More importantly, a boiling water reactor uses the water as a moderator. When as a gas, it's much less effective as a moderator than as a liquid. This operates as a feedback system (too much heat generated - water boils - reaction rate slows - system cools), which is critical to the design here. The water would be more efficent at cooling, if the system was run at a lower temperature. However, the system of reactor - turbine - generator is more efficent as a whole when the water is run near it's boiling point (because the heat exchanging systems work more efficently with a greater temperature differenctial).
So, yes, it is used in those cases - but that's not the most efficent method of using the water _as a coolant_. Within a microprocessor, you have no feedback loop to reduce heat production when the temperature peaks the boiling point [0], and no desire to maximise the running temperature.
Personally, I'll stick with water for electronics cooling.
Worth noting, however, that LINPACK is a linear algebra package (think matrix math, and related areas). You are right that LINPACK was written to take best advantage of parrallelism. Linear algebra is a really common thing that people want to do - for example, the majority of computational chemistry comes down to linear algebra as the slow part. So, whilst it's not a worst case benchmark, there is a reason that it was chosen, as it's an average case benchmark.
If so, the lack of support for 3D is because Nvidia decided not to let people know how the hardware works, but instead to require you to use thier binary driver. See the Nvidia website for thier driver.
Slashdot Mirror
... if you are an expert in the field.
That's really, really, crucial here. The people who gain from peer review are _not_ really the experts. Ok, there's a gain by a first winnowing, but that's not really that much, if you look at what does get published.
For example, there is not a paper in my field (thin layer magnetism) where it matters one whit if it's been peer reviewed or not. Why? Because if it's a load of cobblers, I'll spot it. I don't need other peoples opinions.
Now, outside my field, I'll accept that peer review has some merit to me. The most notable one for me is the mathematical proofs, to be checked by other mathematicians [0]. On the other hand, in the abscence of a formal peer review stage pre publication, any errors would result in a Comment publication in response. I accept that that's a time lag - but I don't think that that time lag would be any greater than the formal peer review stage as is.
No, the people who gain from peer review are not the experts. They are the general public, and those learning, or branching out. A lack of a peer review step would make it more difficult for those people.
You'll find that the drive to opening of papers is primarily driven by the experts. I think that replacing the peer review step with a structed system of comments, and keeping those comments accesable with the paper, would benefit.
The counter point to this, is that by having greater access to papers, with comments, would give benefit to all, general public and experts alike. The end point would be a net gain for experts, and probably a gain for the general public - as more reading would be needed, but all that reading would be easily accessable.
Let me close this by re-iterating that the experts don't need peer review - which is why arXive.org and pre-prints are the stock in trade of many an expert.
[0] There are, of course, similar sections of related research for all fields.
Well, having been in a related situation, here's my story:
I was mugged, and the PIN to my debit card beaten out of me.
The bank pointed out that they had the PIN, therefore the bank wasn't liable. In addition, they argued, the crime wasn't reported to the police until after the money was removed. [0]
I accept that this is a different situation, in so much as it was a debit card, not a credit card. However, the legal situation is exactly the same - insofar as the argument of authorisation applies.
In the end, the bank gave me part of the money back, as a 'goodwill' gesture. Making it quite clear they didn't have to.
Note that this is a specific case of PIN being forcibly extracted - other forms of fraudulaent use will be covered as before.
Also note that if my signature had been forged, then that would have been clearly fraudulent. Because it was a number, it was considered authorised. This was despite injuries sustained in attepting not to reveal it.
As far as the law stands (UK), you give out the PIN, you are liable. Period.
[0] No shit, Sherlock. One went off with the card and PIN, whilst his (armed) mates stayed with me.
I've been there. I was mugged a few years ago, and my debit cards were taken. The muggers then demanded my PIN number.
So, I gave then a false number, and hoped to get away. Alas, one guy went off with the card, and I was push off the path to an underpass, pretty much out of sight of everywhere. I'll add that I was 25m from one University building, and 50m from the other, at this point.
Guy returns, I get a set of bruises, and then I give them the real PIN.
I'll further note that this was not an uncommon tactic, as the police were often heard to recommend getting the cash limit on the cards reduced, to minimise the loss in such an occasion.
Oh, if if you're mugged, they have taken your cell phone, so forget about that.
/usr is an abreviation of UNIX system resources.
/home. The names are shortened because there was a maximum length on filenames in UFS - 12 characters I think, or there abouts.
/sbin and /usr/sbin should be clearer. That is, /sbin contains those special programs (e.g. init) and administrative programs (e.g. fsck) that would be reasonably needed before mounting another partition in the bootup process. Once /usr was mounted, the majority of the system binaries were in /usr/sbin.
The abreviation of user you're looking for is
If I note that sbin means system binaries (i.e. the minimal set of programs to get booted, and administration programs), then the existance of
That's not to say that it was a good idea, or that it is a good idea, but that's why it's the way it is.
The one good thing about such a standard is that I can get put infront of any flavour of Unix (or unix-like system), and do basic sysadmin stuff, like configure a network, install sshd &c. This was very useful when we were getting a lot of odd machines for work - I've used 8 different 'Nix varients in anger, without any documentation save sometimes some man pages installed. That's what any new filesystem layout must compete with - portable knowledge (same sort of thing that helps keep X11 around).
To end, I'll agree that the current windows set up for where files go is, indeed, very nice. The problem is the few applications that don't care, and user hardcoded paths. Those (legacy apps, if you will) cause a lot of pain, and is why most people I know are administrator on thier boxes all the time. It's been caught by, essentially, lazy programmers. I expect that similar problems (although hopefully disimilar solutions) will arise with any Linux distro that moves paths around.
It does mean that if StupidWebForum.cgi is compromised, and the data it stores in the database is compromised, the data columns that SecurePayrollApp use are still encrypted.
In other words, yes, if you break an app, you get _it's_ data, but you don't get any data that other apps might have in the database. That's a significant win if you have a few applications, with only a small shared data set between them, as now sloppy code elsewhere _isn't_ your problem.
'Course, if you've got everything in one table, then your still screwed, but roll on thrid cannonical form, and fine grained encryption.
GPL does not allow for revocation, nor for additional clauses to be added at a later date [0].
Now, if SCO are in breach of the liscence, then that's one thing, and then the copyright holder is entiled to seek relief. However, until and unless they break the liscence (or the law), they can continue to use the software.
This was intentional in the design of the the GPL. It doesn't allow for picking and choosing of who can benefit. That's the breaks for choosing Free software. If it could be revoked, then it's not Free.
[0] There is the question of the 'or later version' clause, but that's at the option of the liscence, I believe. And that has to be a version that the FSF publishes, presumably on the understanding they wouldn't endanger the Freedoms granted in the liscence.
Read the document, it's data November 2003
This is online as a historical document, not as a new summons. Complience with it is now a moot point (unless there was something really freaky going on that we're not aware of), given they were due by 21st Nov 2003.
If speakers are of an active (powered) kind, then initialising the DAC's without setting the volume to zero results in an audable click or pop on the speaker, if they are on. For a large amp / speaker combo, this can, in principle do some damage to the cones or the hearing of someone listening [0].
Secondly, if the volume is not set to zero, where should it be set to? That's not answerable. You can take a guess, but it's might well be too high, or too low. Too low is less of a problem than too high, hence leaving it at zero.
So, the kernel sound drivers leave the system muted, and place the volume setting in the hands of the init scripts, or equivelent. That way, the values can be adjusted without changeing the kernel, which makes much sense.
I agree that the distro aught to do something sensible with the volume settings - at install time, set the sliders to 0, and unmute, then prompt the user to tweak to the settings they want, or something like that. This, of course, depends on the distro.
[0] Although anyone playing with such a system who didn't take precautions is pretty stupid. (large, in this context, is around 1-5 kW or bigger)
This has a major and significant differnece from the previous attempts.
It does not rely on the host's immune system.
Let me repeat that: This method will work on an infected host that has _no_ immune system. This is a totally radical approach - modern disease treatments use microbiology to harrass the disease, to weaken it so the host immune system cleans it up (e.g. antibiotics), or train the immune system to target the disease (that's your vacines and serums, and probably other things too).
If HIV didn't wreck the host's immune system, it'd would be at least partially controlled by now, either by vaccine, symtomatic stasis or maybe even a cure.
This apporach fights HIV with the same resources that HIV uses, thus where ever HIV can thrive, it can be fought. That's a major step forward.
The main reason the scientist wouldn't be too worried about mutation is that it would be cheap to develop a new counter-virus. If it takes $200,000 from cold, well, that's trival on the scale of big pharma - and would come down. I can't see the mutation rate being an issue - if it mutates, develop another strain to handle that.
I agree with you on the controllable front. However, it's not going to be spread differently from HIV. So, if you introduce it to HIV sufferers, then the containment protocol will be the same as they already have to maintain. That's not a big issue. The only problem is a mutation that turns this into virulent virus - but then again, HIV is already fatal. If it ends up killing 1% of those treated with it, those are odd I'd take, if I had HIV. Hell, I'd take it at a 7-10% fatality rate, depending on the overall results.
gcj
Compile Jave to J-code, Java to native, and J-code to native. Is GPL'd. With libgcj to provide the API's.
Besides, I think your comment about closed-source language are off base. A language must be well specified to be useful, and thus an opensource compiler/interpeter can be written, always. The only issue with this would be patents, and I would agree that using a patented language would be a problem.
It was Windscale -> Sellafield, not the other way around. Another old name for it was Calder Hill (technically, a site that's next door to the Windscale reactors).
Thorp is a particular plant at the site, and is quite distinct from the reactors there. Got it's own set of foibles, to be sure, but a different set. See, e.g.
http://www.zetron.com/pages/english/realw/real0
One of the biggest differences between MPEG4 and MPEG2 codecs is the seek times - that's the time between keyframes or I-frames (same thing, different terms).
The typcial keyframe rate in MPEG4 stuff is around 8-10 seconds. In MPEG2 it tends to be around 2-5 ms, which is about as good as the eye gets, apparently. So, if you watch it from start to finish, that's fine - but if you want to do anything non-linear, MPEG2 gives a good win.
In terms of broadcasting, you need to add the seek time onto the total 'tune in to pictures' latency. Remember that this is applied everytime that you change channel, and it's pretty clear that 8-10 seconds is way too much.
Also, MPEG4 is a much more complex beast, with things like motion compensation much greater than MPEG2. This is where MPEG2 wins ove MPEG4. Consider a slowly panning camera, over a scene that changes slowly, with a foreground object - think left to right pan over a nature scene with birds and gentle breeze, with the presenter in the foreground. In the low bandwidth limit, MPEG4 will approximate this to a static background, and just move it. However, as the bandwidth improves, it uses this a baseline, and records deltas to it. In the high bandwidth limit, it can be seen that this is a lot more work than just recordsing the background as a much simpler object, rather than all the moving, and altering. Doing it the way that works at low bandidth is actually more expensive, then, for the high bandwidth situation. MPEG4 _can_ drop all that, and just to it the simple way (as MPEG2 would do), but doesn't have to.
There are many more, similar, examples. The short answear is that if you set the keyframe interval short, and give it lots of bandwidth, MPEG4 can be as good as MPEG2 - but can also be much worse (in terms of picture quality vs bandwidth, and CPU required). MPEG2 is a lot more dependable in this case. Plus, if you set the keyframe intervals to match, I have a sneaky feeling that MPEG2 will have a slight win here.
I take your point - most of this application, like many, is in principle doable independant of the underlying OS.
However, there are a few pluses on the side of Linux for this application.
2 GB+ files. Some versions of Win32 can do them, some can't. Some can only do it with a following wind. When you're talking scientific data, such file sizes can crop up often, if not a regular feature.
Network independance. This is less of an issue for display, but on the processing side, being able to coordinate multiple tasks, spread across many servers, from one desktop is a big win. Particualrly when it's a 'free' side effect (requires no extra programming). Four boxes are cheaper than a quad box - by quite a sizeable margin.
Which leads us on to the scheduler - with Win2K, a background number crunch task will take longer than on Linux, and impact interactive response more. That's not off the top of my head - that's based off my Linux/KDE desktop and my office mates Win2K systems doing the same tasks (computational chemistry, so essentially big matrix sums).
There's also library support. Not such a big one, as they can be ported, but it's more work that way. By libraries, I mean things like FFTW, LAPACK and BLAS.
So, that's a few areas with modest wins for unix/KDE. I'll add that headless admin for Unix is simpler than for Windows, which helps with the headless cruncher boxes, and conclude that there is a reason that unix is popular in universities, as it's got a slight edge.
Yes, it may well have been as easy to write for Win32 as KDE [0] - but in use, the linux is better for the number crunching.
[0] I wouldn't agree to that personally, but there's a degree of personal preference in there, so that's not objective.
but are expensive. Battery backed RAM disks.
The reason such things are expensive (and will likely remain so), is because with no moving parts, you have to have connectors to each bit of storage. That's a lot of interconnects requires, which takes up space, adding to the cost. Once you have a large enough array of bits, the routing of the data and address lines becomes the dominant factor in the construction.
Although this may sound similar at the level of description given in the articles, don't let the journalists deep and impressive knowledge of this technology blind you.
The devices that are being talked about work in profoundly different ways to the old ST506 disks. Plus that fact that spintronics has been expanded to cover anyhting with magnets doesn't help clarification much.
For example, despite zdnets claims that IBM use GMR heads in their hard disks - that's not true, they are spin valves. These show a change in elecrical resistance in the prescence of a magnetic field - but no where near the magnitude of effect of a GMR device. That's fundementally different from the older method used in the read heads, which was to have a coil of wire, and detect the current induced in that coil.
If you can align the spin of electrons (do-able), then you can orient the spin, and thus have two independant channels within a single wire (horizontal and vertical, or whatever you want to call them). That's pretty novel.
The origin of the problems is typical heavy metal toxicity - lead has many available electron orbitals that can form weak bonds with proteins. At the active sites of enzymes, where there are many ligands on the protein, the heavy metal can sit in there, and bind tighter than the intended species. This essentially blocks the action of those affected enzymes. Different heavy metals have different affinities for different enzymes [0], so have different effects, but that's the general mechanism for heavy metal poisioning.
The next problem is that because the metals bind to proteins, they stay there, so that as each plant or animal is consumed, there is a concentrating action as you move up the food chain. Thus, for example, herbivourus fish might collect a small quantiy of mercury, the fish that eat them have more, and the tuna that eat those have even more. Ok, that's not lead, but I can't reacall a specific example for lead at the moment - the principle still holds. It's worth noting that the typical human diet puts them at the top of the food chain.
There is a difference between lead as a metal, and lead in a compound. It should be clear that the lead that is the problem is bioavailable lead - a solid lump of the metal might not be the biggest source of lead - although I suspect that chewing on a block of lead would be as bad, or worse than the paint.
With lead in a fish tank, I suspect that the lead forms a thin layer of an oxide or similar, that reduces the rate the metal dissolves at. This is similar to aluminum and chromium, but I think it's less efective. The small lead released would probably be less damaging to the fish that the effect of other metals (for example, iron would make the tank acidic, aluminium would make it alkaline, and so on). That's a case of minisming hard (although I'd suggest that a plastic would probably be better).
[0] Non enzyme proteins tend not have that many bindable sites, and those that do generally don't suffer much. It's principly enzyme blocking that's a problem, in general.
I assert that you cannot, on the basis of thermodynamic principles. Do you have calculations to back up your point of view? (I'd scribble down some numbers, but there are an infinite possible arrangements, so I can't disprove your point without calculating for all of them. You'd only have to produce a single example - therefore, the burden of proof must fall to your side in this case).
I think that you are wrong. Note that you will need a detailed model on the rate of demagnetisation of your permenant magnets - the maximum rate of energy extractable is related to the rate of demangetisation, right? Yet you havent actually showen where it fits in to your device - this strikes me as a serious flaw in your theory. Still, until you produce a detailed enough model to do calculations with, I'm afriad I can say no more.
Note that the above calculates the total energy involved in the magentic states, and shows that even if all that energy was extractable, then it would be insufficent.
A similar argument applied to the chemical energy in (say) iron would give a number that is around 1000 times greater than the energy that is extratactable by chemical reactions (such as burning or other oxidation reactions). Were there a method for extracting the magnetic energy [0], then I would be very surprised if the accesable portion of the magnetic energy was a significantly greater part than that.
This is not important to my argument above, but might be relevent if you try to use the above back-of-envelope sums for anything else.
[0] I'll repeat myself - I'm not aware of any, and this would be of import in my research area.
Yes, those magnets are exerting a force on each other.
No, that force doesn't 'come from nowhere' any more that the between my desk and my monitor 'comes from nowhere'
Yes, a permentant magnet will lose the observed properties (the macroscopic dipole). Eventually the magnetic domains will end up cancelling each other out. It's a relativly slow process (years typically to noticability, at room temperature), even in the situation you give (opposed magnets).
The fallacy in your logic is to assume that a static force and a force with motion are the same thing. They are not.
Consider the monitor on my desk (or yours, if that's simpler). There is a force from the desk on the monitor holding it up (other wise, it would fall to the earth, due to gravity). Work done is force * distance [0, and thus, as the monitor is not moving, no work is being done. Now, if you move that monitor, work is being done.
Thus it is with magnets - In this case, if the magnets are permentant, there is as much total force forward as backwards, during a full rotation. If the elecromagnets are use to push the ring round, then that is the source of energy.
[0] for a constant force.
Magnets, particulalry permenant magnets, are indeed a reservoir of magnetic potential energy.
This energy is small. Like, really small. I'm involved with calculations on magnetic materials, and we typically use units of meV (milli electron Volts) for a magnetic interaction coefficent. That's 1.602 x 10^-22 Joules. Values are typically between around 2 up to maybe 30. Might be higher with the special rare-earths, dunno.
Iron has 8 interactions per atom. Thus, a magnetic energy of the order of 2 * 10^-20 J per atom. One mole of iron will therefore have of the order of 2 * 10^-20 * Avagadro's number = 2 * 10^-20 * 6 * 10^23 = 12 * 10^3 J. That's 12 kJ of magnetic energy, in 55g of the stuff. [0]
So, a post about says that the moter has a discrepancy of 1.2 W (can't get to the article myself). With 55g of iron permenant magnets then, that's enough to run that system for 10 000 seconds. Might sound a lot, but that's 2.7 hours. If I'm within an order of magnitude, that's a runtime of the system of around a day at most, assuming 100% conversion of the magnetic energy into rotational energy. [1]
No. There is not enough magnetic energy in the parmenant magnets.
[0] In fact, I think that you could only get 1/2 of that out. Still, I'm ignoring that, cos I think that this is only within an order of magnitude.
[1] Which I doubt. A lot. In fact, I've never seen any suggested method for doing that.
Meh, throw some cryptography into the mix.
Take the source IP, add a password, take a one way hash. Include this hash in the knocking packets.
Now, if you've sniffed the packets, then you won't know the password. So, you can spoof the source IP, in which case the port will be opened _for that IP only_, or you can send the knocking packets from you IP, in which case, you need that password, or you've just advertised yourself as a hacking attempt.
In order to prevent a single password for everyone situation, it's not hard to include a user ID in the packets.
Does need the application or firewall to allow connections to and from specific IP's only - but I really can't see that being an issue.
Problem solved.
Nuclear reactors have a lot of design time to make sure they work. They're also made to exacting tolerances - thus things like the surface roughness are precisly known and controlled.
More importantly, a boiling water reactor uses the water as a moderator. When as a gas, it's much less effective as a moderator than as a liquid. This operates as a feedback system (too much heat generated - water boils - reaction rate slows - system cools), which is critical to the design here. The water would be more efficent at cooling, if the system was run at a lower temperature. However, the system of reactor - turbine - generator is more efficent as a whole when the water is run near it's boiling point (because the heat exchanging systems work more efficently with a greater temperature differenctial).
So, yes, it is used in those cases - but that's not the most efficent method of using the water _as a coolant_. Within a microprocessor, you have no feedback loop to reduce heat production when the temperature peaks the boiling point [0], and no desire to maximise the running temperature.
Personally, I'll stick with water for electronics cooling.
It's called UNICOS, or at least it is on the T3E I use. Although it's not strictly a cluster OS (the nodes are not independant machines).
Worth noting, however, that LINPACK is a linear algebra package (think matrix math, and related areas). You are right that LINPACK was written to take best advantage of parrallelism. Linear algebra is a really common thing that people want to do - for example, the majority of computational chemistry comes down to linear algebra as the slow part. So, whilst it's not a worst case benchmark, there is a reason that it was chosen, as it's an average case benchmark.
I suspect that your 3D card is a Nvidia card?
If so, the lack of support for 3D is because Nvidia decided not to let people know how the hardware works, but instead to require you to use thier binary driver. See the Nvidia website for thier driver.