A (somewhat) closed system. In Counter-Strike, each gameserver is its own instance of the game world.
So, what you do on your server (and it has to be your server, in order to be able to tweak the options like you want), you can do this. But it won't affect anyone else.
encryption: HTTPS authentication: HTTP Basic over HTTPS, or certificate based authentication over HTTPS transaction management: WS-Coorination.
I mean, you can use WS-Security; WS-SecureConversation and all that XMLSecurity jazz, but frankly, why bother when HTTPS just plain woks? (You probably have to give up on the 'firewall friendly' approach of everything over port 80, but that is a significant step forward in my book.)
naming: I'll give you that. UDDI feels overengineered for what it's normally used for. On the other hand, why are you looking for a public UDDI registry? The Registry is essentially the single point of contact for a particular application; thus you normally would want to keep some level of control over it. On the other hand, for public acces web serivces, have a look at Xmethods (which does offer a UDDI query interface).
Oh, and I disagree that Axis is any good at all, especially not in performance terms. In fact, Axis 1 is the second slowest (and second worst) way of using SOAP (Axis 2 is the only thing worse). If you want something fast, try GSOAP and C++. (To elaborate: every call made with Axis is essentially a dynamic call, the 'compilation' just writes code to change the defaults. This is a very poor design if you want performance, as you can optimise a SOAP engine a lot if you know the schema at compile time - and I'argue that's the most common use case.
Web serivces have the potential to be approximately the same speed as CORBA, if they're not, look at your middleware..NET web services are about 2 or 3 times faster than Axis, from our benchmarks (which did use stateful web services via WSRF, but I don't believe that distorts the timings apprechiably.) GSOAP is about 5 times faster.
Java RMI can always be faster, because it knows that the classes is needs are already on both sides of the wire or that it can get the actual class directly. That's not possible in a language independant system, where instead you have to give a description of the objects. Also, RMI can pass richer objects than SOAP can, (SOAP is can't pass objects with methods, just data holders). That allows for better architectures to be generated, also improving speed.
No, but I'll wager that you often encase yourself in a cage with a 'heat-generating gasoline-powered device', and strap yourself to it.
By the way, you are aware that lithium batteries are toxic, explosive, flammable, and generate lots of heat, aren't you?
My point is that the relative risk of a well designed methanol fuel cell is no greater than the current technology risks that most people consider acceptable. It just because it's unfamiliar that the risk is perceived as greater (a well understood phenomenon about people and risk assessment, by the way.)
Although... I'd actually agree with you about phones. (Personally, I don't have one, but I agree 4 days on a charge is fine.) I want a fuel cell for my laptop though - that's where the sweet spot is - cheap, easily refueled, long run times. For people who're often away from a wall socket, being able to take 4 days of laptop run time with you easily and cheaply is a very nice feature.
You are conflating 'energy density of a compound' and 'energy density of a compound that we can extract as electricity in a controlled fashion'.
Indeed, there exists more energy dense compounds that are currently used in batteries. But getting the energy out is tricky. Never mind future batteries - you know that about current lithium polymer batteries loose about 3% of stored energy on 'self protection circuits' - i.e. not bursting into flames at awkward moments...
And, for a true comparison, you're not looking at batteries, but at rechargeable batteries. Rechargeable batteries have poorer energy density that primary cells - you're effectively giving up some storage for the ability to recharge it. Things that store lots of energy in bonds are very difficult to do reverse reactions with. In particular, you need a molecule where the 'charging' reaction doesn't go anywhere near a spontaneous decomposition route. Given how messy electrochemical reactions get after a few charging cycles, this gets tricky.
To be fair, I'm not an expert in batteries (I'm materials, and stuff I was looking was relevant to batteries, but that's a separate thing), so I'm always a little behind, and this may have changed. I'd love for there to be a factor of 2 improvement in rechargeable batteries; but I'm not expecting it.
(Aside: I should point out that the 5-10% was an improvement in state of the art batteries, which lead current commercial batteries by some amount (probably another 5-10%, but that's a guess). So there's a bit to go there too.)
That is, the petrol (gasoline, for the North Americans) is, to a first approximation, just as toxic as methanol. When was the last time you heard of someone suffering from petrol poisoning, in any non-trivial (meaning, fixed with 5 minutes of fresh air) manner?
The reason methanol seems more dangerous is that if you contaminate beverages with it, you don't notice it's there until you've consumes a lot. Pure methanol doesn't have that problem. (On the downside, it is absorbed through the skin, so that's not good. Still, when was the last time you got petrol on your hands, in other than a trivial fashion?).
In summary, yes, it's unpleasant. But, in the opinion of this chemist, no more unpleasant that a large number of other substances that we manage to handle quite safely. Just don't drink it.
On battery density - forget it. Battery energy density is on a negative exponential decay - there's just a limit to how much energy you can have in there, and we're at something like 85% of that, IIRC. Power density is improving, but it's better life that you really want, which is energy density. Everyone I know that does reaserch into batteries (that's about 30 people over 7 labs) basically thinks that batteries are more or less as good as they get - there's maybe another 5-10% improvement in energy density, but that's about it.
And, of course,.xxx ==.sex; within the meaning of the RFC.
I wish more people were aware of this RFC - it seems to have fallen under the radar for the current spate of domain name based porn separation politics, which is a shame.
The short version is that it's unenforcable: domain names are _not_ cannonical names for internet activities, therefore, it's trivial to have multiple names for a host. Therefore you have to work out what to do when someone points a non.xxx domain at a host that has porn on it. This need not be an intentional 'Joe job', but can be perfectly legitimate.
This is all totally seperate from the whole debate over what is and isn't 'pornography' - that is not decidable outside a handful of special cases.
The reason fuel cells are much hyped, and preferred over batteries is that they use liquids to produce the electricity. This means that the size of the reaction interface is decoupled from the energy storage medium (whereas in a battery, they are intimately linked [normally]).
So, the size of the reaction interface determines the power that you can get out of the fuel cell, and the size of the energy reservoir determines how long it will last.
A laptop draws, what, 100 watts peak? A car with an 80 hp engine is at 60 kW - 600 times more. A fuel cell big enough to power that would be prohibitive in cost. Not to mention, the fuel cell will degrade with time - impurities in the fuel, and (if it's a polymer cell), degradation in the polymer itself.
Next point is the fuel medium. The energy density of methanol is less than gasoline, at about 22MJ/kg vs 45MJ/kg for gasoline. So, assuming comparable fuel efficency with the internal combustion + mechanical drive vs fuel cell + motors, you'd need twice as much fuel.
There are no good fuel cells that operate on gasoline - the more complex the hydrocarbon, the harder it is to build a fuel cell. Couple that with the way the sulpher tends to kill fuel cells, and it's not feasable (low sulpher gasoline is available - have you ever seen guarenteed no sulpher gasoline?)
So, it would cost more, and you'd only get half the distance on a single tank of methanol. Assuming that you can get the methanol. The whole fuel distribution problem is a seperate case.
All the numbers here are conservative - I'm sure my powerbook draws significantly less than 100W, 80 hp is at the low end for a car - I believe 100hp is more typical. The laptop fuel cells don't use pure methanol, it's methanol and water, further reducing the energy density.
There's a 40MW storage plant down in England somewhere. Unfortunalty, I can't did out any links to a page about the plant. It was Regenesys energy storge was bought out by VRB recently, a bromine / sodium bromide plant.
It's basically a giant battery, with liquid electrolytes. This means that the maximum power is determined by the size of the electrode (a conductive plastic in this case, IIRC), and the maximum storage is determined by the size of the liquid storage tanks (about 200 hours at 40 MW IIRC, or maybe 200MWh).
The cute thing about it is that it scale well - want more power, add another section of electrodes; want more energy storage, add more tanks - modulo the usual engineering problems.
I strongly suspect that it is not possible to craft a virus [0] so that it's indistinguishable from a piece of commercial software - unless it it's functionally identical (in which case... the point is moot).
The core argument is that a virus scanner that uses signature matching can match on any part of the virus. It is therefore insufficient to have only part of the virus matching code from some false positive source - all subsequences of the virus must make a false positive in some other known good software. If there is one subsequence (which need not have a unity nor regular step) that is unique to the virus, then that is sufficient to detect it unambiguously.
Given that (for the code segments), the sequence of bytes of the code corresponds with a behavior [1], or partial definition of a behaviour, to have all subsequences match with some other known good software, then all behaviours the virus embodies must match with behaviours present in known good software. Whilst there is the possibility of code in the virus to match with data in some other known good software, I think that the chances of a suitable match are so small as to be unsuitable for use as part of a deliberate strategy [2].
[0] or trojan, worm, spyware or other malware - I shall use just the term virus for simplicity here. [1] This is less true on architectures with variable length instructions, where by changing the start of a subsequence can totally alter the behaviour it represents. [2] Unless the malware code is deliberately inserted into the data sections of the known good software. This is almost tautologically impossible.
Trademark is specific to a specific 'trade'. So, actually, I _could_ make a move called 'Revenge of BitTorrent', and that would be fine [0]. I just couldn't make a swarmcast filetransfer application and call _that_ BitTorrent (Or, possible any file transfer application - the edges of a given 'trade' are, as always, a little grey).
Thus, I could quite happily sell a hot beverage called Ford, in a cup of a style that I trademark Mercedes, with a Porchse stirring rod, and there's nothing the car companies can do (unless they have a product within the relevent trade spaces).
Classic example: Apple computer and Apple records.
[0] Well, no trademark infringement. The movie would suck, 'cos I'm real bad at making movies.
True. However, that's not the problem. It dosen't really matter how hard it is to copy a film, it's currently happening.
At the moment, with film, it's not economic to roll out a film everywhere at once. Therefore there is a time lag between the first showings, and when it's available to view locally. This time lag is where the pirates are operating. If you can remove this lag, then one of the benefits of pirated films (faster access) is removed. Digital projectors bring the benefits of digital copying to the movie producers, as opposed to currently, where only the pirates are reaping the benefits.
As I understand it then, Bollywood is trying to defeat piracy by starving the pirates of a market.
It turns out that the better question to ask is: Why is (opaque substance X) not transaprent?
This is because the 'natural motion' (whatever that may mean) of a beam of light it to pass right through somthing, unless stopped.
Once you answer the question of opacity in general, then the reason that glass is transparent [0] is answered: by the absence of anything to make it opaque.
There are, from memory, two major causes of opacity.
Every surface will scatter some light. Indeed, you can see a reflection in a window, even for a material that is accepted 'transparent'. This is the reason that snow quartz is white and opaque, and rock crystal is clear, despite being exactly identical [1] in chemical composition. Snow quartz is make up of very many small grains, and at the boundary between these grains, a small part of the light is scattered. This mounts up through the thickness of the material, and the result is white and opaque. Rock crystal have very large grains - indeed, it's possible to get lumps that are single crystal as large as several feet across. In practice, one or two grain boundaries can't be seen by the naked eye.
You can also get quartz (same chemical composition again [1]) that has 'small ish' grains. A lump about 3 to 4 inches across will be translucent - you can see light through it, vaguely make out dark patches and light patches when you look throuugh it, but no more detail than that. That just happens to have a grain boundary density somewhere in the middle, to produce this effect.
Glass, as in window glass, is made in such a way that there are no grain boundaries in it. It's actually totally different to the crystaline substances I mentioned above, but the principles of transparency are the same. Glass is an amorphous solid, sometimes described as a 'supercooled liquid'. Indeed, the very conept of grain boundaries can only be found in substances with long range order - i.e crystals, so you'd never get opacity produced in a liquid or a glass from this origin.
Other than grain boundaries, the other major cause of internal changes of surface is a mixture of a solid and something else. This can be two solids (fine dust inside a glass will make it look opaque), a liquid or a gas (the white effect on ice cubes is air that was dissolved in the water, but can't disolve in ice. This forms tiny [and not so tiny] bubbles inside the ice, giving the white bands common to homemade ice cubes.)
So that's one way something can be opaque. Onto an other, and to being, let's also consider colour.
Specifically, lets think about ruby (which is red), and sapphire (which is any colour but red, lets think blue, and clear). Both are mostly the same material, aluminium oxide (Al203), which is clear in a pure, single crystal. Gem quality ruby and sapphire are single crystals, so there are no internal surfaces to scatter light. You can see clearly through such gems, but the light that gets through them is coloured by the material.
In ruby, there is a small quantity of chromium ions present distributed through the structure. These chromium ions absorb light in the visible spectrum (which then gets reemmited in a random direction, somtimes as the same colour, more often as light of longer wavelength [some sort of infra red typically]). The titanium and iron in a blue sapphire do the same sort of thing [2], but the light absorbed results in a different colour.
As I've implied, the exact wavelengths of light absorbed are determined by the chemical make up of the substance. All substances have paricular wavelengths of light that they will absorb - it is only where a substance absorbes strongly in the visible region of light that colour arises. Most materials absorb in the infrared and ultraviolet, depending on what process occurs when it absorbs light.
There are a few more, more obscure, methods of generating colour - if the particle size of a dust is similar to the wavelength of light, then it'll show a colour,
Isn't there a difference in energy between the spin states?
Not normally, no, in general.
You can find some situations where there is a difference in the energy between the two states. The most common one is the application of a magnetic field - then, the spin state that is most aligned to the field is favoured over the other one.
The other major case is in chemcial species that have partially filled orbitals. Most of these tend to have a net magnetic moment anyway, but are much more complex, and less generally applicable.
Given the presence of a magnetic field merely changes the potential landscape, no work is going to be done.
By analogy - if you want all the cars on a road to be on the left hand side - block the right hand side of the road off. Once the block is in place, no other work need be done to ensure that all the cars are on the left. (That's a sucky analogy, but it's the best I can think of).
.. it's with the people who own and run the site the ad's are on.
Re:Perhaps the SCM Solution is not the problem
on
Linus Drops BitKeeper
·
· Score: 5, Insightful
I'm not convinced by your arguments, although I do note that most of the sub-points are valid. Specifically, I reject your conclusion.
If Linus did Linux the *BSD way, a few things would have to change.
Firstly, and foremostly, he would have to develop, and guide, the userland as well. That is part of the reason for the apparent stability of BSD interfaces - for some kernel->userland interfaces the implemetnation is hidden (for example, things that are used only by libc). Whether this is a good or bad thing on the partof the BSD's is irrelevent, it is a fundementaly different approach.
Currently, Linux provides a set of kernel level interfaces, and the GNU libc utiliese some of these to provide the standard C library. Some of the kernel interfaces are standard, (POSIX file stuff, sockets etc), some are not (Firewall, some threading interfaces etc).
Most fundementally, the reason I reject your conclusion can be best expressed as a question: "If the linux process is so poor, why is it more popular than *BSD?"
One can discuss that question ad nauseum, but I suspect that part of the reason is that it is _not_ tightly controlled. If you have a method for making some part better, the Linux apprach says: show me the code, convince us it's better. The *BSD approach says: Show me the code, convince us it's better, get somone on the core team to sponser it, shedule it for the next (or prehaps one after next) release, and wait.
Thus, Linux has a lot more mobility, and can utilise new approaches sooner than *BSD - for good or ill [0].
My personal thoughts is: Linux is not broken. The development model works as well now as it used to, thus there is no need to change. Let the two approaches co-exists, let people use whichever they feel like. If that means that Linux becomes a testbed for ideas, and *BSD cherry pick, then so be it, that's fine. If that means that Linux evolves and *BSD stagnates, so be it, that's fine. If that means that Linux is unstable and *BSD is stable, so be it, that's fine. In practice, the last two will be indistinguishable for a long time after one of them occurs.
Let them be different - choose your favourite model, and be happy with it. But if the other one results in something you prefer, consider that both are trade-offs, and neither is perfect.
[0] This can bring problems. The various VM saga's are prehaps a canonnical example here.
I don't belive that the claim is that thier new batteries have three times the capacity of a current Li-ion battery. They are claiming three times the power, which I read as meaning that the peak discharge power is three times greater.
This is a lot more reasonable, from my understanding of Li-ion batteries. The theoretical energy capacity isn't three times current batteries, IIRC, so trippling that is unreasonable. But three times the discharge rate is not impossible, and brings them into the range of NiMH batteries, maybe even Lead-Acid. Coupled with the superior energy density of Li-ion, that's very very nice.
This matches well with the claim of faster charging - the limiting factors for charging and dischargeing are related in batteries.
So, your sums become 4Ah in 5 minutes, or a much more reasonable 48 amps. A lot, yes, but not beyond what's currently done with medium current applications.
Reading the press relase as I did above imedialty makes is much more reasonable, although I'd love to get more details. There's a lot hingeing on the word 'power', depending whether you read it in a technical or common definition, so much so that I wouldn't want to depend on it.
Roughly speaking, you don't use acid because you would need too much of it, and it sucks at cutting, and at giving neat edges. Oh, and resists are difficult, and it's slow.
Resists: You need something that is resistant to the acid, but can be applied neatly, and removed neatly afterwords. It needs to adhere well to the metal surface, yet be resistant to the acid and to water, and any by-product produced. Also, it needs to be resistant to exfoliation - as you start to etch, it's no good if your resist falls off around the cut. Oh, and it needs to be cheap and easily available.
Rates: Acid is slow. Or, rather, acid's that you would want to use for this purpose are slow. Anything that can eat through steel or aluminum at a decent rate is not something you want to handle. (Consider: What do you store it in, and what do you do the reaction in? Both are doable - but not strightforward). So you're left with acids that don't eat the metal very fast.
Edges: With an electrical current, you can ensure that the direction of cutting is more or less perpindicular to the surface of the metal (that's why it's two large plates, for example). With an acid, that's not the case. They will tend to etch out round indentations under the edges of the resist - giving you razor sharp edges to your cut out. Which would need filed down afterwords, and means there is a minium thickess of cut, proprtional to the thickness of the sheet.
My back of envelope sums suggest that the miniumum width of cut by acid etch is roughly equal to the thickness of the material, assuming an infitessimally small start. For 1.2 mm sheet metal, that's a 1.2 mm width - easily doable with a Dremel.
It would also take around 3-4 months, I think.
Acids are good at etching a surface layer. I would use an acid if I wanted a matt surface - for example, to etch details onto sheet metal. A combination of cut outs and etching would work very well in giving a unique appearence to a panel.
To back up the parent poster, consider the following:
We are unable to predict the electron density at a specific point in a a metal wire, at a given time.
Yet, we _are_ able to predict the total behaviour of electricty in a wire. Given that electricity is motion of electrons, how does this arise?
Well, this is a common situation, where models of behaviour at different scales are related only through a very small number of parameters.
For example, we can predict the magnetic behaviour of a system from just two parameters (for an binary antiferromagnet), yet to calculate the behaviour of the electrons (which cause said magnetism) takes of the order of 100 or so (and about 15 orders of magnitude longer).
So for practical calculations on magnatic things, you don't need to do the quantum mechanical calculations, just the much simpler ones.
Sure, technically these are inaccurate. In my experience, we're off by 0.001%, and by about 3-5% in the second derivative. That's so accurate, that there are very many additional cases where the calculations show two possible results, and the experiments arn't accurate enough to tell these apart. Or, in plain terms, good enough.
I use magnetism and electricity as examples here, because if these agrregate models didn't work, then the computer that you are using to read these works also wouldn't work. That's a pretty solid argument for the usefulness of these types of models.
Brining this back to weather and climate, the weather researchers call 'weather' individual and specific data points, like cloud cover, rainfall on a day, and so on. 'Climate' is things like total rainfall per year, average temperature in a month - much broader, less specific information.
Under the DMCA, specifically the section 512(d), sets out the criteria under which the 'search engine ' examption applies. The following key points are worthy of note:
Section 512, paragraph (d),
A service provider shall not be liable... if the service provider:
part (1)(A) does not have actual knowledge that the material or activity is infringing;
(B) in the absence of such actual knowledge, is not aware of facts or circumstances from which infringing activity is apparent; or
(C) upon obtaining such knowledge or awareness, acts expeditiously to remove, or disable access to, the material;
Thus, this can only apply if the site owners are never aware that the material they are indexing is infringing.
A simple look at the front page of Suprnova.org is enough to belie that.
If a site wished to claim 512(d) as a defense, they would have to demonstrate to the court that they did not know any of the material they indexed was infringing.
Now, there might be a defense, under the multiple layers of abstraction, in that Suprnova indexed.torrents, which were merely pointers to the infringing data. That's nothing like a 'I'm just a search engine like Google' defense, however.
Simple rule of thumb: If it's common knowledge that a site is were to look to find infringing materials, and is of little other use, 512(d) won't apply (on the grounds that it beggers belief that a site owner would have no grasp on _why_ so many people were using thier site).
Disclaimer: You're not paying for this, this is not legal advice. If you want legal advice, contact a lawyer in your juristriction.
Maya personal lerning edition is free (as in beer). It looses the plugin capabilities that made Maya an industry standard, and watermarks images, but in terms of seeing if you can pump out useful work with it, that's not an issue (same interface, and most of the same capabilities as full grown Maya).
I seriously expect that the submitter is talking about Maya PLE, rather than any of the proper versions of Maya in the byline, for more or less the same reasons as the parent - it's too much money otherwise.
Photoshop is prehaps not too surprising, given that it is often (not completely corretly) considerd _the_ 2D raster packege [0].
Lightwave is still somewhat anomolus, however.
[0] Photo's and photorealistic style images it's great for. Icon design, other, simpler packages might be better.
For my apps, I do iterative matrix calculations. However, one of the required data tables scales as n^2.3 (ish) of the system size. These can be precalculated, or calculated on demand. Typical size for a small run is 4-6 GB. I've filled a 40 GB array with data tables before.
Thus, the part that impacts runtimes the most is either the on disc lookup, which is still faster than direct calculation, which we've also had to do.
I looked into FPGA's a while back. Some back of envelope calculations show that a single FPGA should be able to calculated the data table on demand, and it'll be faster than reading from disc.
(Turns out, that to actually get a usable solution for a basic PC would need to hack up the whole tool chain. FPGA cards for a PC are all designed for DSP, rather than numerics).
So, with an FPGA and a CPU, I could elminated the slowest part of the job, and scale up to, what, a 1GB working matrix, which is about 8 time larger than the biggest job I've ever run, which hogged a T3E1200 for 6 hours.
So, in short, gimme an FPGA and some reasonable tool chain, and I will be able to about half runtimes, and, more importantly, scale up to 10 times larger calculations. 5 time larger calculations is the most I've ever been asked about.
I read that as the submitter knew that the web page was not time sensitive (i.e. it will be as interesting to see for the first time next week as it is to see for the first time today).
Therefore, it is a good one for the editors to hold in reserve, for when there are few topical stories, rather than have either few stories or some naff ones.
It appears that the editors chose not to follow the advice, (as is thier want)
Slashdot Mirror
So, what you do on your server (and it has to be your server, in order to be able to tweak the options like you want), you can do this. But it won't affect anyone else.
encryption: HTTPS
.NET web services are about 2 or 3 times faster than Axis, from our benchmarks (which did use stateful web services via WSRF, but I don't believe that distorts the timings apprechiably.) GSOAP is about 5 times faster.
authentication: HTTP Basic over HTTPS, or certificate based authentication over HTTPS
transaction management: WS-Coorination.
I mean, you can use WS-Security; WS-SecureConversation and all that XMLSecurity jazz, but frankly, why bother when HTTPS just plain woks? (You probably have to give up on the 'firewall friendly' approach of everything over port 80, but that is a significant step forward in my book.)
naming: I'll give you that. UDDI feels overengineered for what it's normally used for. On the other hand, why are you looking for a public UDDI registry? The Registry is essentially the single point of contact for a particular application; thus you normally would want to keep some level of control over it. On the other hand, for public acces web serivces, have a look at Xmethods (which does offer a UDDI query interface).
Oh, and I disagree that Axis is any good at all, especially not in performance terms. In fact, Axis 1 is the second slowest (and second worst) way of using SOAP (Axis 2 is the only thing worse). If you want something fast, try GSOAP and C++. (To elaborate: every call made with Axis is essentially a dynamic call, the 'compilation' just writes code to change the defaults. This is a very poor design if you want performance, as you can optimise a SOAP engine a lot if you know the schema at compile time - and I'argue that's the most common use case.
Web serivces have the potential to be approximately the same speed as CORBA, if they're not, look at your middleware.
Java RMI can always be faster, because it knows that the classes is needs are already on both sides of the wire or that it can get the actual class directly. That's not possible in a language independant system, where instead you have to give a description of the objects. Also, RMI can pass richer objects than SOAP can, (SOAP is can't pass objects with methods, just data holders). That allows for better architectures to be generated, also improving speed.
No, but I'll wager that you often encase yourself in a cage with a 'heat-generating gasoline-powered device', and strap yourself to it.
... I'd actually agree with you about phones. (Personally, I don't have one, but I agree 4 days on a charge is fine.) I want a fuel cell for my laptop though - that's where the sweet spot is - cheap, easily refueled, long run times. For people who're often away from a wall socket, being able to take 4 days of laptop run time with you easily and cheaply is a very nice feature.
By the way, you are aware that lithium batteries are toxic, explosive, flammable, and generate lots of heat, aren't you?
My point is that the relative risk of a well designed methanol fuel cell is no greater than the current technology risks that most people consider acceptable. It just because it's unfamiliar that the risk is perceived as greater (a well understood phenomenon about people and risk assessment, by the way.)
Although
You are conflating 'energy density of a compound' and 'energy density of a compound that we can extract as electricity in a controlled fashion'.
Indeed, there exists more energy dense compounds that are currently used in batteries. But getting the energy out is tricky. Never mind future batteries - you know that about current lithium polymer batteries loose about 3% of stored energy on 'self protection circuits' - i.e. not bursting into flames at awkward moments...
And, for a true comparison, you're not looking at batteries, but at rechargeable batteries. Rechargeable batteries have poorer energy density that primary cells - you're effectively giving up some storage for the ability to recharge it. Things that store lots of energy in bonds are very difficult to do reverse reactions with. In particular, you need a molecule where the 'charging' reaction doesn't go anywhere near a spontaneous decomposition route. Given how messy electrochemical reactions get after a few charging cycles, this gets tricky.
To be fair, I'm not an expert in batteries (I'm materials, and stuff I was looking was relevant to batteries, but that's a separate thing), so I'm always a little behind, and this may have changed. I'd love for there to be a factor of 2 improvement in rechargeable batteries; but I'm not expecting it.
(Aside: I should point out that the 5-10% was an improvement in state of the art batteries, which lead current commercial batteries by some amount (probably another 5-10%, but that's a guess). So there's a bit to go there too.)
in the toxicity stakes.
That is, the petrol (gasoline, for the North Americans) is, to a first approximation, just as toxic as methanol. When was the last time you heard of someone suffering from petrol poisoning, in any non-trivial (meaning, fixed with 5 minutes of fresh air) manner?
The reason methanol seems more dangerous is that if you contaminate beverages with it, you don't notice it's there until you've consumes a lot. Pure methanol doesn't have that problem. (On the downside, it is absorbed through the skin, so that's not good. Still, when was the last time you got petrol on your hands, in other than a trivial fashion?).
In summary, yes, it's unpleasant. But, in the opinion of this chemist, no more unpleasant that a large number of other substances that we manage to handle quite safely. Just don't drink it.
On battery density - forget it. Battery energy density is on a negative exponential decay - there's just a limit to how much energy you can have in there, and we're at something like 85% of that, IIRC. Power density is improving, but it's better life that you really want, which is energy density. Everyone I know that does reaserch into batteries (that's about 30 people over 7 labs) basically thinks that batteries are more or less as good as they get - there's maybe another 5-10% improvement in energy density, but that's about it.
RFC3675: .sex Considered Dangerous
.xxx == .sex; within the meaning of the RFC.
.xxx domain at a host that has porn on it. This need not be an intentional 'Joe job', but can be perfectly legitimate.
And, of course,
I wish more people were aware of this RFC - it seems to have fallen under the radar for the current spate of domain name based porn separation politics, which is a shame.
The short version is that it's unenforcable: domain names are _not_ cannonical names for internet activities, therefore, it's trivial to have multiple names for a host. Therefore you have to work out what to do when someone points a non
This is all totally seperate from the whole debate over what is and isn't 'pornography' - that is not decidable outside a handful of special cases.
The reason fuel cells are much hyped, and preferred over batteries is that they use liquids to produce the electricity. This means that the size of the reaction interface is decoupled from the energy storage medium (whereas in a battery, they are intimately linked [normally]).
So, the size of the reaction interface determines the power that you can get out of the fuel cell, and the size of the energy reservoir determines how long it will last.
A laptop draws, what, 100 watts peak? A car with an 80 hp engine is at 60 kW - 600 times more. A fuel cell big enough to power that would be prohibitive in cost. Not to mention, the fuel cell will degrade with time - impurities in the fuel, and (if it's a polymer cell), degradation in the polymer itself.
Next point is the fuel medium. The energy density of methanol is less than gasoline, at about 22MJ/kg vs 45MJ/kg for gasoline. So, assuming comparable fuel efficency with the internal combustion + mechanical drive vs fuel cell + motors, you'd need twice as much fuel.
There are no good fuel cells that operate on gasoline - the more complex the hydrocarbon, the harder it is to build a fuel cell. Couple that with the way the sulpher tends to kill fuel cells, and it's not feasable (low sulpher gasoline is available - have you ever seen guarenteed no sulpher gasoline?)
So, it would cost more, and you'd only get half the distance on a single tank of methanol. Assuming that you can get the methanol. The whole fuel distribution problem is a seperate case.
All the numbers here are conservative - I'm sure my powerbook draws significantly less than 100W, 80 hp is at the low end for a car - I believe 100hp is more typical. The laptop fuel cells don't use pure methanol, it's methanol and water, further reducing the energy density.
There's a 40MW storage plant down in England somewhere. Unfortunalty, I can't did out any links to a page about the plant. It was Regenesys energy storge was bought out by VRB recently, a bromine / sodium bromide plant.
n t2.shtml
It's basically a giant battery, with liquid electrolytes. This means that the maximum power is determined by the size of the electrode (a conductive plastic in this case, IIRC), and the maximum storage is determined by the size of the liquid storage tanks (about 200 hours at 40 MW IIRC, or maybe 200MWh).
The cute thing about it is that it scale well - want more power, add another section of electrodes; want more energy storage, add more tanks - modulo the usual engineering problems.
It looks like the only major problem is that no one wants it. http://www.mensetmanus.net/windpower/no-green-gia
And a fair degree of NIMBY to boot.
I strongly suspect that it is not possible to craft a virus [0] so that it's indistinguishable from a piece of commercial software - unless it it's functionally identical (in which case ... the point is moot).
The core argument is that a virus scanner that uses signature matching can match on any part of the virus. It is therefore insufficient to have only part of the virus matching code from some false positive source - all subsequences of the virus must make a false positive in some other known good software. If there is one subsequence (which need not have a unity nor regular step) that is unique to the virus, then that is sufficient to detect it unambiguously.
Given that (for the code segments), the sequence of bytes of the code corresponds with a behavior [1], or partial definition of a behaviour, to have all subsequences match with some other known good software, then all behaviours the virus embodies must match with behaviours present in known good software. Whilst there is the possibility of code in the virus to match with data in some other known good software, I think that the chances of a suitable match are so small as to be unsuitable for use as part of a deliberate strategy [2].
[0] or trojan, worm, spyware or other malware - I shall use just the term virus for simplicity here.
[1] This is less true on architectures with variable length instructions, where by changing the start of a subsequence can totally alter the behaviour it represents.
[2] Unless the malware code is deliberately inserted into the data sections of the known good software. This is almost tautologically impossible.
Trademark is specific to a specific 'trade'. So, actually, I _could_ make a move called 'Revenge of BitTorrent', and that would be fine [0]. I just couldn't make a swarmcast filetransfer application and call _that_ BitTorrent (Or, possible any file transfer application - the edges of a given 'trade' are, as always, a little grey).
Thus, I could quite happily sell a hot beverage called Ford, in a cup of a style that I trademark Mercedes, with a Porchse stirring rod, and there's nothing the car companies can do (unless they have a product within the relevent trade spaces).
Classic example: Apple computer and Apple records.
[0] Well, no trademark infringement. The movie would suck, 'cos I'm real bad at making movies.
Someone is way ahead of you!
True. However, that's not the problem. It dosen't really matter how hard it is to copy a film, it's currently happening.
At the moment, with film, it's not economic to roll out a film everywhere at once. Therefore there is a time lag between the first showings, and when it's available to view locally. This time lag is where the pirates are operating. If you can remove this lag, then one of the benefits of pirated films (faster access) is removed. Digital projectors bring the benefits of digital copying to the movie producers, as opposed to currently, where only the pirates are reaping the benefits.
As I understand it then, Bollywood is trying to defeat piracy by starving the pirates of a market.
RFC 3675 ".sex Considered Dangerous"
.sex (or .xxx) TLD is a bad idea.
There's a long discussion of why, exactly,
It turns out that the better question to ask is: Why is (opaque substance X) not transaprent?
This is because the 'natural motion' (whatever that may mean) of a beam of light it to pass right through somthing, unless stopped.
Once you answer the question of opacity in general, then the reason that glass is transparent [0] is answered: by the absence of anything to make it opaque.
There are, from memory, two major causes of opacity.
Every surface will scatter some light. Indeed, you can see a reflection in a window, even for a material that is accepted 'transparent'. This is the reason that snow quartz is white and opaque, and rock crystal is clear, despite being exactly identical [1] in chemical composition. Snow quartz is make up of very many small grains, and at the boundary between these grains, a small part of the light is scattered. This mounts up through the thickness of the material, and the result is white and opaque. Rock crystal have very large grains - indeed, it's possible to get lumps that are single crystal as large as several feet across. In practice, one or two grain boundaries can't be seen by the naked eye.
You can also get quartz (same chemical composition again [1]) that has 'small ish' grains. A lump about 3 to 4 inches across will be translucent - you can see light through it, vaguely make out dark patches and light patches when you look throuugh it, but no more detail than that. That just happens to have a grain boundary density somewhere in the middle, to produce this effect.
Glass, as in window glass, is made in such a way that there are no grain boundaries in it. It's actually totally different to the crystaline substances I mentioned above, but the principles of transparency are the same. Glass is an amorphous solid, sometimes described as a 'supercooled liquid'. Indeed, the very conept of grain boundaries can only be found in substances with long range order - i.e crystals, so you'd never get opacity produced in a liquid or a glass from this origin.
Other than grain boundaries, the other major cause of internal changes of surface is a mixture of a solid and something else. This can be two solids (fine dust inside a glass will make it look opaque), a liquid or a gas (the white effect on ice cubes is air that was dissolved in the water, but can't disolve in ice. This forms tiny [and not so tiny] bubbles inside the ice, giving the white bands common to homemade ice cubes.)
So that's one way something can be opaque. Onto an other, and to being, let's also consider colour.
Specifically, lets think about ruby (which is red), and sapphire (which is any colour but red, lets think blue, and clear). Both are mostly the same material, aluminium oxide (Al203), which is clear in a pure, single crystal. Gem quality ruby and sapphire are single crystals, so there are no internal surfaces to scatter light. You can see clearly through such gems, but the light that gets through them is coloured by the material.
In ruby, there is a small quantity of chromium ions present distributed through the structure. These chromium ions absorb light in the visible spectrum (which then gets reemmited in a random direction, somtimes as the same colour, more often as light of longer wavelength [some sort of infra red typically]). The titanium and iron in a blue sapphire do the same sort of thing [2], but the light absorbed results in a different colour.
As I've implied, the exact wavelengths of light absorbed are determined by the chemical make up of the substance. All substances have paricular wavelengths of light that they will absorb - it is only where a substance absorbes strongly in the visible region of light that colour arises. Most materials absorb in the infrared and ultraviolet, depending on what process occurs when it absorbs light.
There are a few more, more obscure, methods of generating colour - if the particle size of a dust is similar to the wavelength of light, then it'll show a colour,
Not normally, no, in general.
You can find some situations where there is a difference in the energy between the two states. The most common one is the application of a magnetic field - then, the spin state that is most aligned to the field is favoured over the other one.
The other major case is in chemcial species that have partially filled orbitals. Most of these tend to have a net magnetic moment anyway, but are much more complex, and less generally applicable.
Given the presence of a magnetic field merely changes the potential landscape, no work is going to be done.
By analogy - if you want all the cars on a road to be on the left hand side - block the right hand side of the road off. Once the block is in place, no other work need be done to ensure that all the cars are on the left. (That's a sucky analogy, but it's the best I can think of).
.. it's with the people who own and run the site the ad's are on.
I'm not convinced by your arguments, although I do note that most of the sub-points are valid. Specifically, I reject your conclusion.
If Linus did Linux the *BSD way, a few things would have to change.
Firstly, and foremostly, he would have to develop, and guide, the userland as well. That is part of the reason for the apparent stability of BSD interfaces - for some kernel->userland interfaces the implemetnation is hidden (for example, things that are used only by libc). Whether this is a good or bad thing on the partof the BSD's is irrelevent, it is a fundementaly different approach.
Currently, Linux provides a set of kernel level interfaces, and the GNU libc utiliese some of these to provide the standard C library. Some of the kernel interfaces are standard, (POSIX file stuff, sockets etc), some are not (Firewall, some threading interfaces etc).
Most fundementally, the reason I reject your conclusion can be best expressed as a question: "If the linux process is so poor, why is it more popular than *BSD?"
One can discuss that question ad nauseum, but I suspect that part of the reason is that it is _not_ tightly controlled. If you have a method for making some part better, the Linux apprach says: show me the code, convince us it's better. The *BSD approach says: Show me the code, convince us it's better, get somone on the core team to sponser it, shedule it for the next (or prehaps one after next) release, and wait.
Thus, Linux has a lot more mobility, and can utilise new approaches sooner than *BSD - for good or ill [0].
My personal thoughts is: Linux is not broken. The development model works as well now as it used to, thus there is no need to change. Let the two approaches co-exists, let people use whichever they feel like. If that means that Linux becomes a testbed for ideas, and *BSD cherry pick, then so be it, that's fine. If that means that Linux evolves and *BSD stagnates, so be it, that's fine. If that means that Linux is unstable and *BSD is stable, so be it, that's fine. In practice, the last two will be indistinguishable for a long time after one of them occurs.
Let them be different - choose your favourite model, and be happy with it. But if the other one results in something you prefer, consider that both are trade-offs, and neither is perfect.
[0] This can bring problems. The various VM saga's are prehaps a canonnical example here.
I don't belive that the claim is that thier new batteries have three times the capacity of a current Li-ion battery. They are claiming three times the power, which I read as meaning that the peak discharge power is three times greater.
This is a lot more reasonable, from my understanding of Li-ion batteries. The theoretical energy capacity isn't three times current batteries, IIRC, so trippling that is unreasonable. But three times the discharge rate is not impossible, and brings them into the range of NiMH batteries, maybe even Lead-Acid. Coupled with the superior energy density of Li-ion, that's very very nice.
This matches well with the claim of faster charging - the limiting factors for charging and dischargeing are related in batteries.
So, your sums become 4Ah in 5 minutes, or a much more reasonable 48 amps. A lot, yes, but not beyond what's currently done with medium current applications.
Reading the press relase as I did above imedialty makes is much more reasonable, although I'd love to get more details. There's a lot hingeing on the word 'power', depending whether you read it in a technical or common definition, so much so that I wouldn't want to depend on it.
Roughly speaking, you don't use acid because you would need too much of it, and it sucks at cutting, and at giving neat edges. Oh, and resists are difficult, and it's slow.
Resists: You need something that is resistant to the acid, but can be applied neatly, and removed neatly afterwords. It needs to adhere well to the metal surface, yet be resistant to the acid and to water, and any by-product produced. Also, it needs to be resistant to exfoliation - as you start to etch, it's no good if your resist falls off around the cut. Oh, and it needs to be cheap and easily available.
Rates: Acid is slow. Or, rather, acid's that you would want to use for this purpose are slow. Anything that can eat through steel or aluminum at a decent rate is not something you want to handle. (Consider: What do you store it in, and what do you do the reaction in? Both are doable - but not strightforward). So you're left with acids that don't eat the metal very fast.
Edges: With an electrical current, you can ensure that the direction of cutting is more or less perpindicular to the surface of the metal (that's why it's two large plates, for example). With an acid, that's not the case. They will tend to etch out round indentations under the edges of the resist - giving you razor sharp edges to your cut out. Which would need filed down afterwords, and means there is a minium thickess of cut, proprtional to the thickness of the sheet.
My back of envelope sums suggest that the miniumum width of cut by acid etch is roughly equal to the thickness of the material, assuming an infitessimally small start. For 1.2 mm sheet metal, that's a 1.2 mm width - easily doable with a Dremel.
It would also take around 3-4 months, I think.
Acids are good at etching a surface layer. I would use an acid if I wanted a matt surface - for example, to etch details onto sheet metal. A combination of cut outs and etching would work very well in giving a unique appearence to a panel.
To back up the parent poster, consider the following:
We are unable to predict the electron density at a specific point in a a metal wire, at a given time.
Yet, we _are_ able to predict the total behaviour of electricty in a wire. Given that electricity is motion of electrons, how does this arise?
Well, this is a common situation, where models of behaviour at different scales are related only through a very small number of parameters.
For example, we can predict the magnetic behaviour of a system from just two parameters (for an binary antiferromagnet), yet to calculate the behaviour of the electrons (which cause said magnetism) takes of the order of 100 or so (and about 15 orders of magnitude longer).
So for practical calculations on magnatic things, you don't need to do the quantum mechanical calculations, just the much simpler ones.
Sure, technically these are inaccurate. In my experience, we're off by 0.001%, and by about 3-5% in the second derivative. That's so accurate, that there are very many additional cases where the calculations show two possible results, and the experiments arn't accurate enough to tell these apart. Or, in plain terms, good enough.
I use magnetism and electricity as examples here, because if these agrregate models didn't work, then the computer that you are using to read these works also wouldn't work. That's a pretty solid argument for the usefulness of these types of models.
Brining this back to weather and climate, the weather researchers call 'weather' individual and specific data points, like cloud cover, rainfall on a day, and so on. 'Climate' is things like total rainfall per year, average temperature in a month - much broader, less specific information.
Under the DMCA, specifically the section 512(d), sets out the criteria under which the 'search engine ' examption applies. The following key points are worthy of note:
Thus, this can only apply if the site owners are never aware that the material they are indexing is infringing.
A simple look at the front page of Suprnova.org is enough to belie that.
If a site wished to claim 512(d) as a defense, they would have to demonstrate to the court that they did not know any of the material they indexed was infringing.
Now, there might be a defense, under the multiple layers of abstraction, in that Suprnova indexed
Simple rule of thumb: If it's common knowledge that a site is were to look to find infringing materials, and is of little other use, 512(d) won't apply (on the grounds that it beggers belief that a site owner would have no grasp on _why_ so many people were using thier site).
Disclaimer: You're not paying for this, this is not legal advice. If you want legal advice, contact a lawyer in your juristriction.
Maya personal lerning edition is free (as in beer). It looses the plugin capabilities that made Maya an industry standard, and watermarks images, but in terms of seeing if you can pump out useful work with it, that's not an issue (same interface, and most of the same capabilities as full grown Maya).
I seriously expect that the submitter is talking about Maya PLE, rather than any of the proper versions of Maya in the byline, for more or less the same reasons as the parent - it's too much money otherwise.
Photoshop is prehaps not too surprising, given that it is often (not completely corretly) considerd _the_ 2D raster packege [0].
Lightwave is still somewhat anomolus, however.
[0] Photo's and photorealistic style images it's great for. Icon design, other, simpler packages might be better.
package troll.slashdot;
// Retires an obsolete shell script
/* Closes: class Main() */
/* Closes: class OutputRoutine */
/* Closes: class TextGenerator */
import java.io.Writer;
import java.io.PrintWriter;
import java.io.IOException;
class Main {
int static main() {
OutputRoutine or = new OutputRoutine(System.out);
TextGenerator tg = new TextGenerator(or);
tg.run();
}
}
class OutputRoutine {
private PrintWriter pw;
OutputRoutine (Writer w) {
this.pw = new PrintWriter(w);
}
void Output (String text)
throws IOException {
pw.println(text);
}
}
class TextGenerator {
OutputRoutine or;
TextGenerator(OutputRoutine or) {
this.or = or;
}
void run() {
or.Output("First post");
}
}
For my apps, I do iterative matrix calculations. However, one of the required data tables scales as n^2.3 (ish) of the system size. These can be precalculated, or calculated on demand. Typical size for a small run is 4-6 GB. I've filled a 40 GB array with data tables before.
Thus, the part that impacts runtimes the most is either the on disc lookup, which is still faster than direct calculation, which we've also had to do.
I looked into FPGA's a while back. Some back of envelope calculations show that a single FPGA should be able to calculated the data table on demand, and it'll be faster than reading from disc.
(Turns out, that to actually get a usable solution for a basic PC would need to hack up the whole tool chain. FPGA cards for a PC are all designed for DSP, rather than numerics).
So, with an FPGA and a CPU, I could elminated the slowest part of the job, and scale up to, what, a 1GB working matrix, which is about 8 time larger than the biggest job I've ever run, which hogged a T3E1200 for 6 hours.
So, in short, gimme an FPGA and some reasonable tool chain, and I will be able to about half runtimes, and, more importantly, scale up to 10 times larger calculations. 5 time larger calculations is the most I've ever been asked about.
Time to brush up on my VHDL, I think.
I read that as the submitter knew that the web page was not time sensitive (i.e. it will be as interesting to see for the first time next week as it is to see for the first time today).
Therefore, it is a good one for the editors to hold in reserve, for when there are few topical stories, rather than have either few stories or some naff ones.
It appears that the editors chose not to follow the advice, (as is thier want)