Thank you for the additional detail. I didn't go into how advanced drive circuits can mitigate the otherwise nearly linear drop in torque because the discussion was about MAXIMUM torque, as opposed to "pretty good" torque. At least for the one EV motor I've studied the dyno chart for, the changing drive voltage helps the torque curve to be flattER, but nevertheless max torque is still at stall.
A user in California wants to download a video hosted in Texas. Both the user's ISP and and the hosting company have fiber lines from Texas to California. Whose lines carry the video across the country? Alternatively, maybe only one company has spent billions building a nationwide network. Whichever company carries the bits across the country is the doing most of the work. The other company should either balance that by carrying half of the traffic cross-country on its network, or kick in a few dollars to help cover the cost. That's Level3's new approach, and it makes a lot of sense.
Which DIRECTION the traffic is flowing really doesn't make any difference. The cost is in carrying the traffic, so Cogent should expect settlement-free peering if and only if they invest in a network that carries their share of the traffic, if the bit-miles are equal.
> That constrains the bandwidth between Cogent and the Tier 1s (which Cogent is definitely not).
Some sources disagree. Who is Cogent buying transit from or paying settlements to? Do you have a source for that?
Of course many people would say that Cogent isn't top quality, but that has little or nothing to do with their tier. Tier 3 ISPs buy transit from tier 2 ISPs. Tier 2s buy transit from tier 1 ISPs. Tier 1 providers buy from nobody. As far as I know, Cogent doesn't buy transit from anyone. (Modulo the same types of location-specific deals ALL tier 1 providers have with each other.)
To see this effect in action in an interesting way, apply power to an electric motor, then remove power and watch it freewheel to a stop. Next, add a diode to the terminals, oriented such that the normal power does not go through the diode. Run it and remove power. You'll notice it no longer freewheels, but stops abruptly. What's happening is that it's working as a generator driving itself in reverse. As long as it's spinning, the voltage it produces goes through the diode and tries to make it go backward. As soon as it stops, no more voltage is generated and it never goes in reverse, but stops dead.
The effect is powerful enough that if you don't hook up power and just short the terminals, it becomes very difficult to turn the motor by hand. The motor is literally fighting against you. This is great for robots and such where you want the motor to turn for a certain time and then stop. Just have your controller short the terminals for "stop".
The exact same effect occurs when the motor is operating normally - any time it spins it produces reverse voltage which results in reverse torque trying hard to stop itself.
I thoroughly disagree. As a UX designer, I consider my design "in need of improvement" if it's designed such that it's easy to make specific, known errors. A few hours ago I was on the phone with a customer who uses my Strongbox software. He was making the same error that many other people make. That many people make the error proves to me that the software doesn't make it sufficiently obvious what the correct action is.
about when you've been in sometime else's car at night. Often you have to hunt for the door lever and especially on older cars you have to figure out if the handle should be rotated upward, pulled out and back, out and forward, etc. Doors on buildings often have instructions posted on them - Push or Pull. Other buildings don't need instructions - the door has a flat metal plate that can only be pushed. It can't be pulled or turned, it's a flat plate. Emergency exits get it right - a wide, flat bar is obviously for pushing. Some doors, like one I sawlast week, get it ENTIRELY wrong - that one had a round knob - which needed to be SLID to the side. Round knobs are for turning! Vertical slits or projections are for sliding to the side. Not surprisingly, I saw two different people struggle with that door until someone helped them.
We talked about the handles inside of cars. Contrast that with the handles on the outside of a car door. That's a good design. Noone will ever need help figuring out how to operate an exterior car door handle because the design is such that the user can only do one thing - insert fingers and pull.
I seek to make my designs be like exterior car handles - intuitively obvious. With the right design, not only do users not make errors, they aren't even distracted by looking at the UX, figuring it out. They just do it automatically, intuitively, like opening the door to get into a car.
Credit to The Design of Everyday Things for the door handle example.
As you may know, if you spin an electric motor by putting a prop on it and letting the wind spin it, you've just made a generator. You may also know that doesn't mean that the spin a motor powers itself, forming a perpetual motion machine. That's because the generated voltage is in the reverse direction from the direction required to make it spin (among other things).
So what happens is that when you apply 12 volts to make a motor turn, that "generator effect" is producing 6 volts the other direction. If you put a multimeter on the motor terminals, it'll read 12V - 6V = 6V. So the spinning motor has 6V at its terminals. If it's not spinning, it doesn't work as a generator, so it has 12V on terminals. Guess which one has more torque, the stalled motor with 12V or the spinning motor with 6V? The motor with the full 12V (because it's not generating -6V) has more torque. Max torque, therefore, is at 0 RPM. Faster spinning means more negative voltage generated and lower torque.
A manufacturer of the control circuit can of course ARTIFICIALLY limit the power to the motor at low RPM. If they set the control circuit to not ALLOW the motor to full torque, the car would see consistent torque. That's not because of the motor, though, that would be an artificial limit configured into the controller.
Sub-cycle length sounds are not a normal case, of course. The denigrate example does, however, clearly illustrate the difference between a continuous tone of infinite length, which can be perfectly modelled, and a changing blend of sounds of finite length, which cannot be. Real-world sounds would consist of many samples, but not infinite, and would be appear nearly continuous for several cycles.
Re the low pass frequency, two samples of a DTMF tone around 20 kHz aren't unique at 44k sample rate either - the DTMF is indistinguishable from a pure sine wave with a small number of samples, I'm pretty sure
Sub-cycle length sounds would, I think, include a balloon pop or similar impulse sound - not the sounds typically heard in music, but certainly real-world audio.
>> If you SSH to a remote host > xforwarding !?!? > local lan only
Yeah, if by "remote" you mean "local", then yes that makes sense.
I have used X forwarding over the internet and for brief periods it IS usable with compression turned on. (Usable in an emergency, or a single brief task etc.) It seems we agree it's not a reasonable workflow for day-to-day text editing.
The only criticism I can think of for vim, and a very significant one, is that there's a very significant learning curve in the beginning. You can learn enough in a couple hours to use it to accomplish whatever you need to do, but then you can spend years learning to tricks to make your work time more productive and more interesting by disposing of the drudgery. Whatever transformation you want done to some text, vim can do it in under a second, but only if you've learned the magic keystrokes.
Now it suddenly makes sense to me, I "get it". Infinite samples of a repeating function will create a unique pattern.
We can trivially understand that it doesn't work for finite recordings by looking at the simplest case of one sample. A sound recording of duration 1/R second will generate one sample. The value of that single sample tells us virtually nothing about the sound.
Since real-life sounds are not infinitely long repetitions, samples of real sounds can be pretty good approximations, only.
Clearly if you know that the original signal is a digital signal, a square wave, 1/2 B is fine - the recording will be forced to a square wave, which happens to be correct.
Similarly, if you know that it's a single, pure sinusoidal tone, at playback you can round off the edges of the squared recording to get the analogous pure sinuousoid.
If it's not a pure tone, I don't see how you could possibly infer the correct waveform from the squared samples, but the theorem seems to say that you can. That seems quite impossible, but maybe it's not.
At playback, capacitance and physical momentum will round off the corners of a square wave pretty much randomly, while filters can guess that it might be a pure, single tone - a sinusoidal wave (or make some other guess). The recording, the digital file IS sample-and-hold. There is one value per sample.
Starting with the set of squared waves in the recording, then guessing which of many sounds is represented by that sample, will produce _A_ sound. Guessing A sound is not reproducing the original sound. Here's a simple way you can prove it to yourself:
Generate a 23kHz tone. Save as a 48k file.
Generate another 23kHz tone and mix it with another 23kHz offset by 1/92k seconds. Save as a 48k file.
Note that you can visually SEE the difference in the two waveforms.
Check the md5 of the two files. Note that the recordings are identical, though you can see that the sounds were not identical. Sense the recordings are bit-for-bit identical, they will of course play back identically. Filters can be used to round off the edges or otherwise modify the sound, but the two identical files will give results, though they are supposed to represent different sounds.
I'm sure you can think of all kinds of theories to argue why you don't think the files will be identical. Or you can just tryit and see that they are in fact identical.
Vim means "vi, improved". Vim is great. Part of why it's great is because vim is a drop-in replacement (upgrade) for vi.
This guy proposes to do the same thing again, another round of improvements. I believe he intends it will still be a drop-in replacement. Nothing will be lost by symlinking "vi" to nvim instead of vim. Everything will still work the same, only faster and more reliably. I see no reason to think it won't be just as smooth as the transition from vi to vim.
You CAN run a GUI app over the internet and slowly, painfully peck out letters with latency reminiscent of a cheap 4800 baud modem because typing each letter requires generating and downloading an image of the application.
Or you can work literally a thousand times faster by editing text in text mode.
I'm shocked that anyone knowledgeable enough to know what X forwarding is could also be clueless enough to suggest it's a good way to edit text.
What are you talking about? A fake OS update? Does that have anything at all to do anything? A fake update wouldn't add any new system capabilities, so apps wouldn't gain any new capabilities.
Did you read the comment you replied to? Or TFA, or anything to get a clue what that topic is?
That may be the most incorrect xkcd. Self-explanatory tools (knowledge in the world) is great for a newbie doing a one-time task. Four minutes hunting through menus is better than 10 minutes hunting through the manual.
For routine tasks or experts, two seconds typing "find . -atime -1" is much, much better. For tasks you do regularly, you want knowledge in the head. For rarely performed tasks, you want knowledge in the world.
It's interesting the question said "producing" and the things you mentioned are preproduction.
Also, a 48 kHz sample rate cannot try to APPROXIMATE a tone higher than 22kHz. At 22kHz, it's a square wave. That's nowhere NEAR accurately reproducing a 22kHz tone. A sample rate of 48 will represent a 12kHz tone with some accuracy. Look at the wave form to see what I mean.
A monitor two feet away with a 300dpi image has roughly the same angular resolution as a phone one foot away.
If that doesn't make sense intuitively, think of a billboard made up of 1/4 dots - from 50 feet away, it won't look pixelated. Compare looking at the same billboard from 1 foot away - the pixelation will be obvious.
To convert accurately requires geometry that I don't feel like thinking about right now, but you get the point - the closer the viewer, the more easily they can detect pixelation, so you need smaller pixels.
It seems current phones like the two mentioned in TFS are approximately the same resolution as our vision. For an adult human, 400-600 is about the limit of what we can detect.
I guess screen resolution is now at the point cameras have been for a few years - any resolution higher than about 4 megapixels is wasted unless the photo is enlarged considerably. (Or one portion is enlarged aka "zoomed in").
> Lots of devs disparage PHP, but they're all idiots
or they haven't looked closely at the newest changes to the language in the last two years. Or they are talking more about the "PHP community", thousands of "scripters" who use PHP because it's easy to build things in PHP, in the same way that it's easy to build things with Legos.
I helped write the PHP certification test, which suggests I know a little something about PHP. My PHP code is used by many large universities. I could go on, but suffice to say I'm certainly not clueless about PHP. It is my opinion that PHP, as a general purpose language, was awful, horrible, until quite recently. I say "as a general purpose language" because that's how PHP is being used, but that's not what is was originally designed for. It was originally designed as a templating engine, as SSI++. The fact that it was never designed as a programming language was painfully obvious for many years - it had most of the individual features of a language, but no _design_ unifying those features.
We're actually soliciting bids for a new rubble pile to be built. We'll pay several million dollars to whoever builds our next pile of broken concrete. I suggested that the ordnance disposal class could build one cheaper...
We DID have complaints about smoke and noise. It probably didn't help that the fire field is at the end of the main runway for the local airport, so visitors flying in often ser large plumes of smoke just past the end of the runway.
The higher ups wanted to move the fire field to a more remote location and use that land for another purpose. Our director did the obvious thing - he "crashed" to 300,000 pound locomotives in the middle of the property, accessible only by dirt roads. He told them "sure, you can have that land back, you'll just have to drag 600,000 pounds of Amtrak to the new place somehow." Twenty years later, we're still there. I wonder if that director was BOFH in a previous life.
Arbitrary code can run on your machine from the day it's assembled. Java or not makes absolutely no difference in that. That's what a computer IS - a device that runs arbitrary code.
Slashdot Mirror
You CAN commit tax fraud. What happens next IS unknown, it could be jail ...
Thank you for the additional detail. I didn't go into how advanced drive circuits can mitigate the otherwise nearly linear drop in torque because the discussion was about MAXIMUM torque, as opposed to "pretty good" torque. At least for the one EV motor I've studied the dyno chart for, the changing drive voltage helps the torque curve to be flattER, but nevertheless max torque is still at stall.
My post was long enough already.
A user in California wants to download a video hosted in Texas. Both the user's ISP and and the hosting company have fiber lines from Texas to California. Whose lines carry the video across the country? Alternatively, maybe only one company has spent billions building a nationwide network. Whichever company carries the bits across the country is the doing most of the work. The other company should either balance that by carrying half of the traffic cross-country on its network, or kick in a few dollars to help cover the cost. That's Level3's new approach, and it makes a lot of sense.
Which DIRECTION the traffic is flowing really doesn't make any difference. The cost is in carrying the traffic, so Cogent should expect settlement-free peering if and only if they invest in a network that carries their share of the traffic, if the bit-miles are equal.
o
> That constrains the bandwidth between Cogent and the Tier 1s (which Cogent is definitely not).
Some sources disagree. Who is Cogent buying transit from or paying settlements to? Do you have a source for that?
Of course many people would say that Cogent isn't top quality, but that has little or nothing to do with their tier. Tier 3 ISPs buy transit from tier 2 ISPs. Tier 2s buy transit from tier 1 ISPs. Tier 1 providers buy from nobody. As far as I know, Cogent doesn't buy transit from anyone. (Modulo the same types of location-specific deals ALL tier 1 providers have with each other.)
To see this effect in action in an interesting way, apply power to an electric motor, then remove power and watch it freewheel to a stop. Next, add a diode to the terminals, oriented such that the normal power does not go through the diode. Run it and remove power. You'll notice it no longer freewheels, but stops abruptly. What's happening is that it's working as a generator driving itself in reverse. As long as it's spinning, the voltage it produces goes through the diode and tries to make it go backward. As soon as it stops, no more voltage is generated and it never goes in reverse, but stops dead.
The effect is powerful enough that if you don't hook up power and just short the terminals, it becomes very difficult to turn the motor by hand. The motor is literally fighting against you. This is great for robots and such where you want the motor to turn for a certain time and then stop. Just have your controller short the terminals for "stop".
The exact same effect occurs when the motor is operating normally - any time it spins it produces reverse voltage which results in reverse torque trying hard to stop itself.
I thoroughly disagree. As a UX designer, I consider my design "in need of improvement" if it's designed such that it's easy to make specific, known errors. A few hours ago I was on the phone with a customer who uses my Strongbox software. He was making the same error that many other people make. That many people make the error proves to me that the software doesn't make it sufficiently obvious what the correct action is.
about when you've been in sometime else's car at night. Often you have to hunt for the door lever and especially on older cars you have to figure out if the handle should be rotated upward, pulled out and back, out and forward, etc. Doors on buildings often have instructions posted on them - Push or Pull. Other buildings don't need instructions - the door has a flat metal plate that can only be pushed. It can't be pulled or turned, it's a flat plate. Emergency exits get it right - a wide, flat bar is obviously for pushing. Some doors, like one I sawlast week, get it ENTIRELY wrong - that one had a round knob - which needed to be SLID to the side. Round knobs are for turning! Vertical slits or projections are for sliding to the side. Not surprisingly, I saw two different people struggle with that door until someone helped them.
We talked about the handles inside of cars. Contrast that with the handles on the outside of a car door. That's a good design. Noone will ever need help figuring out how to operate an exterior car door handle because the design is such that the user can only do one thing - insert fingers and pull.
I seek to make my designs be like exterior car handles - intuitively obvious. With the right design, not only do users not make errors, they aren't even distracted by looking at the UX, figuring it out. They just do it automatically, intuitively, like opening the door to get into a car.
Credit to The Design of Everyday Things for the door handle example.
As you may know, if you spin an electric motor by putting a prop on it and letting the wind spin it, you've just made a generator. You may also know that doesn't mean that the spin a motor powers itself, forming a perpetual motion machine. That's because the generated voltage is in the reverse direction from the direction required to make it spin (among other things).
So what happens is that when you apply 12 volts to make a motor turn, that "generator effect" is producing 6 volts the other direction. If you put a multimeter on the motor terminals, it'll read 12V - 6V = 6V. So the spinning motor has 6V at its terminals. If it's not spinning, it doesn't work as a generator, so it has 12V on terminals. Guess which one has more torque, the stalled motor with 12V or the spinning motor with 6V? The motor with the full 12V (because it's not generating -6V) has more torque. Max torque, therefore, is at 0 RPM. Faster spinning means more negative voltage generated and lower torque.
A manufacturer of the control circuit can of course ARTIFICIALLY limit the power to the motor at low RPM. If they set the control circuit to not ALLOW the motor to full torque, the car would see consistent torque. That's not because of the motor, though, that would be an artificial limit configured into the controller.
Sub-cycle length sounds are not a normal case, of course. The denigrate example does, however, clearly illustrate the difference between a continuous tone of infinite length, which can be perfectly modelled, and a changing blend of sounds of finite length, which cannot be. Real-world sounds would consist of many samples, but not infinite, and would be appear nearly continuous for several cycles.
Re the low pass frequency, two samples of a DTMF tone around 20 kHz aren't unique at 44k sample rate either - the DTMF is indistinguishable from a pure sine wave with a small number of samples, I'm pretty sure
Sub-cycle length sounds would, I think, include a balloon pop or similar impulse sound - not the sounds typically heard in music, but certainly real-world audio.
>> If you SSH to a remote host
> xforwarding
!?!?
> local lan only
Yeah, if by "remote" you mean "local", then yes that makes sense.
I have used X forwarding over the internet and for brief periods it IS usable with compression turned on. (Usable in an emergency, or a single brief task etc.) It seems we agree it's not a reasonable workflow for day-to-day text editing.
The only criticism I can think of for vim, and a very significant one, is that there's a very significant learning curve in the beginning. You can learn enough in a couple hours to use it to accomplish whatever you need to do, but then you can spend years learning to tricks to make your work time more productive and more interesting by disposing of the drudgery. Whatever transformation you want done to some text, vim can do it in under a second, but only if you've learned the magic keystrokes.
Now it suddenly makes sense to me, I "get it". Infinite samples of a repeating function will create a unique pattern.
We can trivially understand that it doesn't work for finite recordings by looking at the simplest case of one sample. A sound recording of duration 1/R second will generate one sample. The value of that single sample tells us virtually nothing about the sound.
Since real-life sounds are not infinitely long repetitions, samples of real sounds can be pretty good approximations, only.
Maybe what I just said isn't right.
Clearly if you know that the original signal is a digital signal, a square wave, 1/2 B is fine - the recording will be forced to a square wave, which happens to be correct.
Similarly, if you know that it's a single, pure sinusoidal tone, at playback you can round off the edges of the squared recording to get the analogous pure sinuousoid.
If it's not a pure tone, I don't see how you could possibly infer the correct waveform from the squared samples, but the theorem seems to say that you can. That seems quite impossible, but maybe it's not.
At playback, capacitance and physical momentum will round off the corners of a square wave pretty much randomly, while filters can guess that it might be a pure, single tone - a sinusoidal wave (or make some other guess). The recording, the digital file IS sample-and-hold. There is one value per sample.
Starting with the set of squared waves in the recording, then guessing which of many sounds is represented by that sample, will produce _A_ sound. Guessing A sound is not reproducing the original sound. Here's a simple way you can prove it to yourself:
Generate a 23kHz tone. Save as a 48k file.
Generate another 23kHz tone and mix it with another 23kHz offset by 1/92k seconds. Save as a 48k file.
Note that you can visually SEE the difference in the two waveforms.
Check the md5 of the two files. Note that the recordings are identical, though you can see that the sounds were not identical. Sense the recordings are bit-for-bit identical, they will of course play back identically. Filters can be used to round off the edges or otherwise modify the sound, but the two identical files will give results, though they are supposed to represent different sounds.
I'm sure you can think of all kinds of theories to argue why you don't think the files will be identical. Or you can just tryit and see that they are in fact identical.
Vim means "vi, improved". Vim is great. Part of why it's great is because vim is a drop-in replacement (upgrade) for vi.
This guy proposes to do the same thing again, another round of improvements. I believe he intends it will still be a drop-in replacement. Nothing will be lost by symlinking "vi" to nvim instead of vim. Everything will still work the same, only faster and more reliably. I see no reason to think it won't be just as smooth as the transition from vi to vim.
> you can compile Vim with only core vi commands
You can compile Vim TO HAVE only core vi commands.
You can compile Emacs WITH only core Emacs commands.
I wish there were more posts like this on Slashdot ^H^H^H^H^H^H^H^H the internet.
You CAN run a GUI app over the internet and slowly, painfully peck out letters with latency reminiscent of a cheap 4800 baud modem because typing each letter requires generating and downloading an image of the application.
Or you can work literally a thousand times faster by editing text in text mode.
I'm shocked that anyone knowledgeable enough to know what X forwarding is could also be clueless enough to suggest it's a good way to edit text.
What are you talking about? A fake OS update? Does that have anything at all to do anything? A fake update wouldn't add any new system capabilities, so apps wouldn't gain any new capabilities.
Did you read the comment you replied to? Or TFA, or anything to get a clue what that topic is?
That may be the most incorrect xkcd.
Self-explanatory tools (knowledge in the world) is great for a newbie doing a one-time task. Four minutes hunting through menus is better than 10 minutes hunting through the manual.
For routine tasks or experts, two seconds typing "find . -atime -1" is much, much better. For tasks you do regularly, you want knowledge in the head. For rarely performed tasks, you want knowledge in the world.
It's interesting the question said "producing" and the things you mentioned are preproduction.
Also, a 48 kHz sample rate cannot try to APPROXIMATE a tone higher than 22kHz. At 22kHz, it's a square wave. That's nowhere NEAR accurately reproducing a 22kHz tone. A sample rate of 48 will represent a 12kHz tone with some accuracy. Look at the wave form to see what I mean.
A monitor two feet away with a 300dpi image has roughly the same angular resolution as a phone one foot away.
If that doesn't make sense intuitively, think of a billboard made up of 1/4 dots - from 50 feet away, it won't look pixelated. Compare looking at the same billboard from 1 foot away - the pixelation will be obvious.
To convert accurately requires geometry that I don't feel like thinking about right now, but you get the point - the closer the viewer, the more easily they can detect pixelation, so you need smaller pixels.
See that @ sign in your subject line? It's left over from mine, part of @ 1'
It seems current phones like the two mentioned in TFS are approximately the same resolution as our vision. For an adult human, 400-600 is about the limit of what we can detect.
I guess screen resolution is now at the point cameras have been for a few years - any resolution higher than about 4 megapixels is wasted unless the photo is enlarged considerably. (Or one portion is enlarged aka "zoomed in").
> Lots of devs disparage PHP, but they're all idiots
or they haven't looked closely at the newest changes to the language in the last two years.
Or they are talking more about the "PHP community", thousands of "scripters" who use PHP because it's easy to build things in PHP, in the same way that it's easy to build things with Legos.
I helped write the PHP certification test, which suggests I know a little something about PHP. My PHP code is used by many large universities. I could go on, but suffice to say I'm certainly not clueless about PHP. It is my opinion that PHP, as a general purpose language, was awful, horrible, until quite recently. I say "as a general purpose language" because that's how PHP is being used, but that's not what is was originally designed for. It was originally designed as a templating engine, as SSI++. The fact that it was never designed as a programming language was painfully obvious for many years - it had most of the individual features of a language, but no _design_ unifying those features.
We're actually soliciting bids for a new rubble pile to be built. We'll pay several million dollars to whoever builds our next pile of broken concrete. I suggested that the ordnance disposal class could build one cheaper ...
We DID have complaints about smoke and noise. It probably didn't help that the fire field is at the end of the main runway for the local airport, so visitors flying in often ser large plumes of smoke just past the end of the runway.
The higher ups wanted to move the fire field to a more remote location and use that land for another purpose. Our director did the obvious thing - he "crashed" to 300,000 pound locomotives in the middle of the property, accessible only by dirt roads. He told them "sure, you can have that land back, you'll just have to drag 600,000 pounds of Amtrak to the new place somehow." Twenty years later, we're still there. I wonder if that director was BOFH in a previous life.
Arbitrary code can run on your machine from the day it's assembled. Java or not makes absolutely no difference in that. That's what a computer IS - a device that runs arbitrary code.