Naw, the magentic field lines are found by using the "right hand rule" (or the left hand rule if you're an EE guy). So the field lines wrap around the wire.
Right, they "wrap around" the wire. Although the field lines are curling around the wire, they are still always perpendicular to it (dot product of magnetic field and current is always zero). The field lines are tangentially perpendicular, not radial.
But seriously folks, 1800 lbs of thrust just does not seem very manly when compared to the Saturn V F1's 1.5 million lbs of studly thrustosterone. Ugh - more power!
Well, consider that the Saturn V weighed about 6.7 million pounds, and the rocket used five F1 engines providing a total of 7.5 million pounds of thrust, then the net upward force is actually only 800,000 pounds, or 160,000 pounds per F1 engine. So about 9/10ths of the thrust is used just to counteract the weight of the rocket itself (at least on liftoff).
Look at Time magazine from last week (the one with the big "Gulf War II" on the cover). Flip open to somewhere in the middle, where they have a section on various historical events of the 20th century. One of the article sections shows a photograph of a woman sitting in front of a medical tent during the Depression. The woman has her hand near her face, held in a position as if she were holding a cigarette. However, the cigarette is nowhere to be found. It has been removed from the photo.
If you have a copy of the mag sitting around, please look at the photo and tell me if you agree.
I find it sickening that a supposedly respectable publication would edit historical photographs for the sake of modern political correctness. We wouldn't want our young kids learning that, way back during the Depression, people smoked cigarettes, would we?
These weapons have been long under research and development. Interestingly, this paper seems critical of the gasdynamic laser. The paper is nontechnical and relatively brief.
Actually, it's not negligable. I used to ride my bike for a kilometer or two quite often under some 115 kV lines near where I lived. If i didn't ground out my bike, or touch it every 10 seconds, I'd get quite a shock..
I believe this is possible, but this wasn't caused by induction. The induced emf due to the transmission wire's magnetic field will create a current in the bike frame, but this current is just a loop, and can't cause charge to build up on the bike.
What happened to you was an effect of the wire's *electric* field, not its magnetic field. Either the bike frame, or your body, was raised to a very high voltage by the line's electric field, and when you came in contact with the bike frame the charge quickly moved to equalize the difference, i.e., you received a shock. Since your body capacitance is so small you can easily be raised to thousands of volts difference from the surroundings.
In contrast the magnetic effect (induced emf in the bike frame) is on the level of millivolts. So you experienced a different, but related, phenomenon.
If that's the case, AC induces, DC doesn't, then how come AC is used for long distance lines?
You answered your own question. It's precisely *because* AC induces that it's used for transmission. Induction is what makes transformers possible. DC current can't be easily converted from one voltage to another the same way AC can.
The powerlines you see around your neighborhood are 12-20 kV, 50 or 60 Hz. For efficiency reasons, power is transmitted at the highest possible voltage (this reduces resistive loss). The can-shaped transformers (or "pole-pigs" as they are called) you see on top of the power poles convert this high voltage current to 120 V for home use.
DC is used over long distances because it reduces inductive and capacitive loss, but the "transformer" equipment at the lines terminals is much more complex and expensive than simple AC transformers, so AC is the most common transmission method.
Now we know why they run power lines alongside every road -- so they can soak up the free energy caused by cars driving alongside them!
Actually, the magnetic field of the AC line will induce eddy currents in the body of a passing car. These eddy currents produce their own magnetic fields which oppose the field from the wire, and these fields actually reduce the current flowing in the wire (the energy to produce the eddy current has to come from somewhere, that somewhere is the current in the wire).
The effect is tiny, but nearby metal objects actually *reduce* the efficiency of the transmission.
That doesn't matter, because he's moving along parallel to the wire. The magnetic field is perpendicular to both the wire and the direction of travel, so the field strength is independent of the motion. If he were moving obliquely w.r.t. the wire then the field *would* depend on the motion and you would see an emf.
If the lines are AC (which is the usual case except for long distance transmission lines) then you should have an induced emf in the bike frame. The bike frame forms a conducting loop, and as the AC current oscillates in the transmission line it creates a magnetic field perpendicular to the wire, which oscillates at the same frequency. As this magnetic field passes through the bike frame loop it will induce an alternating current at the same frequency. Basically your bike frame is acting like a single-turn inductor.
You can increase the induced emf by wrapping multiple turns of insulated magnet wire into a loop in the same orientation as the bike frame. Neglecting the finite resistivity of the wire, you will get twice as much emf every time you double the number of turns. But even with hundreds of turns we're still talking about millivolts or perhaps hundredths of a volt at most.
If the line is DC, then there will be no induced emf since the magnetic field is not changing.
The speed at which you ride the bike has no influence on the induced emf, unless you are travelling near light speed, in which case the apparent frequency of the AC will be reduced since you are "catching up" to the propagating waveform. But I don't think you could pedal that fast:-)
Information theory says that random noise is the most "concentrated" form of information possible. Roughly, information == entropy (actually, entropy times number of symbols).
Random data may not be meaningful but they are full of information by definition.
Consider the sequence 123123123123. The sequence is highly ordered, and therefore is probably meaningful (at least to someone, somewhere), but it contains very little information. In contrast the random sequence 196390244187 is highly disordered, totally meaningless, yet contains more information than the 123123123123 sequence.
The technical definition of "information" is counterintuitive, not as simple as "noise vs. signal."
In the most general form possible: life decreases physical entropy, which leads to ordered images, which means a decrease in informational entropy. Therefore, life processes produce images with less information than nonbiologically produced images. Less information takes less space, so the biological images should compress better. This is all in the abstract; in reality your results will depend on what algorithms you use.
Someone pointed out that using JPEGs as source images is tainting the results. That's definitely true, but the basic concept here is valid. Anyone who's studied both physical entropy and information theory can understand that the two are highly related. I'd like to see them do this study again with the *original* images -- I suspect the result will still come out. I'm not sure gzip is entirely the most appropriate algorithm to use here, but it could work.
Well, another solution would be to not even send the models if the code determines they aren't going to be visible. That way no amount of tweaking of OpenGL settings can ever make an invisible object visible.
Ironically, the reason this isn't done is that it's *far* faster to just send everything to the video card and let it sort out what is visible and what isn't. Letting the CPU perform visibility calculations would slow rendering down unacceptably.
It's amazing that video cards are *that much* faster than the CPU, that it's actually more efficient to send them a bunch of polygons that will never even be drawn!
This won't work with already compressed images unless it reduces the quality or resolution.
What if they have a better compression algorithm that makes the image smaller while retaining quality? JPEG is widespread and standardized but it is not "king" in terms of modern image compression performance. They probably have a transcoder which translates between JPEG and whatever their proprietary format is, with as little degradation as possible. Even a 5-10% savings would make a difference.
Leaving the TCP/IP connect unclosed violates standard practices and will only improve web speed if the server is running IIS since it expects IE to do this same trick.
I think what they probably mean by this is a persistent connection is maintained between the client and the transparent proxy, *not* between the proxy and the external server. Notice they said "optimize the communication between your modem and our network of servers." This is actually a really good idea since it avoids the overhead of building up and tearing down a TCP connection to the proxy for each web request. The external web server has no idea this is going on; it's something happening between the Propel office and the home user.
so apps only get 2GB, and that's shared across all the apps.
I'm having a hard time believing this. I know there is a 2G limit in user-space, but it needs to be *shared* by all the apps? There's no hardware or software reason why it has to be that way.
You are probably better off disassembling the CRTs and selling the individual parts. The flyback transformers in particular are sought after by hobbyists.
Of course, disassembling a CRT is just as dangerous as a television. There are capacitors charged to many kilovolts, which maintain this charge long after being turned off. You can easily be killed working inside a CRT. But if you know how to safely take it apart you might be able to make a few bucks selling the pieces.
By this argument, anything above machine code is simply a crutch, because programming "discipline" could also achieve the same result.
Yes, I also said there is nothing inherently bad about a crutch as long as you apply it where appropriate and not when it isn't the right solution. I do view HLLs as a crutch, and yes I've programmed in assembler before. HLLs are a crutch I'm grateful to have.
Read your own quotation again. By writing only C, your mindset has become limited to believing that C and discipline are adequate for any programming paradigm. This is simply not the case.
First off, I think I misphrased that slightly. What I meant is that we have products which are 99.9% C code. We also have other products in other languages, as the situation warrants. We use C++ when we should, and PHP when we should, etc.
But the claim that C somehow can't accomplish everything is kind of silly. It may not always be the best choice (although it often is) but it is never impotent. If you could come up with a problem that is *impossible* to solve in C I would be very interested to hear about it.
Templates are a crutch. So are overloaded operators, overloaded functions, public vs. private data, etc. A crutch is simply something which makes it easier to accomplish a goal. A crutch, by itself, is not a bad thing.
However, it's nearly always fatal to mistake a tool (in this case, templates) for an end in itself (a functioning, maintainable codebase). No programming technology, be it HLL in general, objects, inheritance, or even templates will replace the need to think intelligently and make sound engineering decisions. You cannot build a skyscraper without the proper knowledge, no matter how excellent your hammer is.
The company I work for is among the few remaining who produce large-scale Windows products written entirely (ok, 99.9%) in C. My work is in a totally different world than the object oriented people, yet I still manage to accomplish everything an OO programmer could do. The secret here is not cute little language features, but discipline and correct design.
IMHO, templates do not deserve a book quite this large. Clearly, the author has had enormous experience in various situations, and knows how to solve all kinds of problems with templates, BUT -- remember the famous words passed down from people wiser than ourselves: "When all you have is a hammer, everything starts to look like a nail." Make sure the hammer isn't the only thing in your toolbox.
Alas it's a homebrew deal. I'm running syslog-ng which logs iptables firewall events to both a flat file and a FIFO. Sitting on the other side of the FIFO is a perl script which translates each log event into a SQL insert statement and pipes these statements into MySQL.
It took only a few hours to set up and ensure everything was working right. I highly recommend that you use syslog-ng so that you can direct the logs to both a FIFO *and* a plain file. That way if the DB goes down it continues logging, and I can come back later and reinsert the missing entries...
I get hundreds of scans per day. I don't "take offense" at this or get my panties crunched over it. In fact, it's interesting to see what the latest "craze" is -- some weeks, the LPD port is really popular, other times it's port 1433 (sql slammer). A lot of the time I'm aware of a new vulnerability even before it's widely known, because I start seeing people hitting those ports.
All my firewall events go into a DB, which I query daily. I have a set of reports showing things like average scans per second per host, most popular ports, most popular times of day, etc. If I see something incredibly suspicious I suppose I would try to investigate further -- but most of the time I just have a good time watching people bounce off my firewall.
If you don't want people sending packets to various ports on your box, perhaps you should disconnect it from the Internet.
Slashdot Mirror
Right, they "wrap around" the wire. Although the field lines are curling around the wire, they are still always perpendicular to it (dot product of magnetic field and current is always zero). The field lines are tangentially perpendicular, not radial.
Well, consider that the Saturn V weighed about 6.7 million pounds, and the rocket used five F1 engines providing a total of 7.5 million pounds of thrust, then the net upward force is actually only 800,000 pounds, or 160,000 pounds per F1 engine. So about 9/10ths of the thrust is used just to counteract the weight of the rocket itself (at least on liftoff).
If you have a copy of the mag sitting around, please look at the photo and tell me if you agree.
I find it sickening that a supposedly respectable publication would edit historical photographs for the sake of modern political correctness. We wouldn't want our young kids learning that, way back during the Depression, people smoked cigarettes, would we?
Lasers And Their Potential For Tactical Military Use
These weapons have been long under research and development. Interestingly, this paper seems critical of the gasdynamic laser. The paper is nontechnical and relatively brief.
I believe this is possible, but this wasn't caused by induction. The induced emf due to the transmission wire's magnetic field will create a current in the bike frame, but this current is just a loop, and can't cause charge to build up on the bike.
What happened to you was an effect of the wire's *electric* field, not its magnetic field. Either the bike frame, or your body, was raised to a very high voltage by the line's electric field, and when you came in contact with the bike frame the charge quickly moved to equalize the difference, i.e., you received a shock. Since your body capacitance is so small you can easily be raised to thousands of volts difference from the surroundings.
In contrast the magnetic effect (induced emf in the bike frame) is on the level of millivolts. So you experienced a different, but related, phenomenon.
You answered your own question. It's precisely *because* AC induces that it's used for transmission. Induction is what makes transformers possible. DC current can't be easily converted from one voltage to another the same way AC can.
The powerlines you see around your neighborhood are 12-20 kV, 50 or 60 Hz. For efficiency reasons, power is transmitted at the highest possible voltage (this reduces resistive loss). The can-shaped transformers (or "pole-pigs" as they are called) you see on top of the power poles convert this high voltage current to 120 V for home use.
DC is used over long distances because it reduces inductive and capacitive loss, but the "transformer" equipment at the lines terminals is much more complex and expensive than simple AC transformers, so AC is the most common transmission method.
Actually, the magnetic field of the AC line will induce eddy currents in the body of a passing car. These eddy currents produce their own magnetic fields which oppose the field from the wire, and these fields actually reduce the current flowing in the wire (the energy to produce the eddy current has to come from somewhere, that somewhere is the current in the wire).
The effect is tiny, but nearby metal objects actually *reduce* the efficiency of the transmission.
That doesn't matter, because he's moving along parallel to the wire. The magnetic field is perpendicular to both the wire and the direction of travel, so the field strength is independent of the motion. If he were moving obliquely w.r.t. the wire then the field *would* depend on the motion and you would see an emf.
You can increase the induced emf by wrapping multiple turns of insulated magnet wire into a loop in the same orientation as the bike frame. Neglecting the finite resistivity of the wire, you will get twice as much emf every time you double the number of turns. But even with hundreds of turns we're still talking about millivolts or perhaps hundredths of a volt at most.
If the line is DC, then there will be no induced emf since the magnetic field is not changing.
The speed at which you ride the bike has no influence on the induced emf, unless you are travelling near light speed, in which case the apparent frequency of the AC will be reduced since you are "catching up" to the propagating waveform. But I don't think you could pedal that fast :-)
Random data may not be meaningful but they are full of information by definition.
Consider the sequence 123123123123. The sequence is highly ordered, and therefore is probably meaningful (at least to someone, somewhere), but it contains very little information. In contrast the random sequence 196390244187 is highly disordered, totally meaningless, yet contains more information than the 123123123123 sequence.
The technical definition of "information" is counterintuitive, not as simple as "noise vs. signal."
Someone pointed out that using JPEGs as source images is tainting the results. That's definitely true, but the basic concept here is valid. Anyone who's studied both physical entropy and information theory can understand that the two are highly related. I'd like to see them do this study again with the *original* images -- I suspect the result will still come out. I'm not sure gzip is entirely the most appropriate algorithm to use here, but it could work.
Very cool...
Ironically, the reason this isn't done is that it's *far* faster to just send everything to the video card and let it sort out what is visible and what isn't. Letting the CPU perform visibility calculations would slow rendering down unacceptably.
It's amazing that video cards are *that much* faster than the CPU, that it's actually more efficient to send them a bunch of polygons that will never even be drawn!
True, but they could also be using a hardware device to do it (transcoder card? sounds cool to me!)
What if they have a better compression algorithm that makes the image smaller while retaining quality? JPEG is widespread and standardized but it is not "king" in terms of modern image compression performance. They probably have a transcoder which translates between JPEG and whatever their proprietary format is, with as little degradation as possible. Even a 5-10% savings would make a difference.
Leaving the TCP/IP connect unclosed violates standard practices and will only improve web speed if the server is running IIS since it expects IE to do this same trick.
I think what they probably mean by this is a persistent connection is maintained between the client and the transparent proxy, *not* between the proxy and the external server. Notice they said "optimize the communication between your modem and our network of servers." This is actually a really good idea since it avoids the overhead of building up and tearing down a TCP connection to the proxy for each web request. The external web server has no idea this is going on; it's something happening between the Propel office and the home user.
I'm proud to have this man as my senator.
For a sec I read that as "now powered by WMD." It is a giant thermonuclear reactor, after all. ;-)
I'm having a hard time believing this. I know there is a 2G limit in user-space, but it needs to be *shared* by all the apps? There's no hardware or software reason why it has to be that way.
Is Microsoft really *monumentally* stupid?
Of course, disassembling a CRT is just as dangerous as a television. There are capacitors charged to many kilovolts, which maintain this charge long after being turned off. You can easily be killed working inside a CRT. But if you know how to safely take it apart you might be able to make a few bucks selling the pieces.
Yes, I also said there is nothing inherently bad about a crutch as long as you apply it where appropriate and not when it isn't the right solution. I do view HLLs as a crutch, and yes I've programmed in assembler before. HLLs are a crutch I'm grateful to have.
Read your own quotation again. By writing only C, your mindset has become limited to believing that C and discipline are adequate for any programming paradigm. This is simply not the case.
First off, I think I misphrased that slightly. What I meant is that we have products which are 99.9% C code. We also have other products in other languages, as the situation warrants. We use C++ when we should, and PHP when we should, etc.
But the claim that C somehow can't accomplish everything is kind of silly. It may not always be the best choice (although it often is) but it is never impotent. If you could come up with a problem that is *impossible* to solve in C I would be very interested to hear about it.
However, it's nearly always fatal to mistake a tool (in this case, templates) for an end in itself (a functioning, maintainable codebase). No programming technology, be it HLL in general, objects, inheritance, or even templates will replace the need to think intelligently and make sound engineering decisions. You cannot build a skyscraper without the proper knowledge, no matter how excellent your hammer is.
The company I work for is among the few remaining who produce large-scale Windows products written entirely (ok, 99.9%) in C. My work is in a totally different world than the object oriented people, yet I still manage to accomplish everything an OO programmer could do. The secret here is not cute little language features, but discipline and correct design.
IMHO, templates do not deserve a book quite this large. Clearly, the author has had enormous experience in various situations, and knows how to solve all kinds of problems with templates, BUT -- remember the famous words passed down from people wiser than ourselves: "When all you have is a hammer, everything starts to look like a nail." Make sure the hammer isn't the only thing in your toolbox.
It took only a few hours to set up and ensure everything was working right. I highly recommend that you use syslog-ng so that you can direct the logs to both a FIFO *and* a plain file. That way if the DB goes down it continues logging, and I can come back later and reinsert the missing entries...
Aren't your tax dollars funding the bombing of Iraq?
All my firewall events go into a DB, which I query daily. I have a set of reports showing things like average scans per second per host, most popular ports, most popular times of day, etc. If I see something incredibly suspicious I suppose I would try to investigate further -- but most of the time I just have a good time watching people bounce off my firewall.
If you don't want people sending packets to various ports on your box, perhaps you should disconnect it from the Internet.
Is there anything for PPC analogous to VMWare which would allow you to run Yellow Dog in MacOS X, or vice versa?
If it was static (in the C sense), an overflow wouldn't smash the stack and there would be no exploit. ;-)